Software Bill of Materials

A software bill of materials records software components and their supply-chain relationships. NIST describes the component record, while CISA emphasizes its nested structure: a product incorporates components that can themselves incorporate others.

That nesting matters when an advisory names a transitive dependency rather than a library the application team selected directly. Record the relevant component relationships so the search can follow those dependencies.

What it lets you answer

An inventory becomes useful when it supports questions about an identifiable artifact and its deployments:

1. Does this artifact contain component X at version Y? The advisory arrives naming a library, and this is the first thing someone asks.
2. Which running services contain it? This requires joining the record to what is deployed, which is a different data set from the record itself.
3. What changed between these two releases? A diff of two inventories finds the component that arrived without a pull request, which is how a transitive addition becomes visible.

The second question requires deployment records. An accurate inventory for a build cannot tell you where that build runs unless it is joined to an environment’s deployed artifact identity.

Presence is not a verdict

A component listing alone does not determine whether vulnerable code is included, reachable, or exploitable under the product’s configuration. CISA describes Vulnerability Exploitability eXchange (VEX) as a way to record whether identified products are affected by known vulnerabilities. That conclusion needs supporting analysis beyond a name match.

Treating every inventory match as proof of exploitability can misdirect investigation. Conversely, an incomplete inventory can miss affected components. Preserve the applicability assessment and its assumptions so later readers can check or revise the conclusion.

Where it is generated changes what it says

Inventories can differ because they use different inputs, tool support, and inclusion scopes, even when generated for the same release. Generation location is only part of that explanation.

Generated	Sees	Misses
Build integration using resolution records and observations	Resolved versions and fetches captured by the integration	Unobserved script downloads, unsupported ecosystems, and whether every input remains in the final artifact
Finished artifact or image analysis	Components the scanner recognizes in the inspected bytes, including supported base-image packages	Unrecognized vendored, linked, or renamed code, and dependencies loaded later
Source repository analysis	Manifest declarations and, where supported lock files or submitted graphs exist, resolved direct and transitive versions	Proof that the actual build followed those records or that every listed dependency shipped

Combine build observations and artifact analysis where their coverage is complementary, and attach the inventory to the build artifact digest it describes. GitHub’s dependency graph documentation shows that source-based inventories can include lock-file and submitted dependency data. They still need reconciliation with the delivered bytes. Check tool coverage for vendored source, statically linked libraries, script downloads, and inherited container image contents; combining tools does not by itself prove completeness.

Making it usable rather than compliant

Automated generation for release candidates reduces gaps between releases and their inventories. An on-demand inventory can also be accurate if it inspects the same artifact with adequate coverage; age alone does not make a record stale. Store the record by artifact digest, preserve its generation scope and tool information, and make it queryable with deployment records across the estate.

A dependency lock file directs resolution, while an artifact inventory describes observed components. An SBOM can include creator and generation metadata, but neither record replaces authenticated build provenance tying an artifact to its build process. The wider component and process controls belong to software supply chain security.

One caution for planning: the guidance on what an inventory must contain is being revised, with updated minimum elements and separate guidance for artificial intelligence systems published alongside the original. Treat the field list as something to check at the time you implement rather than as settled.

How inventories, provenance, dependency resolution, and pipeline permissions fit together across the development lifecycle is worked through in The Pipeline Had the Keys.

References

• NIST Computer Security Resource Center Glossary, software bill of materials. The definition is attributed on the page to NIST SP 800-161r1-upd1, drawing on Executive Order 14028.
• CISA, Software Bill of Materials (SBOM), including the description of Vulnerability Exploitability eXchange documents and the notices of updated minimum elements guidance.
• GitHub Docs, Dependency graph