Prove it is a false positive before you suppress it. Record the analysis using a standard justification, scope the suppression to the exact component and release, give it an expiry, and report the error upstream if the data is wrong. Never silence a rule globally to clear one finding.
Two kinds of "false"
Be precise about which one you have, because the response differs.
- The finding is wrong. The data source says your version is affected, but it is not, for example because of a misread version range or a backported fix.
- The finding is real but not exploitable here. The component is present, yet the vulnerable code is never called or cannot be reached by an attacker.
The second is not strictly a false positive, but teams often treat it as one. It is better handled as "not affected" with a justification.
Using standard justifications
The OpenVEX specification gives a common vocabulary. Its not_affected status requires a justification or impact statement, with values such as component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary and inline_mitigations_already_exist. Using these labels makes your reasoning legible to auditors and customers, and avoids vague notes like "ignore".
Steps
- Reproduce the finding. Note the component, version and rule.
- Read the advisory and compare its affected range to what you run.
- Check reachability: is the vulnerable function called, and can an attacker control the input?
- Pick the matching justification and write two sentences of evidence.
- Suppress narrowly: this component, this version, this release, with an expiry.
- Get a second person to review the suppression.
- Report data errors to the advisory source or your scanner vendor.
Guardrails against abuse
| Risk | Control |
|---|---|
| Suppressing to ship faster | Second reviewer, reason required |
| Suppression outliving the facts | Expiry date, re-check on new release |
| Broad rule disabled | Narrow scope only |
| No visibility | Monthly suppression report |
Track the ratio of suppressed to total findings per team. A sudden rise deserves a conversation.
Fix the root cause
If the same false positive appears again and again, the cause is usually data or configuration. Tuning a scanner is legitimate work, but record changes as policy changes, with review, not as private tweaks.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which findings drop out when the vulnerable code is never called.
Safeguard offers reachability analysis and policy gates, and a free scan is available at gold.safeguard.sh/scan.
Quick check
Can we suppress a finding without a reviewer?
Better not. A second pair of eyes catches rushed or self-serving suppressions.
Should suppressions expire?
Yes. Facts change when the component or the code changes, so re-check at each release.
Sources
Last reviewed: 19 October 2026.
