To find which products use a library, search every stored SBOM by the library's package URL or ecosystem and name, filter by the affected version range, and report product, release and dependency path. This works only if SBOMs are stored per release and indexed by identifier.
The question behind the question
When a new advisory is published, leaders ask one thing: are we exposed? That breaks into smaller questions that a good SBOM store can answer.
- Which products and releases contain the component?
- At which versions?
- Is it a direct or a transitive dependency?
- Is the vulnerable code reachable in our use?
- Which of those releases are live in customer hands?
The method
- Normalise the target. Write the ecosystem, the name and the affected version range from the advisory. Use the package URL form where the advisory gives one.
- Search by identifier first, name second. Names collide across ecosystems. Identifiers do not.
- Handle version ranges. Comparing versions as text fails. Version ordering rules differ per ecosystem, so use a tool that understands them.
- Include nested and transitive components. A flat search of direct dependencies misses most hits.
- List per release. One product with three supported releases is three answers.
- Record the dependency path. Knowing which parent pulls the library in tells you where the fix must go.
- Mark unknowns. Products with no SBOM, or an incomplete one, are not safe. They are unknown. See known unknowns explained.
Why spreadsheets struggle
A sheet can answer this for one product with a filter. Across twenty products you open twenty files, and version range logic by hand invites mistakes. Names with different spellings hide hits. The answer takes hours at the moment you have minutes. A platform that holds every release in one searchable index can return the list immediately, and can keep the query to rerun later.
A table of pitfalls
| Pitfall | Effect | Fix |
|---|---|---|
| Searching by name only | False hits and misses | Search by package URL |
| Text compare of versions | Wrong range | Use ecosystem aware comparison |
| Direct dependencies only | Missed transitive hits | Search the whole graph |
| Latest SBOM only | Old live releases missed | Search every supported release |
| Shaded or bundled copies | Component not listed | Check for bundled libraries, see shaded dependencies |
After the list: triage
A list of affected releases is not yet a plan. Add reachability, exposure and fix availability. Then pick an order. The post on matching components to vulnerabilities covers the matching side.
Practice the query
Pick a well known past advisory and run the search against your store. Time it. Note what broke. Repeat each quarter. The drill is cheap and shows exactly how fast you could respond.
Where Safeguard fits
Safeguard's SBOM and dependency scanning feeds an inventory you can query, and its reachability analysis helps separate reachable usage from the rest. Start with the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
After finding a component, look at what the check says about whether it can actually be exploited in context.
Quick check
Is a name search enough to find a library across SBOMs?
No. Use the package URL or ecosystem plus name, because names repeat across ecosystems.
What about products without an SBOM?
Treat them as unknown, list them separately and generate SBOMs for them first.
Last reviewed: 19 October 2026.
