A suppression policy for dependency scanning is a short document that says who may hide a finding, for which reasons, for how long, and with what evidence. Six parts cover it: allowed reasons, scope, approvers, maximum duration, required evidence and a review routine. Without them, suppressions pile up and nobody can say why.
Why a policy and not just a button
Every scanner lets you mute a finding. That is useful, because many findings are noise. It is also the easiest way to turn a security control into a decoration. A suppression is a decision to accept risk, and it should be recorded like one.
A policy does not need to be long. One page that engineers actually read beats twelve pages nobody opens.
The six parts
| Part | What it answers | Example wording |
|---|---|---|
| Allowed reasons | Why can a finding be hidden? | Not present, not reachable, mitigated, advisory withdrawn or disputed, no fix yet |
| Scope | How wide is the suppression? | One advisory on one package version in one repository |
| Approvers | Who says yes? | Code owner proposes, a second person approves |
| Maximum duration | When does it lapse? | 90 days by default, shorter for high severity |
| Evidence | What proves the reason? | A link to code search, a call path, a test, or a vendor note |
| Review routine | Who looks at the list? | A named owner, monthly |
Write each part in plain terms
Reasons. Keep the list short and closed. If a reason is not on the list, the request goes to a human. Our guide on valid and invalid reasons goes deeper.
Scope. Say that suppressions are per finding, not per package. A suppression for one advisory should never silence future advisories on the same package. See choosing scope.
Approvers. The person who wrote the code should not be the only person who approves hiding a finding in it. Small teams can use a peer from another team.
Duration. Every suppression gets an end date. When it arrives, the finding returns. Renewal is allowed, but it is a fresh decision with fresh evidence. Our post on expiry by reason suggests different defaults for different reasons.
Evidence. One sentence plus one link. "Function is never called, see search result in the pull request" is better than "false positive".
Review. Someone owns the list. They look for expired entries, entries with no owner, and entries that have been renewed more than once.
Where to keep it
Keep the policy in the same place engineers keep other engineering rules, and keep the suppressions themselves as data that can be diffed. A file in the repository, reviewed in a pull request, gives you history for free. Chat messages and spreadsheets lose context fast.
A common failure
Teams write the policy and forget the end dates. Six months later the list has 400 entries, half of them for packages that were removed. Make expiry a default in the tooling rather than something people must remember to type.
If your scanner supports it, let the gate treat an expired suppression as no suppression at all. That removes the need for anyone to chase.
Where Safeguard fits
Safeguard supports policies, gates and guardrails for dependency findings, plus compliance and evidence automation, so suppression decisions and their evidence can be recorded in one place. You can try a free scan at gold.safeguard.sh/scan.
Quick check
How long should a suppression policy be?
One page is enough. Cover reasons, scope, approvers, duration, evidence and review. Link to longer guidance for edge cases.
Do suppressions need an approver?
Yes for anything beyond a clear false positive. Having someone other than the author approve is the simplest control.
Last reviewed: 19 October 2026.
