Ask for a build SBOM, because it is produced alongside the artifact you received, and ask the supplier to say which type it is. If a build SBOM is not possible, an analyzed SBOM of the delivered artifact is a reasonable second choice.
Start from your question
Different questions need different data.
- "Is this exact file we received affected by a new vulnerability?" You want build or analyzed data about that artifact.
- "What would we have to change in their code?" That is the supplier's problem, so source data matters to them, not to you.
- "What is running in our environment today?" That needs deployed or runtime data, which you may produce yourself from installed software.
Why build first
CISA's working group document lists these benefits for build SBOMs: confidence rises because the information is available during the build, they show more than source files alone, and the SBOM and the artifact can be signed by the same workflow. The limits are real too. The supplier may have to change its build process, and dynamically linked dependencies may be swapped at runtime.
When analyzed is the better ask
Legacy products, firmware and vendors without a modern build pipeline often cannot give you a build SBOM. An analyzed SBOM looks at the finished artifact, so it needs no access to the build. The document also notes it can help verify SBOM data from other sources and can find hidden dependencies other methods miss. The tradeoff is heuristics, so expect some omissions or approximations.
You can run this yourself. Generate an analyzed SBOM of what you receive and compare it with the supplier's build SBOM. Gaps are a conversation starter, not proof of bad faith.
What to write in the request
Keep it short.
- State the format you accept, such as SPDX or CycloneDX.
- State the minimum elements version you expect.
- Ask the supplier to name the SBOM type and the tool that made it.
- Ask how often it will be refreshed and how you will receive updates.
- Ask how unknown components and withheld data are marked.
What not to demand
Do not ask for a runtime SBOM of a supplier's production system as a routine deliverable. It needs a running system, can expose their environment, and some detail only appears after the system has run for a while. Ask for it only for a clear reason.
Once you have the file, use the supplier SBOM review checklist to test it.
Quick check
Is a source SBOM good enough for a buyer?
Rarely as the only evidence. The CISA document says source SBOMs can include components that never run and may miss platform libraries.
Should I accept an SBOM with no type label?
Accept it, but ask. Without the type you cannot judge what it can and cannot see.
Sources
- Types of Software Bill of Material (SBOM) Documents, CISA PDF
- FOSSA, CISA releases 2026 minimum SBOM elements
Last reviewed: 19 October 2026.
