Understanding findings
Read severity first
Section titled “Read severity first”Start with critical and high items — they represent the largest potential impact if valid.
Then confidence
Section titled “Then confidence”Within the same severity band, prefer higher confidence when deciding what to fix first.
Validate in context
Section titled “Validate in context”Ask:
- Does this match how our protocol actually runs?
- Is the assumption still true after our latest changes?
- Is there a dependency or integration the finding does not cover?
Use system analysis
Section titled “Use system analysis”Open invariants, assumptions, and decisions when available — they help you judge whether an issue is realistic for your design.
Track review state
Section titled “Track review state”Use per-finding review labels — open, true positive, or false positive — so your team agrees on what is accepted, fixed, or dismissed.
Set an audit verdict on the repository when the latest completed scan has been reviewed (for example requires action vs all clear).
When exploit verification exists
Section titled “When exploit verification exists”If exploit verification ran, treat reproduced outcomes as strong evidence — but still align with your threat model. Exploit runs are started from a completed code audit (repo Exploits tab), not as a separate top-level product entry.