Findings¶

A finding is a specific security issue, misconfiguration, compliance gap, or vulnerability discovered during an inspection run.

Browsing findings¶

Open a completed run and click the Findings tab. Each row shows:

View modes¶

Toggle between two views using the buttons at the top of the Findings tab:

• All Findings - flat list of every finding in this run, sorted by severity
• Grouped by Pattern - findings grouped by their pattern_fingerprint (same rule, same resource type). Rows are collapsible; expand a group to see all occurrences. Use this view to identify systemic issues affecting many resources at once.

Note: When navigating from the WAF tab, the view is locked to All Findings - WAF findings are associated with individual resources and do not benefit from pattern grouping.

Filtering¶

Use the collapsible filter sidebar (click the filter icon to toggle). All filters are applied in combination. Click Clear All to reset.

Severity¶

Select one or more levels (Critical, High, Medium, Low, Info). Multiple selections are OR'd - selecting Critical + High shows findings at either severity.

Cloud¶

Filter to a specific cloud provider: AWS, Azure, or GCP.

When a cloud provider is selected, a Region text field appears - enter a region name (e.g. us-east-1) to narrow further.

Source¶

Filter findings by which scanner agent produced them:

Codebase scanner sub-filters¶

When Codebase is selected, an additional Scanner section appears with fine-grained sub-filters:

Selecting a sub-filter shows only findings from that specific scanner while keeping the source filter on Codebase. Switching to a different source (e.g. Cloud) automatically clears the scanner sub-filter.

Category¶

Filter by what kind of finding it is:

Remediation¶

The Remediation section of the filter sidebar surfaces fixability as a first-class filter:

