Skip to main content
Bureau of AI
Category: Third-Party & Supply Chain

Software Bill of Materials

Also known as:
Simply put

A Software Bill of Materials (SBOM) is a document that lists the components and dependencies used to build a piece of software, much like a list of ingredients on a food label. It helps organizations understand what is inside their software, including open source and third-party parts, so they can better manage security and supply chain risks. As commonly described, it is a building block for software security rather than a control that eliminates risk on its own.

Formal definition

As commonly defined by U.S. federal sources, an SBOM is a formal record containing the details and supply chain relationships of the various components used in building software. In practice it functions as a detailed inventory of components and dependencies, including open source and third-party components present in a codebase, spanning the development and delivery of software. It supports software supply chain risk management by providing component-level transparency; note that these definitions derive from cybersecurity and software supply chain contexts and are distinct from AI-specific model documentation or model risk management artifacts, though an SBOM may form one input among others when governing software that incorporates AI components.

Why it matters

Modern software is rarely built from scratch; it assembles open source libraries, third-party components, and dependencies, often nested several layers deep. Without an inventory of what those components are, an organization cannot reliably answer a basic question when a vulnerability is disclosed: does our software contain the affected component, and where? As commonly described in U.S. federal sources, an SBOM addresses this gap by providing component-level transparency, functioning as a building block for software supply chain risk management rather than as a control that eliminates risk on its own.

This transparency matters most during incident response and ongoing risk monitoring. When a widely used component is found to have a serious flaw, teams that maintain SBOMs can search their inventories to scope exposure quickly, whereas those without them may spend considerable effort simply determining what they run. It is important to keep expectations calibrated: an SBOM describes what is present, but it does not by itself detect, prioritize, or remediate vulnerabilities. Those activities depend on additional processes and tooling that consume the SBOM as one input among several.

For readers in AI governance and model risk management, note that an SBOM is a cybersecurity and software supply chain artifact, not an AI-specific document. It is distinct from model documentation, model cards, or model risk management artifacts. Where AI capabilities are delivered through software, an SBOM may form one input among others when governing that software, but it should not be treated as a substitute for model-level transparency, validation, or the governance controls specific to AI systems.

Who it's relevant to

Security and software supply chain teams
These teams use SBOMs as a building block for software supply chain risk management, relying on component-level inventories to scope exposure when vulnerabilities in open source or third-party components are disclosed. The SBOM supports, but does not replace, the detection, prioritization, and remediation processes they operate.
AI governance and model risk professionals
For those overseeing systems that incorporate AI components, an SBOM can be one input among others when governing the underlying software. It should be understood as a cybersecurity artifact distinct from AI-specific model documentation and from model risk management artifacts, and not as a substitute for them.
Auditors and compliance officers
An SBOM can provide documentary evidence of what software components an organization runs, supporting transparency-oriented reviews. Because formats and requirements can vary by context and by the guidance an organization follows, auditors should confirm which expectations apply rather than assuming a single universal standard.
Procurement and vendor risk functions
When acquiring software or services, teams may request an SBOM to understand the open source and third-party components included in a product. This supports supplier transparency and downstream risk assessment, while recognizing that the document describes what is present rather than certifying that it is free of risk.

Inside SBOM

Component inventory
A structured list of the software components, libraries, and dependencies that make up a system, typically including both direct and transitive dependencies where they can be identified.
Version and provenance information
Details such as component names, version identifiers, and, where available, the supplier or origin of each component, supporting traceability of what is actually deployed.
Dependency relationships
Information describing how components relate to one another, including which components depend on others, so that the impact of a given component can be traced through the system.
Licensing and metadata
Metadata that may include license information and other attributes associated with each component, though the completeness of such fields varies by tool and format.
AI/ML-specific extensions (where applicable)
In AI contexts, some practitioners extend the concept toward related artifacts describing models, datasets, or other assets; note that such extensions are an evolving practice rather than a settled, standardized part of a traditional software-focused SBOM.

Common questions

Answers to the questions practitioners most commonly ask about SBOM.

