Managing severity and validity
Triage findings consistently so the highest-risk issues get attention and false positives stay out of the way.
V12 gives every finding an initial machine-generated severity and validity signal, but the final call belongs to your team. Use the two together:
- Severity answers how bad the issue would be if it matters.
- Validity answers whether the issue is real, accepted, or still waiting on human review.
Severity levels
| Level | Meaning |
|---|---|
critical |
Severe, exploitable impact that needs immediate attention |
high |
Significant security risk that should be prioritized quickly |
medium |
Meaningful issue that deserves investigation and likely remediation |
low |
Lower-risk problem or a minor weakness |
qa |
Quality or hygiene issue worth tracking, even if it isn’t a security bug |
untriaged |
No final severity has been set yet |
Validity states
| State | Meaning |
|---|---|
unreviewed |
Nobody on your team has made a final call yet |
valid |
Confirmed as a real issue |
invalid |
False positive, not applicable, or otherwise not actionable |
acknowledged |
Real or relevant enough to keep visible, but intentionally accepted for now |
Where to change them
From the list
Click either badge in the findings list: use the severity badge to change the risk level, or the validity badge to change the review status.
From the details panel
Use the evaluation controls to mark a finding Valid, Invalid, or Acknowledged. Click the active state again to return it to Unreviewed.
Practical triage workflow
A reliable first pass usually looks like this:
- Review Critical and High findings first.
- Open the Proof of concept tab when available to understand exploitability.
- Use Invalid aggressively for clear false positives.
- Use Acknowledged when the team accepts the issue, dependency, or tradeoff and wants that decision recorded.
- Revisit Unreviewed items until the queue is empty.
How these decisions help
Next: Using Autopilot