SBOM Overview

An overview of what an SBOM is and why it is needed, covering software supply chain threats and the benefits an SBOM provides.

1: SBOM Levels and Classification

What Is an SBOM

A Software Bill of Materials (SBOM) is a machine-readable list of all the components and libraries that make up a software product, along with the dependency relationships among them. It carries over the manufacturing concept of a Bill of Materials into software. Just as a finished vehicle has a specification sheet recording which parts came from which supplier, an SBOM records which open source and commercial components, at which versions, went into an application.

Most modern software is filled more with components brought in from outside than with code written in-house. Those external components can carry vulnerabilities, come with license obligations attached, and in turn depend on still other components. An SBOM makes this chain of dependencies visible, providing a common data layer that security, license management, and asset management can all reference.

Why It Matters: The Collapse of Supply Chain Trust

Two supply chain incidents raised the SBOM onto the policy agenda. In the SolarWinds incident that came to light in December 2020, attackers poisoned the legitimate update path of the Orion software itself. A backdoor spread along with that update to the many organizations that trusted and installed it. It was a structure in which a compromise at a single point upstream in the supply chain spread across the entire downstream.

A year later, in December 2021, a remote code execution vulnerability in the Java logging library Log4j (CVE-2021-44228, commonly known as Log4Shell) was disclosed. What this incident exposed was not a breach itself but an absence of visibility. Log4j was buried deep as an indirect dependency in countless products, so few organizations could give an immediate answer to the question, “where in our products does this library exist?” If every piece of software had already had a machine-readable component list in place, determining the scope of impact would have taken a single query. This experience gave direct momentum to the SBOM agenda.

After that, the SBOM moved beyond recommendation into regulation. The United States opened a path to requiring SBOMs for software delivered to the federal government through Executive Order 14028 in 2021, and the European Union made producing an SBOM a legal obligation through the Cyber Resilience Act (CRA). The detailed regulatory landscape is covered in 3. Regulatory Landscape.

Benefits of an SBOM

The value of an SBOM is not limited to security alone. The same data — a component list — serves multiple purposes at once.

Vulnerability management and incident response: When a new vulnerability is disclosed, affected components can be looked up immediately to set response priorities.
Supply chain risk management: The provenance and trustworthiness of external components are assessed and reflected in procurement and supplier management.
License compliance: Tracking the license of each component prevents obligation violations and conflicts in advance.
Regulatory compliance: Meets transparency requirements and provides the evidence needed for regulatory reporting and audits.
Asset management and operational efficiency: Knowing exactly what is in use makes lifecycle management easier.

Who Creates and Uses It

The value of an SBOM does not come from a single organization producing it alone; it is realized when it flows along the supply chain. The third edition of CISA’s Framing Software Component Transparency organizes the actors around an SBOM into three perspectives: producers (Produce) who make software, choosers (Choose) who select which software to use, and operators (Operate) who run it. It is common for a single organization to hold all three roles at once, as with a company that develops its own products while also bringing in external libraries and operating infrastructure.

The core of this structure is the chain of supplier-consumer relationships. When an upstream producer creates an SBOM and passes it downstream, the downstream chooser uses it to assess risk before adoption, and the operator looks up the scope of impact immediately when a new vulnerability is disclosed. What Log4Shell showed was precisely a break in this chain. Because producers had not passed along a component list, operators could not know what libraries existed in their own assets.

Interests diverge subtly across actors. Consumers want a deeper, more complete SBOM, while producers, concerned about trade secrets and attack surface exposure, want to narrow the scope of disclosure. Where regulation sets the floor of obligation, and how it adjusts the scope of disclosure, are the mechanisms that resolve this tension. Sharing and disclosure scope are covered in 7. Sharing and Governance.

The next section looks at levels and types according to the depth of information an SBOM carries.

Sources

The factual basis for this section is compiled in this guide’s background research materials. Executive Order 14028 (86 FR 26633, May 12, 2021), CVE-2021-44228 (NVD), and the third edition of CISA’s Framing Software Component Transparency (September 3, 2024) were used as primary sources. For the full set of sources, see 3. Regulatory Landscape and the bottom of each section.

1 - SBOM Levels and Classification

Summarizes SBOM levels based on the depth of information they contain, and classification based on when they are generated.

Not all SBOMs are the same. They are divided into levels based on how deep a dependency chain they cover, and classified based on the point in the software lifecycle at which they were created. Distinguishing these two axes makes it possible to clearly decide “which SBOM to require and which SBOM to produce.”

Levels by Depth of Information

Level	Description
Top-Level SBOM	A summary of the components directly integrated into or used by the product. Contains essential information such as component name and version.
Transitive SBOM	Includes not only direct dependencies but also the indirect (transitive) dependencies that those dependencies rely on in turn.
n-Level SBOM	Contains information hierarchically to an arbitrary depth (N levels), beyond the top-level overview.
Delivery SBOM	Describes all components and libraries included in a release or distribution package.
Complete SBOM	A complete inventory of all components, dependencies, and metadata present in a system.

An organization does not need to commit to a single level. A common approach is to tailor the SBOM delivered to consumers to a level that omits sensitive information while still meeting security requirements, while internally maintaining a complete-level SBOM to track vulnerability updates. This reduces the risk of exposing trade secrets and intellectual property while securing both supply chain transparency and internal resilience.

The regulatory floor for obligations is also expressed in the language of levels. The EU Cyber Resilience Act requires an SBOM that “cover[s] at the very least the top-level dependencies of the product.” There is no obligation to expand the entire dependency tree, but that is clearly the direction of recommended practice.

Classification by Point of Generation

The US CISA document Types of Software Bill of Materials (SBOM) divides SBOM into six types aligned with the stages of the Software Development Life Cycle (SDLC). For the same product, the information captured and its accuracy differ depending on when the SBOM was generated.

The six SBOM stages — Design, Source, Build, Analyzed, Deployed, and Runtime — follow the order of the software lifecycle, with later stages containing more information

Figure 1. SBOM classification by SDLC stage (source: CISA, Types of Software Bill of Materials (SBOM), 2023)

Design SBOM: Records the components planned at the design stage, before the components actually exist.
Source SBOM: Reflects the development environment and contains source files and dependencies.
Build SBOM: Generated during the build process and includes information on source, dependencies, and pre-built components.
Analyzed SBOM: Generated by inspecting the final artifact after the build.
Deployed SBOM: A list of software installed and configured on a specific system, taking the deployment environment into account as well.
Runtime SBOM: Monitors components while running, capturing dynamically loaded dependencies and external interactions as well.

The Build SBOM, generated at build time, is the most widely recommended in terms of accuracy and automation, because it records exactly what the build tool actually assembled. Generation timing and automation are covered in detail in 5. Tools and Automation.

Sources

CISA (2023). Types of Software Bill of Materials (SBOM). https://www.cisa.gov/resources-tools/resources/types-software-bill-materials-sbom (accessed: June 14, 2026). This is the primary basis for the classification of the six SBOM types (Design, Source, Build, Analyzed, Deployed, Runtime). For attributes and maturity stages, see CISA (2024). Framing Software Component Transparency, Third Edition. https://www.cisa.gov/resources-tools/resources/framing-software-component-transparency-2024. The EU Cyber Resilience Act’s top-level dependency requirement is based on Regulation (EU) 2024/2847, Annex I Part II(1).