Valid reasons to suppress a dependency finding are that the vulnerable component is not present, the vulnerable code cannot be reached, a control already blocks the attack, or the advisory was withdrawn or is wrong. Invalid reasons include "no time", "it is old" and "we will fix it later" without a date.
The test for a reason
A good reason describes a fact about your software that makes the finding not apply. A bad reason describes your schedule. Facts can be checked. Schedules cannot.
The OpenVEX specification, a format for stating whether a product is affected by a vulnerability, gives a useful vocabulary. Its justification values for a not affected status are 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. These map neatly onto what a scanner suppression should say.
Valid reasons and the evidence each needs
| Reason | Evidence to attach |
|---|---|
| Component not present | Build output or SBOM showing the package is absent from the shipped artifact |
| Vulnerable code not present | Proof the affected function or module was stripped or never included |
| Not in execute path | A call graph, reachability result, or code search plus a test |
| Cannot be controlled by an attacker | Description of where input comes from and why it is trusted |
| Mitigation exists | The control, where it runs, and a test that shows it blocks the attack |
| Advisory withdrawn or disputed | A link to the withdrawal or the dispute note |
Reasons that look valid and are not
"It is a dev dependency." Sometimes true, sometimes not. A build tool can run attacker-supplied files in CI. Check what the package does and where it runs.
"No known exploit." Absence of an exploit today is not a property of your code. It is a snapshot, and it expires. Use it as a priority signal, not a suppression reason.
"Low severity." Severity is a prioritization tool. If you need to defer, use a time-limited exception, not a permanent hide. See low severity suppression.
"The scanner is always wrong about this package." That may be true, but the right action is to find the cause and report it, not to blanket silence the package.
"We accepted this last year." Acceptances age. Conditions change.
A short procedure
- Name the reason from a closed list.
- Attach the evidence in the same record.
- Scope it to one advisory and one version range.
- Set an end date.
- Get a second person to approve.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how findings split into reachable and not reachable, which is the evidence behind the most common valid reason.
Where Safeguard fits
Safeguard runs reachability analysis on dependency findings, so the evidence for a not reachable reason is generated rather than written by hand. The free scan at gold.safeguard.sh/scan shows what it looks like on a real project.
Quick check
Is "no fix available" a valid suppression reason?
It is a valid reason to defer, not to hide forever. Record it with an end date and a mitigation, and revisit when a fix ships.
Can a false positive be suppressed without evidence?
Avoid it. One sentence and a link makes the decision auditable and saves the next person an hour.
Sources
Last reviewed: 19 October 2026.
