Do not bulk-except them. A new scanner version or rule set can add hundreds of findings overnight, and the instinct to suppress them all is understandable. Group them, triage by exposure, fix the cheap ones, and give the rest short, grouped exceptions with a review date. A blanket suppression hides the findings you most need to see.
The findings are usually real but newly visible. Nothing about the code changed. Your knowledge did.
Step 1: Confirm what changed
Read the release notes. Did a rule get added, a database expand, or severity logic change? Re-run the old version on the same code if you can. If the count difference comes from a bug in the scanner, report it and wait. If it comes from better detection, proceed.
Step 2: Group, do not list
Hundreds of rows are unmanageable. Group by one of these:
| Grouping | Why it helps |
|---|---|
| Component | One upgrade closes many findings |
| Base image | A rebuild closes a whole layer |
| Rule or CWE | One code pattern fix repeats |
| Service | Assigns clear owners |
Most floods collapse into a few dozen actions once grouped.
Step 3: Triage by exposure
Rank groups by what an attacker can reach. Internet-facing services come first, then anything touching customer data. Check the CISA KEV catalog for any group that includes a known exploited CVE, and treat those as urgent. Reachability analysis can drop many findings in a library never called by your code.
Step 4: Fix the cheap wins
Patch-level upgrades and base image rebuilds often resolve a large share without much risk. Do these first. The remaining list gets shorter, and morale improves.
Step 5: Grouped exceptions for the rest
For findings you cannot fix now, write one exception per group, not per finding, as long as the reason and scope are truly shared. Each group exception names the asset set, the reason, the other controls, an owner and an expiry no longer than 60 days. If a group mixes different reasons, split it.
Step 6: Set a grace window in policy
Teams that hit this repeatedly can add a clause to policy: findings that appear only because of a scanner change get a defined intake window, for example 14 days for triage, before the normal SLA clock starts. Write the rule down so it is not improvised each time.
What to tell leadership
Say the count jumped because detection improved, show the grouped plan, and give a date for the next report. A fast, honest explanation keeps the spike from reading as a sudden decline in security.
Where Safeguard fits
Safeguard's dependency scanning groups findings by component and its reachability analysis helps remove ones that sit on code you never call, which shrinks a flood to a workable list.
Try it yourself
Click through it at your own pace, or open it full screen. Toggle the filter and watch the raw finding count drop, which is the same effect you want in step 3.
Quick check
Is it okay to suppress findings that are all low severity?
Only with a recorded group exception and an expiry. Low severity findings still need an owner and a review.
Does a scanner change reset the SLA clock?
Only if your policy says so. If it does, put the intake window in writing and apply it consistently.
Sources
Last reviewed: 19 October 2026.
