No, do not suppress all low severity dependency findings. Severity is a starting score, not a verdict about your software. Lower their priority, batch them into routine updates, and let rules escalate them when exploitation, reachability or exposure changes. Hide only what you have reviewed and can justify.
What severity does and does not say
A severity rating describes the technical impact of a flaw in general terms. It does not know how your code uses the package, whether input is attacker controlled, or whether the issue is being exploited. Our article on CVSS and real risk explains the gap.
Low scores can matter. A low rated flaw in a package that sits on an internet facing path can be more useful to an attacker than a critical flaw in code never run.
Why a blanket rule is risky
- It hides findings that later change status, such as when the issue becomes known to be exploited.
- It ends the paper trail. No record, no review, no end date.
- Combined flaws can be worse together than alone, and a blanket rule prevents anyone from seeing the pair.
- Auditors and customers ask what you do with low items. "Hidden" is a weak answer.
What to do instead
| Option | Effect |
|---|---|
| Lower priority queue | Findings stay visible but do not block |
| Batch fix with routine updates | Cleared in normal upgrade work |
| Gate threshold | Block on high and above, report the rest |
| Escalation rules | Move a finding up when reachable, exposed or listed as exploited |
| Targeted suppression | Only for reviewed findings with evidence |
A simple escalation rule set
Raise a low finding to a higher tier when any of these is true:
- The vulnerable code is reachable.
- The package is in a service that faces the internet.
- The vulnerability is on a known exploited list.
- Its exploit prediction score rises past your threshold.
- A second finding in the same package or path makes a chain plausible.
Review these conditions on each scan, not once.
Handling the volume
If low findings flood the list, the fix is better presentation and automation, not hiding. Group by package so one upgrade clears many. Let a bot open update pull requests for low items weekly. Measure the age of the oldest low finding so the queue does not become permanent.
Try it yourself
Click through it at your own pace, or open it full screen. See how a fix available finding can be cleared through an upgrade rather than a suppression.
What to tell leadership
Report low findings as a count with an age, not as a hidden pile. A statement like "we carry a number of low items, the oldest is 40 days old, and none are reachable" is more credible than a dashboard that shows zero because everything was muted.
Quick check
Can low findings be excluded from the build gate?
Yes. Setting the gate to block on higher severities is different from suppressing. The findings stay recorded and reviewed.
How long can low findings wait?
Set a policy window, for example the next routine upgrade cycle, and escalate if the finding becomes reachable or exploited.
Last reviewed: 19 October 2026.
