Read five things in order: the rule name, the file and line, the data path, the severity and confidence, and the surrounding code. Then try to reproduce or reason through an attack. If you cannot explain how an outsider reaches the flaw, mark it unclear rather than real.
Why this matters
OWASP notes that static analysis reports the file, line and snippet but that confirming a finding is a real vulnerability can be hard, and false positives are common. A repeatable method turns guessing into a decision you can record.
The five steps
- Rule. What weakness does the rule describe? Look up the weakness category so you know what a true case looks like.
- Location. Open the file at the line. Is it production code, a test, a generated file or a sample?
- Path. Follow the data from source to sink. Did it cross a validation or encoding step the tool missed?
- Severity and confidence. Severity is the damage if real. Confidence is how sure the tool is. A high severity, low confidence finding needs a human look, not an alarm.
- Context. Can an outside user reach this code? Is it behind authentication? Is the data sensitive?
Verdict table
| What you found | Verdict | Action |
|---|---|---|
| Path from public input, no sanitizer | Real | Fix and add a test |
| Sanitizer exists but is unknown to the tool | False positive | Suppress with reason, or teach the rule |
| Code only in tests | Not a risk | Exclude the folder |
| Cannot tell | Unclear | Ask the code owner, set a review date |
Write it down
For every verdict, note the reason in the ticket. Short notes like "input is validated by the shared parser, see file name" help the next reader and feed rule tuning.
Fix properly
Fix the cause, not the symptom. If one helper builds unsafe queries, change the helper so all callers benefit, and add a test that fails on the old behavior.
Common mistakes
New reviewers often fix the line the tool points at and move on. That may silence the alert without removing the weakness, for example by escaping a value for the wrong context. Re-run the scan after the change and, for serious issues, add a test that sends the hostile input. Another habit worth building is reading neighboring findings: three similar results in one folder usually point to one shared mistake worth fixing once.
Quick check
What if the tool and I disagree?
Get a second opinion from the code owner. Document the reasoning if you suppress.
Do I need to reproduce every finding with an exploit?
No. Reproduce high severity ones where practical. For others, a clear reasoned path is enough.
Where Safeguard fits
Safeguard provides reachability analysis and policy gates for dependency findings, which narrows what you read by hand. Try the free scan.
Sources
Last reviewed: 19 October 2026.
