To deduplicate findings across scanners, pick a stable key for each finding type, merge findings that share it, assign each finding class to one owning tool, and send everything to a single triage queue. The aim is one ticket per real problem, with the other tools reported as extra evidence.
Why duplicates appear
The same flaw can be seen from several angles. A vulnerable npm package shows up in SCA from your lockfile and in container scanning from the image. A public storage bucket shows up in IaC scanning from the code and in CSPM from the live account. A secret in a config file can be flagged by a secrets scanner and by SAST.
Each tool then creates its own alert, often with a different title and severity. The developer sees three tasks for one change.
Choose a key per finding type
A key is the set of fields that makes two findings the same.
- Dependency vulnerability: package name, version and advisory ID, plus the repository or image.
- Secret: secret type and a hash of the value, never the value itself, plus location.
- Misconfiguration: resource identity and rule, using the code resource name where possible so IaC and CSPM findings can be linked.
- Code flaw: file, rule and approximate line, which shifts over time, so allow tolerance.
Assign ownership
Write a short table.
| Finding class | Owning tool | Others act as |
|---|---|---|
| App library vulnerability | SCA | Corroboration |
| OS package vulnerability | Container scanning | Corroboration |
| Credential | Secrets scanner | Corroboration |
| Cloud configuration | CSPM for live state, IaC for code | Link both |
The owner creates the ticket. The others attach their evidence and do not open new ones.
One queue, one severity
Normalise severity so a single issue does not read as high in one tool and low in another. Pick one scale, state how you map each tool to it, and whether context such as reachability or internet exposure can change it.
Watch for false merges
Do not merge by title or by text similarity alone. Two different vulnerabilities in one package are two findings. Test your merge rules on a week of data and sample the results by hand.
Where Safeguard fits
Safeguard's reachability analysis helps decide which dependency findings deserve attention, which reduces the number of tickets that survive triage.
Quick check
Should overlapping tools be removed?
Not necessarily. Overlap can catch a miss at another stage. The fix is merging and ownership, not removal.
Is title matching a safe merge rule?
No. Use stable identifiers such as package, version and advisory ID, and sample the results.
Last reviewed: 19 October 2026.
