One CVE appears in many scans because many services share the same cause: a base image, a library, or a build template. Group findings by that cause, not by service. Fixing the shared source once and rolling it out turns hundreds of tickets into a handful of changes.
What a root cause looks like
Think of three buckets.
- Shared base image: the vulnerable package lives in the operating system layer that many images inherit.
- Shared library: an internal or open source package that many services depend on.
- Shared template: a build file, chart or starter project that copied the same pinned version into every service.
A scanner reports per artifact, which is correct but noisy. The same finding on a hundred images is one fact, not a hundred.
How to group
| Group key | Finds | Fix once at |
|---|---|---|
| Base image name and digest | OS package findings | The base image |
| Package name and version | Library findings | The library or its parent |
| Template or chart | Config copy findings | The template |
| Advisory id | Everything for one CVE | Your campaign tracker |
Start with the advisory id to count the spread. Then drill into the cause with the other keys.
A short procedure
- Export findings with the service, artifact, package, version and layer.
- Sort by package and count distinct services.
- For OS packages, trace to the base image layer.
- For libraries, trace the dependency path to the parent.
- Create one work item per root cause, linking the affected services.
- Close the child findings automatically when the parent change deploys.
The work item is the thing humans manage. The findings are the evidence.
Pitfalls
Do not suppress findings just because they are grouped. A grouped finding is still open until the fix is deployed. Do not group across ecosystems without care, since the fix owners differ.
Also watch for findings that look identical but are not. The same package name at different versions can have different exposure.
What to track
Track distinct root causes open, not total findings open. The first number tells you how much work remains. The second tells you how big the fleet is.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are grouped and prioritised in one place.
Quick check
Is deduplication the same as suppression?
No. Deduplication groups the same cause. Suppression hides a finding. Only the first keeps the work visible.
Which metric should I report to leadership?
Open root causes and their age. It stays meaningful as the fleet grows.
Safeguard's vulnerability management and SBOM scanning aim to surface this, and a free scan shows a project view.
Last reviewed: 19 October 2026.
