SBOM searches return false matches because component names are not unique: the same name can exist in different ecosystems, forks and wrapper packages can share names, and tools spell names in different ways. Searching by package URL, including type and namespace, and checking each hit against the advisory removes most of them.
Common causes
| Cause | Example pattern | Fix |
|---|---|---|
| Same name, different ecosystem | A library name used in two package registries | Match on the purl type as well as the name |
| Different namespace | Two publishers with a similarly named package | Match the namespace |
| Fork or rebrand | A fork keeps the name but not the vulnerable code | Check the fork's own advisory or source |
| Wrapper or binding | A package that wraps a native library with a related name | Confirm which one the advisory covers |
| Case and separator differences | Underscores versus hyphens, upper versus lower case | Normalise per ecosystem rules before comparing |
| Substring search | Searching a short string that appears in many names | Use exact or prefix matching on the purl |
The Package-URL specification says purls are a standard way to identify packages across ecosystems, and that they are used in CycloneDX and SPDX SBOMs and in most vulnerability databases. Because the type, namespace and name are separate components, a purl search can be exact where a text search cannot.
Cutting the noise, step by step
- Take the identity from the advisory, not from memory. Note ecosystem, namespace and name.
- Build a purl prefix and search with exact or prefix match.
- Remove hits whose type or namespace differs.
- For each remaining hit, confirm the version against the affected range (see matching version ranges).
- For forks and wrappers, read the advisory to see exactly which package it covers.
- Log the removed hits with the reason, so the next person does not redo the work.
The opposite problem: false negatives
Do not over correct. An SBOM that records a component with no namespace, or with a name from a different source, may hide a real hit. When tools disagree about naming, run a second wider search and review the extra hits by hand. A few minutes of review is cheaper than a missed product.
Prevent it in future
Ask for purls in every SBOM you generate or accept, normalise names at ingestion, and store the original identifier alongside any cleaned version. If a supplier SBOM has no purls, consider asking for them; the related post on purl or CPE compares the two identifiers.
Quick check
Is a CPE search better than a purl search?
They answer different needs. Purls map cleanly to packages, and CPEs are common in some databases. Compare them in the post linked above.
Should we delete false matches from results?
Keep them in the record with the reason for removal. That evidence helps later and avoids repeat work.
Safeguard's SBOM and dependency scanning matches on package identity and can help cut this noise.
Sources
Last reviewed: 19 October 2026.
