To dedupe one CVE across many environments, group findings by the vulnerable component and version, then by the build artifact that contains it, and only then list the places that artifact runs. Ten servers running the same image are one fix with ten rollouts, not ten findings.
The cause of the pile
Most scanners report per asset. If a container image runs on forty hosts, a per host report shows forty rows for one problem. Add staging and production in several accounts and the count looks frightening and means little.
Duplicates also hide real differences. The same CVE in production and in a test sandbox is one component but two different risks, so the grouping must keep environment as an attribute rather than dropping it.
A grouping ladder
- Finding key: the advisory identifier plus the component name and version.
- Artifact: the image digest, function package or machine image that holds the component.
- Service: the application that builds that artifact.
- Deployments: the environments and accounts where the artifact runs.
- Owner: the team on the service record.
Work from the top. One finding key becomes a handful of artifacts, a few services and a longer list of deployments. The fix happens at artifact level, and tracking closure happens at deployment level.
What the grouped view looks like
| Level | Count in a sample estate | Action |
|---|---|---|
| Raw rows from per host scans | Many | Do not work from this |
| Finding keys | Few | Decide priority once |
| Artifacts | More | Rebuild once each |
| Deployments | Most | Roll out and verify |
The counts depend on your estate, so measure yours instead of borrowing a ratio.
Dedupe rules that avoid mistakes
- Do not merge findings across different versions of a component, because the fix differs.
- Do not merge across digests when a rebuild changed the content, even if the tag matches.
- Keep the environment so you can set priority by exposure and data sensitivity.
- Keep a first seen date per deployment, so age is honest.
Pair dedupe with relevance
After grouping, ask whether the vulnerable code can be reached by the service. Reachability analysis narrows the fix list further. The CISA Known Exploited Vulnerabilities catalog is described as an input to prioritisation, so mark any finding key listed there before ordering the queue.
Try it yourself
Open the demo and compare the full findings list against the reachable subset. Notice how much shorter the working list becomes once relevance is applied.
Click through it at your own pace, or open it full screen.
Quick check
Should staging findings be hidden once grouped?
No. Keep them as deployments under the same finding, with a lower priority if the environment justifies it.
Why not dedupe by CVE identifier alone?
One CVE can affect several components and versions, each with a different fix, so the identifier alone merges things that need separate work.
Safeguard's reachability analysis and dependency scanning are built for this narrowing. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
