An SBOM, or software bill of materials, is an ingredient list for a piece of software: the components inside it and their versions. It tells a buyer what is in the product, so they can check it against newly discovered flaws and license terms. It does not say whether the product is safe.
The two minute version
"Think of the label on food. It lists ingredients, so if one is later recalled, you know whether you have it. An SBOM does that for software. When a flaw is found in a popular component, a buyer with the supplier's SBOM can see whether it is inside."
Then say what it is not: "It is a list, not a verdict. It does not say whether the ingredients were used safely, or whether a flaw can be reached."
What it contains
| Item | Why it matters to a non-engineer |
|---|---|
| Component names and versions | Lets you match against flaw announcements |
| Supplier or origin | Shows who made each part |
| License for each component | Flags terms that affect distribution and obligations |
| Relationships | Shows what is inside what |
| Date and author of the list | Shows how current it is |
Common formats are SPDX and CycloneDX. A lawyer does not need to read either. They need to know a machine readable format exists, so the list can be checked automatically.
Why legal and procurement care
Contracts. You can ask for an SBOM on delivery and on request after changes, and for a notice period if a serious flaw is found in a listed component.
Licenses. The list helps check whether components carry terms that conflict with how you use or distribute the software.
Due diligence. It gives a factual basis for supply chain questions instead of relying on promises.
Incident response. After a headline vulnerability, the first question is "do we have it". An SBOM answers that in minutes instead of weeks.
What to ask a supplier
- Do you produce an SBOM for each release, and in which format?
- Can we receive it, and how often is it updated?
- Does it include nested components and not just direct ones?
- Will you tell us if a listed component has a serious flaw that affects the product?
- Can you also share a statement of whether known flaws are exploitable in your product, such as a VEX statement?
Question five matters because an SBOM alone will list many components with known issues that do not apply. A companion statement keeps the buyer from chasing false alarms.
Limits to state clearly
An SBOM may be incomplete. It reflects a point in time. It does not cover services the product calls. And it does not prove anything about how the software was built unless paired with other evidence. Say these limits out loud so nobody treats it as a guarantee.
Try it yourself
Click through the dependency inventory demo to see what a component list looks like and how it ties to findings.
Click through it at your own pace, or open it full screen.
Safeguard generates SBOMs and scans dependencies, and the free scan at gold.safeguard.sh/scan is a way to see one for your own project.
Quick check
Does an SBOM prove software is secure?
No. It lists components. Security depends on what flaws affect them and how they are used.
Do I need to read the SBOM file myself?
No. Ask the technical team to check it with tools, and ask them to summarise the result.
Last reviewed: 19 October 2026.
