Scope a dependency suppression as narrowly as the evidence allows: one advisory, on one package version, in one project or path. Suppressing a whole package hides every future advisory on it, and suppressing a whole directory hides new dependencies added later. Narrow scope costs a few extra lines and prevents silent risk.
The scope ladder
From narrowest to widest:
| Level | What it hides | Risk |
|---|---|---|
| One advisory, one version, one project | Exactly the reviewed finding | Lowest |
| One advisory, all versions | The same issue across versions | Medium: a new version may behave differently |
| One advisory, all projects | The issue everywhere | Medium: other projects may use the code differently |
| One package, any advisory | Every present and future issue | High |
| One path or directory | Everything found in that tree | High |
Pick the lowest rung that does not generate daily busywork.
Why package wide is dangerous
Advisories arrive over time. A reviewer who looked at one issue on Tuesday has not reviewed the issue published next March. A package wide rule turns a decision about one finding into a decision about findings nobody has seen.
Why version matters
Evidence belongs to a version. Your call path analysis was done against the code as it stood. If the dependency upgrades, the vulnerable function may now be called by new code. Tie the suppression to the exact version so an upgrade forces a fresh look. Our post on exceptions across upgrades covers this.
Why project matters
The same library can be harmless in a CLI and dangerous in a web service that passes user input into it. If three services use it, review three times, or suppress with a list of named projects.
When wide scope is fine
There are honest cases for a wider rule:
- A package that is confirmed absent from every shipped artifact, such as a test helper that never leaves the build.
- A withdrawn advisory, where the data itself is wrong everywhere.
- An advisory that does not apply to your operating system or runtime, across all projects that share it.
Even then, set an end date and write the reason.
Path rules and test directories
Path rules solve a different problem: code you do not ship. Excluding a samples folder from scanning is a scan scope choice, not a risk acceptance. Keep the two separate, and see excluding paths versus suppressing.
How to apply it
- Start from the narrowest rule your tool allows.
- Write the project name, package, version and advisory ID into the record.
- If a request asks for package wide scope, ask what evidence covers future advisories. Usually there is none.
- Review wide rules more often than narrow ones.
Where Safeguard fits
Safeguard policies and gates can be written per finding, so a decision stays attached to the advisory and version it was made for. A free scan at gold.safeguard.sh/scan is a quick way to see your current findings.
Quick check
Is it ever fine to suppress a whole package?
Rarely. It fits a package confirmed absent from shipped artifacts. Even then, add an end date.
Should the version be part of the rule?
Yes. Evidence is tied to the code you reviewed, and an upgrade should trigger a fresh review.
Last reviewed: 19 October 2026.
