Ask for one SBOM per product and version you actually run, not one for the whole catalog. Add a product to the list when you adopt it. A narrow request is faster for the supplier to answer and easier for you to keep current.
Why scope matters
Large suppliers sell dozens of products built from different codebases. A single company-wide SBOM, if one exists, tells you little about the specific product in your environment. The NTIA minimum elements report describes a piece of software as a hierarchical tree of components, each of which can have its own SBOM. Your unit of interest is the product you deploy.
Asking for everything also looks like a compliance exercise, and suppliers respond to it that way.
Step by step
- List what you run. From your own inventory, not from the supplier's brochure. Include product name, version and where it runs.
- Mark what you use directly versus indirectly. A platform you configure is direct. A library bundled inside another vendor's product is indirect, and the SBOM request goes to that vendor.
- Request per product and version. Say which version you run. A request for "the SBOM" gets whichever file is closest to hand.
- Ask about shared components. Some products share a core. If so, one SBOM may cover several, but confirm in writing.
- Set a refresh trigger. New SBOM on new release of that product, as the NTIA report describes under frequency.
- Add on adoption. Make SBOM request part of the checklist when a team starts using another product from the same supplier.
Example
| Supplier product | You run it? | Request |
|---|---|---|
| Product A 6.1 | Yes, production | SBOM for 6.1, refresh on release |
| Product B 2.0 | Yes, pilot | SBOM for 2.0, review before production |
| Product C | No | Nothing |
| Product D | Via a reseller | Ask the reseller who produces the SBOM |
Bundles and suites
A suite may contain several programs under one name. If the supplier gives you one SBOM for a suite, check whether it lists the programs as separate components with their own dependencies, or collapses them into one list. A collapsed list loses the structure you need to trace a component to a particular program.
What if the supplier insists on a single document
Accept it, but ask them to mark which products each component belongs to. If they cannot, record the limitation. You will be able to search it, but not narrow results to one product.
Keep an index
Maintain a simple table: supplier, product, version, SBOM date, format, owner. When the next advisory arrives, you search the table first to see which products might contain the component. Refresh dates tell you which files to distrust.
Safeguard's SBOM and dependency scanning can scan each product's file you collect, and the free scan is at gold.safeguard.sh/scan.
Quick check
Should we ask for every product the supplier sells?
No. Ask for the products and versions you run, and add more as you adopt them.
What about a product we get through a reseller?
Ask the reseller who produces the SBOM and how you receive it. The component information usually originates with the product maker.
Sources
Last reviewed: 19 October 2026.