• Has Fix toggle - show only findings that have a matching remediation template (based on the finding's check ID), or a fix that has already been proposed. Useful for building a "what can I fix right now?" work queue.
• Fix Status dropdown - filter by the remediation workflow state. Only visible when Has Fix is enabled.

Filter state is preserved in the URL - share a link pre-filtered to "Has Fix + Proposed" to hand off a fix queue to another operator.

AI Workloads and WAF-only¶

Two independent toggles narrow the list to a specific finding origin regardless of the Source filter above: AI Workloads shows only AI-SPM findings, and WAF-only shows only WAF Assessor findings. Both can be combined with any other filter.

False positives¶

Toggle on to show only findings marked as false positives; toggle off (default) to hide them.

Natural-language search¶

In addition to the instant substring search box, press Enter in the search box to run an AI-interpreted search: a short natural-language description like critical S3 findings from last week or unresolved secrets in the payments repo is translated into structured filters automatically.

The results banner shows "AI interpreted your query as..." with the filters that were actually applied, so you can verify the interpretation before trusting the results. Changing any other filter clears the natural-language search and returns to the normal instant filter.

Note: If the AI interpreter is unavailable, the search box falls back to a plain server-side substring search instead of failing outright.

Severity levels¶

Finding detail¶

Click any finding to open the detail sheet. It has three tabs:

Details tab¶

• Full description and evidence
• Remediation panel - when a matching template exists, shows the best-matched remediation template with:
• Risk badge (low / medium / high) and estimated operator time
• Numbered step list with the specific resource ID already filled in
• Tabbed code snippets - Steps · CLI · Terraform · IaC (only tabs with content are shown)
• Propose Fix button - creates a remediation proposal for this finding; disabled once proposed
• Approve button - available after a fix has been proposed; approves it for application
• AI-suggested fix: when no deterministic remediation template matches, an LLM-generated fix may be offered instead. Accepting it opens a real, reviewable pull request on the source repository with the change; VirtualSutra never merges it or writes directly to your default branch. Requires the remediation:approve scope. If the LLM is unavailable, this control shows a clear "unavailable" state rather than a broken button.
• Compliance controls - which specific control IDs across frameworks this finding violates
• Raw evidence - the raw API response or scan output (expandable)

History tab¶

Shows every run in which this finding (matched by fingerprint) has appeared:

Use the History tab to track whether a finding has persisted across multiple scans, understand when it first appeared, or confirm it was resolved after remediation.

Composite alerts¶

Some findings are only alarming together. A public S3 bucket is a finding. PII in a bucket is a finding. A public bucket that contains PII is an emergency - and neither individual finding says so.

A composite alert is a single finding that says it. It is produced by fixed, reviewable rules - not by a language model - and it always names the exact findings that triggered it.

What triggers one¶

How they behave¶

• Severity is raised one level above the worst member, capped at Critical. Two High findings that combine into a composite produce a Critical alert.
• Select Composite in the Category filter to see only composite alerts.
• They behave like any other finding everywhere else: they appear in reports and exports, trigger notifications (including on-call paging), can be muted or marked false positive, and deduplicate across runs so you can watch one in the History tab.

Member Findings¶

Open a composite alert and its detail sheet shows a Member Findings (n) list directly under the summary, above any remediation panel. Each row shows the member's severity badge and title.

• Click a member to open it in place - the sheet swaps to that finding and the header gains a Back to … control that returns you to the composite.
• Long lists are capped at the first 20 rows with a +n more line.

Verified safe versions on dependency fixes¶

When a dependency finding has a remediation, VirtualSutra checks the proposed target version against every published advisory for that package rather than trusting whichever "fixed version" the scanner happened to record. The remediation header shows one of two badges:

The Unverified reasons are:

No badge at all means this remediation is not a dependency upgrade, so there is nothing to verify.

Marking false positives¶

If a finding does not apply to your environment, toggle Mark as false positive on the finding detail. False positives stay visible with a badge but are excluded from compliance scoring.

Deduplication¶

If the same underlying issue appears across multiple runs, VirtualSutra deduplicates it using a fingerprint. Deduplicated findings show a Deduplicated badge.

Issues¶

Persistent findings are automatically promoted to Issues - tracked entities with a full state machine:

Browse all issues under the top-level Issues navigation item. Each issue links to the findings that triggered it and shows first/last seen timestamps.

Mute rules¶

Pattern-based mute rules suppress findings that match a fingerprint pattern, check ID, or resource path - across all runs. Manage mute rules under Settings → Mute Rules. Rules can be imported in bulk via YAML.

Resource catalog¶

The Resources tab on the Run Detail page groups all findings by the resource they affect, giving you a resource-centric view alongside the finding-centric Findings tab.

Each row in the resource catalog shows:

The resource catalog is read from GET /runs/{run_id}/resources. It is available as soon as the run completes and does not require any additional configuration.

Navigating from the Service Map¶

On the Map tab, click View Findings → on any tile to jump to the Findings tab pre-filtered for that tile's context:

The findings are opened in All Findings (flat) view.

Attack path analysis¶

On the Map tab, an attack paths overlay draws directional red edges between nodes on the service map, showing multi-step chains an attacker could realistically follow. For example, an internet-facing security group into an over-privileged IAM role into a sensitive S3 bucket. Each step is numbered on the map; click a path to open the Attack Path Detail panel with the full chain, the specific findings backing each step, and the reasoning behind the chain.

Toggle the overlay off with Show attack paths if you just want the plain service map. A run with no correlated attack paths simply shows no overlay; this isn't an error state.

Note: Attack paths are generated by an LLM correlating the security graph (see below) with your findings, and are only as complete as the graph data available for that run. Treat a path as a strong lead to investigate, not a guarantee that no other paths exist.

The security graph¶

Behind the attack-path overlay is a graph of your environment's resources and the relationships between them (e.g. "security group X allows ingress from Y", "role A can assume role B"). The graph is built automatically from each run's findings, primarily security-group reachability and infrastructure-as-code relationship findings, and requires no separate configuration.

Effective permissions (CIEM)¶

Cloud Infrastructure Entitlement Management (CIEM) findings surface principals (users, roles, service accounts) whose effective permissions are broader than their attached policies suggest once role assumption, group membership, and policy composition are taken into account. For example, a role that can escalate itself to admin via iam:PassRole, or a service account with an unused Owner binding.

These show up as regular findings with finding_category: relationship, filterable and viewable the same way as any other finding. Coverage differs by provider:

CIEM runs automatically as part of a cloud inspection (there's no separate toggle), provided the account's credentials include the permissions listed in Cloud Account Configuration. If those permissions are missing, the check is not evaluated: the findings the scan did collect are kept, the account's task completes with the check named in its message and in the Cloud scan coverage record (which carries the role to grant and the command that grants it), and the run ends partial. This is the same for AWS, Azure and GCP.

AI workload security (AI-SPM)¶

AI Security Posture Management (AI-SPM) findings cover AI/ML services deployed in your cloud accounts: Amazon Bedrock and SageMaker, Azure OpenAI, and Google Vertex AI. Checks look for issues like missing invocation logging, absent guardrails/content filters, public network access to a model endpoint, and over-permissive execution roles.

Turn a scan on by setting enable_ai_spm on the relevant cloud account connection (Settings > Connections > Cloud) or directly in the inspection scope. Findings are tagged so you can filter to just AI workloads using the AI Workloads toggle in the filter sidebar (alongside the WAF-only toggle covered under Filtering above).

AI-SPM findings map to two additional compliance frameworks; see Compliance for exactly which risks/functions are covered and which are deliberately not claimed as covered.

Comparing runs (diff)¶

The Run Detail page shows a diff against the previous baseline run: