To find every product that ships a vulnerable component, search your stored SBOMs for the component's package URL (purl) and compare each version found with the advisory's affected range. Then confirm each hit against the real release, because an SBOM is a claim about a build, not proof about what customers run.
Why the purl is the key to the search
A package name alone is a weak search term. The same name can exist in several ecosystems, and tools spell names differently. The Package-URL specification describes a purl as a standard identifier built from a scheme, type, namespace, name, version, qualifiers and subpath, used in CycloneDX and SPDX SBOMs and in most vulnerability databases. If your SBOMs carry purls and the advisory names one, the match is a string comparison rather than a guess.
The search in five steps
- Get the exact component identity from the advisory: ecosystem, package name and affected versions.
- Build the purl without a version, for example the type, namespace and name only.
- Search every stored SBOM for components whose purl starts with that value, in direct and transitive positions.
- Compare each version found against the affected range (see the related post on matching version ranges).
- Map each SBOM back to a product, a release and, where you can, a customer-facing deployment.
Keep the output as a table so nobody redoes the work:
| Product | Release | SBOM source | Component version | Position | Verdict |
|---|---|---|---|---|---|
| Example app | 4.2.1 | CI build | 2.14.0 | transitive | in range |
| Example agent | 1.9.0 | CI build | 2.17.2 | direct | outside range |
Where the search goes wrong
Three failure modes show up repeatedly.
First, missing SBOMs. If a product has no stored SBOM for a shipped release, it will not appear in results, and silence looks like safety. List the products with no SBOM as a separate "unknown" group in the answer.
Second, shallow SBOMs. If an SBOM lists only direct dependencies, a transitive hit is invisible. Check whether your generator includes the full resolved tree.
Third, vendored or shaded copies. A library copied into your source or bundled into another artifact may not carry its original identity. Search source and binaries for known file names or class paths as a second pass for high-risk cases.
What to say when you are done
Report three groups: confirmed affected, confirmed not affected with the reason, and unknown with the owner and next step. That structure is more useful to leadership than a single number, and it is honest about gaps.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a single component appears under several parents.
Safeguard's SBOM and dependency scanning keeps an inventory you can query this way, and reachability analysis helps decide which hits to act on first. You can try the free scan at gold.safeguard.sh/scan.
Quick check
Is a package name enough to search SBOMs?
It is a start, but the purl is safer because it includes the ecosystem and namespace. Names alone can collide across ecosystems.
Does no match mean we are not affected?
Only if every shipped release has a complete SBOM. Products without an SBOM belong in an unknown group, not in the clean group.
Do transitive dependencies count?
Yes. A vulnerable component that arrives through another package ships in your product just the same.
Sources
Last reviewed: 19 October 2026.
