Default to per-finding exceptions, because each one ties a decision to a specific issue and asset. Use a blanket waiver only for a narrow, well-defined class, such as one test-only package family, with a named owner, evidence and a short expiry. Never waive "all low severity".
Definitions
A per-finding exception covers one advisory on one component in one place. A blanket waiver covers a pattern: a package, a severity band, a repository, or a class like "dev dependencies".
Comparison
| Aspect | Per-finding | Blanket |
|---|---|---|
| Effort to create | Higher | Lower |
| Precision | High | Low |
| Drift risk | Low | High, hides new findings |
| Audit clarity | Each decision visible | One decision hides many |
| Fits | Production code | Narrow, low-impact classes |
The big risk with blanket waivers is future findings. A rule that covers a package covers every advisory published against it tomorrow, including ones nobody has read.
When a blanket waiver is defensible
All of these should be true:
- The class is narrow and named, not a severity band
- The code runs only in a contained place, such as a build step with no network or secrets
- Someone owns it and has written the reasoning down
- It expires within weeks or a few months
- New advisories in the class still alert the owner
If any of these fails, split it into per-finding exceptions.
Scoping tests
Ask the same questions as for any exception: which asset, which version, which environment. The post on how to scope a vulnerability exception to one asset, not everywhere goes deeper.
A blanket waiver should also carry a cap on what it can cover. For example, it may exclude anything on a known exploited list. Exploitation evidence should reopen the decision automatically.
A safer alternative: policy rules
Often the real need is "do not block on this class". That is a gate policy, not a waiver. A written, versioned policy such as "dev-only dependencies do not block merges, but still appear in reports" is visible, reviewable and applies the same way everywhere. A waiver pretending to be a policy is hard to audit.
Reviewing existing blanket waivers
List every waiver that matches more than one finding. For each, count the findings it currently hides and how many were published after the waiver was created. If the hidden set has grown, the owner never approved those later ones. Convert them to per-finding records or retire the waiver.
Safeguard's policies, gates and guardrails let you write class-level rules as policy, with reachability analysis showing which findings actually matter in your code.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how evidence can narrow a long list to the findings that deserve a decision.
Quick check
Is waiving every low severity finding acceptable?
It is a policy choice, not a waiver. If you do it, write it as a policy with an owner and review date.
Do blanket waivers need expiry?
Yes, and a shorter one than per-finding exceptions, because they hide more.
Last reviewed: 19 October 2026.
