ASPM tools deduplicate by matching fields that identify the same issue across scanners: the vulnerability identifier, the affected component and version, and the location in code or image. When those fields agree, the findings merge into one record. When they do not, duplicates remain.
Why duplicates happen
Teams run several tools for good reasons. One reads dependency manifests, another inspects built container images, another reviews source. Their coverage overlaps, so one flaw can be reported two or three times, each with a slightly different label.
A duplicate is more than clutter. It inflates the backlog, creates multiple tickets for one fix, and makes severity look inconsistent.
What the matching looks at
Most approaches compare some combination of these fields:
| Field | Example | Why it helps |
|---|---|---|
| Vulnerability ID | A CVE or advisory identifier | Strongest signal when present |
| Component name | Package or library name | Confirms the same thing is affected |
| Version | Installed version | Separates old from patched |
| Ecosystem | Language or package manager | Avoids name collisions |
| Location | File path, image layer, repository | Ties it to one place in your estate |
Component identity is the hard part. The same library can be named differently by different tools. Standards for naming components, such as package URLs, make matching easier, and an SBOM gives a shared list to match against.
Where it goes wrong
- Missing identifiers. Code level findings often have no CVE, so matching relies on file and rule names, which is less reliable.
- Same flaw, different path. A library reached through two different parents may show as two findings. Whether that counts as one issue is a policy choice.
- Transitive versus direct. One tool may report the direct dependency and another the nested one that actually carries the flaw.
- Over merging. Aggressive rules can fold two different problems into one and hide the second.
How to test it yourself
- Pick five issues you know two tools both report.
- Check that each appears once in the platform, with both sources shown.
- Pick two issues that look similar but are different, and check they stayed separate.
- Ask what happens when you split or merge records manually, and whether that decision survives the next scan.
- Compare the ratio of raw findings to unique issues across a few repositories.
The fourth step matters most in practice. A merge that resets on every import will frustrate your team quickly.
Questions to ask in a demo
Which fields drive matching? Can I see why two findings were merged? Can I override it? How are code level findings without identifiers handled? These are factual questions and a clear answer is a good sign.
A worked example
Suppose a service uses a logging library at version 2.14. A dependency scanner reads the lockfile and reports an advisory against it. A container image scanner inspects the built image and reports the same advisory against the same library, with a different severity label and a different path.
The matching logic checks, in order:
- Same advisory identifier? Yes.
- Same ecosystem and component name? Yes, after normalizing the name.
- Same version? Yes.
- Same application? Both findings map to the same service via the build.
All four agree, so the two findings merge into one record with two sources. The record keeps both severity labels, and the platform picks one display value according to a rule you can see.
Now change one detail: the image scanner reports version 2.15, because the build step upgraded the library. Step three fails. The platform keeps two records. That is correct, because they describe two different versions. It is also a hint that your lockfile and image have drifted, which is worth fixing.
What to do with findings that never match
Some findings will not match anything. Typical causes are:
- Code level findings with only a rule name.
- Operating system packages that one tool names differently.
- Vendored libraries copied into a source tree, without a package manager record.
Do not force a merge. Keep these as their own findings, and make sure they still have owners and statuses. Tracking a few extra records is better than hiding a distinct problem.
Step by step: tuning a platform after the first import
- Export the list of merged records with their sources.
- Review twenty of them, five for each of the main sources.
- Look for wrong merges first. They are rarer but more harmful than missed merges.
- Look for missed merges next, and note the pattern, such as a naming difference.
- Ask whether the platform can add a mapping rule for that pattern.
- Re-run the import and check that your manual decisions survived.
Why this matters for metrics
If you report the number of open findings, deduplication changes the number. Record the date the matching rules changed, so a drop in the count is not mistaken for progress. A short note in your scorecard, such as "matching improved this month, count fell by consolidation," saves awkward questions later.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, which gives a consistent component list that findings can be tied back to. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a dependency is identified by name, version and ecosystem together.
Quick check
Does deduplication change the risk?
No. It changes how many records you manage. The underlying flaw is the same.
Why not match on severity?
Tools score the same flaw differently, so severity is a poor identifier.
Can two findings in different repositories be the same issue?
They can share a cause, such as the same library, while still being separate records that need separate fixes. Good tools link them rather than merge them.
Last reviewed: 19 October 2026.