Does having a Software Bill of Materials (SBOM) for an AI system satisfy AI governance or model risk management requirements?
No. An SBOM is an inventory of software components and their dependencies; it is a transparency and supply-chain artifact, not a governance framework or a model risk management program. In many frameworks, an SBOM can support governance activities—such as component-level accountability and vulnerability tracking—but it does not by itself address model-specific concerns like validation, performance monitoring, bias, or the oversight structures typically expected under AI governance. Treating an SBOM as evidence of compliance conflates a component inventory with the broader controls those disciplines require.
Is an SBOM the same thing as a model inventory or 'model bill of materials' used in model risk management?
Not necessarily, and the terms should not be blurred. An SBOM traditionally documents software packages, libraries, and their versions and dependencies. A model inventory, as commonly maintained in model risk management, tracks models as risk objects—their purpose, owners, validation status, and use—rather than software components alone. Some organizations are extending SBOM concepts to capture model-specific artifacts (for example, datasets, weights, or training pipelines), but this usage is evolving and not standardized, so the two artifacts serve different primary purposes and should be scoped separately.
What components would an SBOM for an AI or machine learning system typically capture?
An SBOM typically enumerates software components and their dependencies—libraries, frameworks, and packages with their versions and, where available, supplier and license information. For AI systems, practitioners often discuss extending or supplementing this with information about datasets, model artifacts, and pipeline tooling. Because standardized formats for capturing model-specific elements are still developing, organizations should be explicit about what their SBOM does and does not cover, and avoid assuming it captures data or model provenance unless those fields are deliberately included.
How does an SBOM fit into the lines-of-defense structure for AI oversight?
An SBOM is generally produced and maintained by the first line—the teams that build or operate the system—as part of documenting what a system contains. Second-line functions may use SBOM information to assess supply-chain and dependency risk, and third-line or audit functions may rely on it as evidence when testing controls. The artifact itself does not perform oversight; it is an input that different lines can use for their respective monitoring and challenge activities. Its usefulness depends on being kept current.
How often should an SBOM be updated once an AI system is in production?
An SBOM reflects the state of a system's components at a point in time, so its value degrades as dependencies change through updates, patches, or retraining. In many practices, organizations regenerate or update the SBOM when the underlying components change materially—such as on new releases or dependency updates. There is no single universally mandated cadence; the appropriate frequency depends on the organization's change-management process and the risk profile of the system. An outdated SBOM can create a false sense of assurance.
Can an SBOM help identify vulnerabilities or licensing issues in an AI system's dependencies?
An SBOM can support this by providing a component and version inventory that can be cross-referenced against known vulnerability sources and license terms. It enables that analysis rather than performing it—the SBOM lists what is present, while separate scanning, review, and monitoring processes interpret the risk. Its effectiveness is limited by completeness and accuracy: undocumented components, transitive dependencies, or model-level artifacts not captured in the inventory can leave gaps, so an SBOM reduces but does not eliminate the risk of undetected issues.

Common misconceptions

An SBOM is a security control that makes software safe or eliminates supply chain risk.
An SBOM is primarily an inventory and transparency artifact. It supports risk identification and response but does not by itself remediate vulnerabilities or eliminate risk; it is a measure that helps manage and reduce risk when paired with monitoring and action.
An SBOM fully captures every component and dependency in a system.
Completeness depends on the tooling, build process, and depth of dependency resolution. Transitive dependencies or components introduced outside tracked build pipelines may be missing or incompletely described, so an SBOM should be treated as an aid rather than a guaranteed exhaustive record.
A software-focused SBOM is the same as documentation of an AI model's datasets, training data, or model behavior.
A traditional SBOM focuses on software components and dependencies. Documentation of models and datasets is a related but distinct concern; extending SBOM concepts to AI artifacts is an emerging and not yet uniformly standardized practice, and the two should not be conflated.

Best practices

Generate SBOMs automatically as part of the build and release pipeline so the inventory reflects what is actually deployed rather than a manually maintained approximation.
Regenerate and update the SBOM whenever components or dependencies change, treating it as a living artifact rather than a one-time deliverable.
Capture transitive dependencies where feasible, and document known limitations or gaps in coverage so consumers understand what the SBOM does and does not include.
Use the SBOM to support vulnerability identification and response, but pair it with monitoring and remediation processes rather than treating it as a standalone security control.
Record version and provenance information consistently so components can be traced back to their source when investigating issues.
Where AI or model-related assets are in scope, clearly distinguish traditional software components from any model or dataset documentation, and note that such extensions reflect an evolving, non-standardized practice.