Vulnerability triage

Review the findings an autonomous pentest surfaces — taxonomy, validation, triage, human review, retest, SARIF export and quality gates.

The triage queue

Every confirmed finding from a pentest lands in its vulnerability queue. A vulnerability here behaves less like a static scan result and more like a ticket: it has a state, an owner, a discussion thread, evidence and a full audit history. Triage is the work of taking each finding from “newly detected” to “closed” — by fixing it, disputing it or accepting it.

Open a finished pentest and go to its Vulnerabilities tab to see the queue. For the underlying model, read Vulnerabilities.

Read a finding

Each finding shows its severity (critical, high, medium, low, info), a due date computed from that severity, its current state, and any assignee. You can sort and filter the queue by severity, status and priority to work the most urgent items first. A per-pentest summary rolls everything up: counts by status, by severity and by priority, the overall resolution rate, mean time to resolve and the number of overdue findings.

Severity is set from the impact of the finding and isn’t something you change. Priority (urgent, high, normal, low) is yours to set, so you can manage your own work queue independently of severity.

Taxonomy

Each finding carries structured identifiers alongside the narrative:

• CVSS 4.0 — vector, base score and severity. The discovering model supplies metrics; code computes the score. Overriding a CVSS-derived severity requires a reason.
• CWE and related CVE ids.
• ATT&CK techniques (T1190, T1110.001).
• EPSS and CISA KEV — published exploitability signals. They are not writable; they stay checkable against the publishers.
• Fingerprint — a stable identity Rank computes for dedup and regression across runs.

Independently, you still control priority for your own queue. The full object is in Vulnerabilities.

Validation

Triage state (open, resolved, …) is independent of validation_status, which is how much the finding can be trusted as a confirmed issue:

Validators are isolated from the discovering model. Human review settles needs_manual_review or not_validatable to validated or failed. It is not a way to walk back an already recorded conclusion.

Resolve, dispute or accept

A finding is always in exactly one of five states: open, in_progress, resolved, false_positive or accepted_risk. From the detail view you can move it along:

• Resolve — mark it fixed. You choose whether to resolve with evidence (which requires at least one uploaded file) or without evidence (allowed, but discouraged).
• False positive — declare it isn’t a real issue. This requires a written reason.
• Accept risk — acknowledge it but decide not to fix it.
• Reopen — send any closed finding back to open if a resolution didn’t hold. Reopening a false positive clears its stored reason and recomputes the due date.

You can also flip a finding between open and in_progress directly to reflect that someone has started work, and change its priority at any time.

Assign and discuss

When a pentest belongs to a team, findings become collaborative:

• Assign a finding to a team member (the assignee must belong to that team). Assigning an open finding automatically moves it to in_progress, and the assignee is emailed.
• Comment on a finding. Comments appear in a combined activity feed alongside automatic system entries — status changes, assignments, evidence uploads — so the whole story of a finding is in one place. You can edit and delete your own comments.

Assignment, comments and notifications keep a team aligned without leaving the platform. Setting up roles and membership is covered in Teams & RBAC.

Evidence

Evidence is how you back up a resolution. From a finding you can upload proof that it has been mitigated:

• Supported formats: images (jpg, jpeg, png, gif, webp), PDF, TXT and CSV.
• Up to 20 files per finding, each up to 10 MB.
• Every upload is validated three ways — by file extension, by declared MIME type and by actual file content — so a renamed file can’t slip through.

An evidenced resolution is one that has at least one such file attached. Files are stored securely and served back through time-limited download links.

Retest

A retest is a separate run against a resolved finding. It does not rewrite validation_status. Outcomes: fixed (stays resolved), still_vulnerable (reopens to open), inconclusive or skipped. Optional cookies/headers for that run are never returned on later reads. A scheduled re-run of the whole pentest is a different object — see Scheduled pentests. How to enqueue and poll a retest is in the Retest API and the retest recipe.

Audit history

Every state change is recorded in an immutable history trail: who changed what, when and why. Combined with the activity feed, this gives you a defensible record of how each finding was handled — useful for compliance and for post-engagement review.

Quality gates for CI/CD

Triage doesn’t have to be manual. For pipelines, a quality gate evaluates rules against a pentest’s current findings and returns pass/fail, so a failing gate can block a deploy. Always-on rule types: no open criticals (severity + max_open), a minimum resolution rate (min_resolution_rate, 0–1), no overdue findings (max_overdue). Opt-in, on top of those: min_verified_resolution_rate, max_unverified_resolved, max_regressed, max_pending_retests.

{
  "rules": [
    {"severity": "critical", "max_open": 0},
    {"severity": "high", "max_open": 5},
    {"min_resolution_rate": 0.8},
    {"max_overdue": 0},
    {"min_verified_resolution_rate": 0.9},
    {"max_unverified_resolved": 0},
    {"max_regressed": 0},
    {"max_pending_retests": 0}
  ]
}

This pairs with bulk status updates (triage many findings at once) and export (CSV, JSON, SARIF, DefectDojo) for auditing. Quality gates, bulk updates and webhooks are available on the appropriate plans — see Teams & tiers. To wire this into a pipeline, see the Vulnerabilities API and the recipe Vulnerability triage & CI gate.

Export

Download the full set of findings for a pentest as CSV (spreadsheets and auditors), JSON (tooling), SARIF (GitHub Code Scanning and similar; fingerprints are stable across runs) or DefectDojo. SARIF and DefectDojo are finding exports, not sealed report formats.

The CSV/JSON export includes each finding’s title, description, severity, status, priority, assignee, resolution type, false-positive reason, due date and resolution timestamps.

Where to go next