When a supplier will not provide an SBOM, narrow the ask, make it easy to say yes, and put it in the contract. If that fails, build your own inventory from what you can observe and record the gap as a risk. A refusal is information you can act on, not a dead end.
Find out why they said no
Reasons differ, and the fix differs with them.
| Reason | What it usually means | Try this |
|---|---|---|
| "We do not have one" | They never generated it | Offer a format and a sample, ask for a date |
| "It is confidential" | Worry about exposing internals | Offer an NDA or a limited scope |
| "We only share summaries" | A policy, not a technical limit | Ask which fields the summary omits |
| "Our customers never ask" | Low pressure so far | Cite your policy and renewal date |
| Silence | No owner for the request | Find the security contact |
Steps
- Ask for a specific thing: an SBOM for the product version you run, in CycloneDX or SPDX, with the common minimum fields. Name the version.
- Offer a path that is easy for them: a secure transfer, an NDA, quarterly updates instead of every release.
- Ask a smaller question if the full file is blocked: are specific components, named in a recent advisory, present in the product?
- Put it in writing at renewal. A clause that requires an SBOM on request, plus a notice when a listed component has a serious flaw, gives the ask weight.
- Record the gap. In your risk register, note the supplier, the product, the missing evidence and the date you asked.
Build your own picture
You can often approximate an inventory yourself:
- Scan installed software or container images you run to list components and versions.
- Read the vendor's public documentation, release notes and open source notices, which often name libraries.
- Scan a software package you hold, such as an installer or image, with a tool that can read compiled artifacts.
This is weaker than a supplier SBOM. Binary analysis can miss components or guess versions, so treat results as leads and ask the supplier to confirm.
Decide on risk, not principle
How hard to push depends on what the product touches. A tool with network access and admin rights deserves more insistence than a calendar plugin. Ask who else could replace the product, and what you would lose by waiting.
Try it yourself
Click through it at your own pace, or open it full screen.
See what an inventory built from scanning looks like, and note which fields you would still ask the supplier to confirm.
Quick check
Can I require an SBOM from an existing supplier?
You can ask at any time, but a contract clause at renewal is what makes it dependable.
Is my own scan a substitute?
It is a stopgap. It shows what you can observe, not what the supplier built.
Safeguard's SBOM and dependency scanning can build a component inventory from what you run, and a free scan is available at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
