Why does an SBOM matter when something breaks? A constructed case

An SBOM matters most on the first bad day. It lets you answer "do we ship this component, in which versions, and where" without waiting for suppliers. It does not say whether the flaw is reachable or exploitable, so pair it with exploitability data. The case below is constructed, not a real program.

The constructed case

A fielded system built in the early 2000s has had software updates for twenty years. Its fire control unit runs a Linux-based image with a few hundred components. Some were added in 2009, some in 2016, some by a subcontractor nobody has called in years.

A critical flaw is published in a widely used open source library. The program office asks one question: do we have it?

What happens without an SBOM?

The prime contractor emails three subcontractors. One answers in four days that the library is "probably not present." Another says it is present in a build that may or may not match the fielded one. A third has since been acquired and nobody knows who owns the code.

Meanwhile, the library might sit inside a vendored copy in another component, with no package manager record. Searching source trees finds some copies and misses others.

CISA's guidance on Log4Shell shows this pattern in the real world. It told organizations to check products against known lists, scan file systems, include internally developed software, and look at third-party products and cloud services they cannot see directly. Early mitigation that covered only a limited set of assets left gaps.

What changes with an SBOM?

If each release shipped with an SBOM in SPDX or CycloneDX, tied to the exact build, the first hour looks different. A query returns every build containing the library, with versions. The team learns that two of six fielded configurations include it and that one of those includes a patched version already.

NTIA's SBOM resources cover both halves of this: the formats (SPDX, CycloneDX and SWID) and how SBOM data can flow down the supply chain to the people who need it.

What does the SBOM not tell you?

Presence is not exposure. A library can be linked but never called, or called only on an input path the system never sees. A VEX statement addresses this. CISA describes VEX as a way for a supplier to say whether a product is affected by a given vulnerability, so the supplier's analysis travels with the inventory.

An SBOM is also only as good as the build it describes. If it was generated from a manifest and not from the final image, vendored code and statically linked libraries can be missing.

How to check or apply this

1. Generate the SBOM from the built artifact or image, not just from source manifests, and store it with the release.
2. Record the exact build identifier in the SBOM so a fielded unit maps to one document.
3. Include vendored and statically linked components. Test this by planting a known library copy and confirming it appears.
4. Require subcontractors to deliver SBOMs in a machine-readable format, with the same naming for components.
5. Keep a place to record exploitability decisions per vulnerability and per product, in VEX form.
6. Run a drill: pick a past critical flaw and time how long it takes to list affected products.

Safeguard can generate SBOMs, scan dependencies and run reachability analysis, which speaks to the presence versus exposure gap above.

Open the exploitability check demo in its own page.

What about very old systems?

Long-lived systems are where SBOMs pay off most and are hardest to produce. Original build records may be gone, and some components have no upstream. A practical path is to scan the fielded image to recover a first inventory, mark unknown items honestly, and improve it at each update. A partial, honest SBOM is more useful than none, as long as it says what it does not cover.

Quick check

Sources

• NTIA, Software Bill of Materials
• CISA, Software Bill of Materials
• CISA, Apache Log4j Vulnerability Guidance
• CycloneDX, Capabilities

Last reviewed: 18 October 2026.