An SBOM, a software bill of materials, tells you what components are inside a piece of software. It does not tell you whether those components have known flaws today, whether a flaw can actually be reached, or whether the vendor builds and supports the product well. Use it as a starting list, not a verdict.
What an SBOM is, in one sentence
CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components. Think of the ingredient list on food packaging. It names what went in. It does not say whether the food is fresh, safe for you, or cooked properly.
What it does not tell you
| Question you may have | Does the SBOM answer it? | What helps |
|---|---|---|
| What components are inside? | Yes | The SBOM itself |
| Does any component have a known vulnerability today? | Not by itself | Matching the SBOM against advisory data, repeated over time |
| Can that flaw actually be triggered in this product? | No | An exploitability statement such as VEX, or reachability analysis |
| Is the vendor fixing problems quickly? | No | Vendor advisories, release notes, a disclosure policy |
| Was the software built without tampering? | No | Build provenance and signing information |
| Is the SBOM complete and current? | Not guaranteed | Ask how and when it was generated |
Why a list goes stale
Software changes. A new release can add or swap components, and new vulnerabilities are found in old components all the time. An SBOM is a snapshot of one version. The ingredient list of last quarter's release says little about this quarter's.
CISA's 2026 joint guidance on minimum elements, published with the NSA, the FBI and international partners, sets a baseline for what an SBOM should contain. It replaces the 2021 NTIA minimum elements. CISA describes the minimum elements as a baseline of technologies and practices, not a complete standard, and notes that some software types, such as AI and cloud software as a service, may need additional elements.
How to use one well
- Ask which product version the SBOM covers, and when it was produced.
- Check that each component has a name and a version, so it can be matched to advisories.
- Run the list against current vulnerability data, and repeat on a schedule.
- For each finding, ask the vendor whether the product is actually affected. CISA mentions VEX as an attestation of whether products are affected by known vulnerabilities.
- Keep the SBOM with your records so you can answer "are we affected?" fast the next time a big flaw is announced.
What a good answer from a vendor looks like
A useful vendor reply names the product version, attaches the SBOM in a standard format, and says how often it is refreshed. It also states how you will be told when a component in it has a serious flaw. If the answer is only a PDF with no versions, you can read it, but you cannot check anything against it.
Where Safeguard fits
Safeguard generates SBOMs from your code and containers, scans the dependencies in them for known vulnerabilities, and uses reachability analysis to show which findings your code can actually reach. Policies and gates can then stop risky components from shipping. Try the inventory view below, or run the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click a component and compare what the inventory shows with what it leaves out, such as whether a flaw is reachable.
Quick check
If a vendor gives me an SBOM, is the product safe?
No. The SBOM shows what is inside. Safety depends on whether those parts have flaws that matter, and on how the vendor builds, tests and patches.
Does an SBOM list vulnerabilities?
Usually not. It lists components. Vulnerabilities come from matching those components against advisory data, ideally on a recurring basis.
Sources
Last reviewed: 19 October 2026.
