Findings and remediation

What a finding is

A finding is one issue identified by the platform, tied to one asset, supported by evidence, and tracked over time. Every finding has a severity, a validation state, a lifecycle status, remediation guidance, and a history of every action taken against it.

Findings are scope-bound. Two findings on the same kind of issue across two scopes are tracked separately because their context, remediation paths, and owners can differ.

Triage workflow

The findings inbox is the daily working surface. Most teams adopt the same rhythm: highest severity first, then look at validation state, then read evidence, then assign or act.

1. 1Filter by scope, severity, validation state, and status.
2. 2Open the highest-severity findings first.
3. 3Read the evidence to confirm the issue is real.
4. 4Assign an owner (typically the team that owns the asset).
5. 5Set status — in remediation, accepted risk, false positive, or resolved.
6. 6Start a validation run if the finding's state is unclear, or schedule a retest after a fix ships.

Severity and confidence

Severity reflects the impact of the issue if exploited. Confidence reflects how sure the platform is that the issue is real. A high-severity, low-confidence finding deserves validation; a high-severity, high-confidence finding deserves remediation immediately.

• Severity — Critical, High, Medium, Low, Informational.
• Confidence — automatic estimate based on evidence strength.
• Use both signals together when triaging.

Reading evidence

Evidence is what separates a finding from a guess. Open a finding's Evidence tab to see exactly what the agent did and what came back.

• HTTP exchanges — full request and response pairs, suitable for reproducing manually.
• Artifacts — downloaded files, screenshots, payloads, and other captured material.
• Excerpts — relevant portions of larger documents or responses.
• Code locations — file paths and line numbers, when white-box context was available.
• Timeline — every action the agent took on this finding, in chronological order.

Validating a finding

When the platform is uncertain, or when your team wants to independently confirm an issue before remediation, request a validation run. The agent re-executes a focused assessment using the original evidence as the starting hypothesis.

1. 1Open the finding.
2. 2Click Validate.
3. 3The platform launches a small run scoped to that finding.
4. 4When it completes, the validation state updates and new evidence is attached.

Retesting after remediation

Once an engineering team ships a fix, request a retest. The agent compares the current behavior against the original evidence and updates the finding lifecycle. If the issue is gone, the finding moves to resolved with a fix-verification record attached.

Lifecycle actions

Each finding can be moved through the lifecycle as its real-world status changes.

• Open — newly created or under review.
• In remediation — assigned to a team and being worked on.
• Retest requested — fix has shipped; waiting for verification.
• Resolved — verified fixed and closed.
• False positive — confirmed not a real issue (with note explaining why).
• Accepted risk — your team has decided not to fix (with note and optional expiry).

Assignment

Findings can be assigned to organization members. Assignment routes notifications, updates the dashboard, and helps reports identify ownership. Combine it with the asset's owner team field to make assignment near-automatic over time.

Sharing and export

Findings can be shared internally as part of run reports, included in evidence packages for compliance, or exported as standalone documents for handoff to engineering. The platform always preserves the evidence trail with the export.