Findings

A finding is one security check evaluated against one resource. The Findings page lists every finding across the connected accounts, ranked by severity: Critical, High, Medium, Low, Info. Each finding carries status fail, pass, or manual. The page opens on failing checks.

Two views

• By finding. One row per resource and check. The flat list, best for working a filtered queue.
• By check. One row per check with an impacted-resources tally. Best for seeing which controls fail broadly. Click a check to drill into its findings.

Filtering

A single search box sits beside a Filters button that carries a badge with the number of filters currently off their default and opens a grouped popover. Every filter you set becomes a removable chip in a row under the bar; the two baseline filters (Status Fail and Muted hidden) always show a chip, and dismissing one widens that filter rather than clearing it. Unset filters show as quiet chips that open the popover, and Reset clears them all.

The popover groups:

Filter	Values
Status	fail, pass, manual, all
Severity	Critical, High, Medium, Low, Info, each with a count
Service	IAM, S3, EC2, …
Region	any region seen in the connected accounts
Category and resource type	check category, native resource type
Change	New or Changed since the previous scan of the account
Muted	hidden, muted only, or muted + active. The default is hidden. See Mute rules
Scan	a specific run, via View findings on the Scans page

The change filter is the fastest way to review a fresh scan: New is what regressed, and remediated findings drop out of fail. Severity is single select today, one severity at a time.

The posture strip

Between the filters and the table, a strip states in one line how many findings are failing, across how many resources, and a distribution bar coloured by severity. Clicking a severity in its legend filters the list to that severity.

The table

One row per finding: a left severity stripe, the check title and id, the affected resource (a short name over its full identifier), account and region, the frameworks it maps to, and when it was first seen (hover for the exact date). The Status column appears only when the status filter is all; otherwise the whole list already shares one status. When the change filter is on, each row notes whether it is new or changed.

The finding detail

Open a row and the finding takes the whole page in place of the list, with the navigation still at the side. A breadcrumb at the top reads Findings › the check; tap Findings (or press Escape, or use your browser's Back) to return to the list exactly as you left it. J and K step to the next and previous finding from the keyboard. / focuses the search box on the list.

• Header. Severity and status badges (plus new in this scan when the change filter is on), the check title, copyable identifiers (the check id and the resource), and one line of facts: account and account id, region, service, and when the finding was first and last seen. The header is washed in the finding's severity colour.
• Actions, at the top right (at the bottom of the screen on a narrow tablet). View resource opens the affected resource in place, so you can inspect the resource and step back without leaving the page; Mute this finding is offered for a failing, unmuted finding.
• Status detail. What the scan actually found on this resource, promoted to the top and tinted by pass or fail.
• Risk. Why the failure matters.
• Remediation. Step-by-step guidance, with a copy button on any CLI or IaC snippet.
• Same check elsewhere. The other resources failing this same check. Open one in place (the breadcrumb keeps the trail; each earlier crumb and Escape step out one level), or See all to drill the list into the check.
• Compliance, in the side column. The frameworks this check maps to, grouped with their requirement ids.
• References, in the side column. Links to provider documentation, for the checks that carry one. The section is absent when a check has none.
• Mute state. A muted finding shows its reason at the top of the detail.

On a wide screen the reading column and the side column sit side by side; on a tablet or a narrow window they stack, and every control is sized for a finger.

The open finding lives in the address bar as ?finding=<id>, so an open finding is a link you can send. Anything you open inside the detail from there — a same-check finding, or the affected resource through View resource — is in-memory only and is not written to the URL. The breadcrumb spans both, so a trail can read "Findings › a check › a resource"; each earlier crumb steps back to that level, Escape steps out one level, and the Findings crumb closes the whole trail.

Reading severity

Severity is the check's assessment of impact, not a to-do ordering by itself. A Critical on a production account outranks a Critical on a sandbox. Use provider groups on the Accounts page to keep that context filterable.

History is kept

Findings history is kept on every plan. The Findings page reads findings per scan: pick a scan and the page shows exactly what that run found.