A Practical Guide to SBOM (Software Bill of Materials)

• 1: SBOM Overview
• 1.1: SBOM Levels and Classification
• 2: Standards and Formats
• 2.1: Minimum Elements of an SBOM
• 2.2: Identifiers and Licenses
• 3: Regulatory Trends
• 3.1: EU Cyber Resilience Act (CRA)
• 3.2: India, Korea, and Other Jurisdictions
• 4: Adoption Roadmap
• 5: Tools and Automation
• 6: Vulnerability Management and VEX
• 7: Sharing and Governance
• 8: Recommendations and Checklist

1 - SBOM Overview

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.1 - SBOM Levels and Classification

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

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.

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).

2 - Standards and Formats

Since an SBOM requires machine readability, a standard format is necessary. Among the three formats specified by the US NTIA minimum elements, SPDX and CycloneDX split practical use between them. The third, the SWID tag, is used mainly in asset management; its role as an identifier is covered in Identifiers and Licenses.

SPDX

SPDX (System Package Data Exchange) is a project under the Linux Foundation. Version 2.2.1 became an international standard as ISO/IEC 5962:2021 in August 2021. It is worth noting that the current ISO standard refers strictly to version 2.2.1.

The Linux Foundation released SPDX 3.0 on April 16, 2024, introducing a structure of purpose-specific profiles. The approach layers Security, Build, Dataset, and AI profiles on top of a core model. The AI profile carries model training and characterization information, the Dataset profile carries data provenance and licensing, and the Security profile carries vulnerability identification, severity, exploitability, and mitigation plans. A patch release, 3.0.1, followed in December of the same year. Whether SPDX 3.x is being re-standardized with ISO had not been confirmed as of June 2026.

CycloneDX

CycloneDX is a full-stack BOM standard that originated at OWASP (Open Worldwide Application Security Project). Its distinguishing feature is native support for Vulnerability Exploitability eXchange (VEX) within the format itself. International standardization proceeded through Ecma International’s technical committee TC54. Version 1.6 was published as ECMA-424 1st edition in June 2024, adding a Cryptographic Bill of Materials (CBOM) and CycloneDX Attestations, and v1.7 was announced in October 2025 and standardized as ECMA-424 2nd edition in December 2025. v1.7 added post-quantum cryptography readiness, structured citations, and support for patent objects.

CycloneDX can express software (SBOM), hardware (HBOM), services (SaaSBOM), and machine learning models (ML-BOM) all within a single format.

Comparing the Two Formats

Table 1. Comparison of the two major SBOM standard formats (source: ISO/IEC 5962:2021, Linux Foundation 2024, Ecma International ECMA-424. Retrieved 2026-06-14)

The two standards differ in design philosophy. SPDX extends its scope of application through profiles, while CycloneDX expresses it through component types and auxiliary objects. Both, however, target the same problem in that they carry component identification, licensing, and dependency relationships. Whichever you choose, conversion tools exist between the two formats, so you can choose based on the format your trading partners require and the format your own tool chain supports well. If license compliance is the focus, SPDX is the familiar starting point; if vulnerability operations is the focus, CycloneDX is.

Next, we look at the minimum elements that define what a format must contain, and identifiers and licenses for consistently pointing to components.

Sources

ISO/IEC (2021). ISO/IEC 5962:2021 — SPDX Specification V2.2.1. The Linux Foundation (2024). SPDX 3.0 Release. https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases. Ecma International. ECMA-424 — CycloneDX Bill of Materials Specification. https://ecma-international.org/publications-and-standards/standards/ecma-424/. CycloneDX (2025). CycloneDX v1.7 Released. https://cyclonedx.org/news/cyclonedx-v1.7-released/. (All retrieved: 2026-06-14)

2.1 - Minimum Elements of an SBOM

Once a format is chosen, the next question is what that format must contain. The documents that define this floor are the US Minimum Elements series. Though they are recommendations, they function as the de facto standard for federal procurement, and SBOM requirements in the EU and other jurisdictions largely reference this same framework.

Lineage: From NTIA 2021 to CISA 2025

The National Telecommunications and Information Administration (NTIA) published The Minimum Elements For a Software Bill of Materials (SBOM) in July 2021, under the delegation of Executive Order 14028. The document organized the minimum elements into three categories: the data fields to track per component, automation support requiring a machine-readable format, and practices and processes covering generation frequency, depth, and the like.

Stewardship of the community’s work then moved to the Cybersecurity and Infrastructure Security Agency (CISA), and two lines of revision followed. One was the third edition (September 2024) of Framing Software Component Transparency, a reference document that defines attributes, which added License and Copyright Notice to the baseline attributes. The other was a revision of the minimum elements document itself: CISA released 2025 Minimum Elements for a Software Bill of Materials as a public comment draft in August 2025, with the comment period closing on October 3, 2025. As of June 2026, this revision remains in draft status, and the date of a final version has not been confirmed.

The Data Fields and Three Categories of NTIA 2021

The NTIA 2021 minimum elements set seven per-component data fields.

The three categories are as follows.

• Data fields: The seven items above — the basic information for tracking and identifying components.
• Automation support: Specified SPDX, CycloneDX, and SWID as standard formats for automated generation and machine readability.
• Practices and processes: Covers generation frequency, depth, handling of known unknowns, distribution and delivery, access control, and how errors are accommodated.

What the CISA 2025 Draft Adds

The CISA 2025 minimum elements draft expanded the data fields to reflect the maturing state of tooling. Four core elements were newly added.

Existing items were also revised. The roles of SBOM Author and Software Producer were distinguished, “Other Unique Identifiers” was updated to “Software Identifiers,” and the access control element, previously separate, was folded into the distribution and delivery item. The trajectory of License — entering as a baseline attribute in Framing 3rd edition and hardening into a data field in the 2025 draft — shows that the SBOM is establishing itself as primary data for open source license compliance, beyond a security inventory. Behind adding Tool Name, Generation Context, and Hash together lies the concern that an SBOM produced by an untrustworthy tool cannot itself be trusted. Tool integrity is covered in 5. Tools and Automation.

Practical Recommendations

The minimum elements are, as the name says, a floor. Organizations can, and should, add fields suited to their own purposes. Carrying CVE references and patch status for vulnerability identification, SPDX license identifiers and copyright notices for license management, and release and End-of-Life dates for lifecycle management, together in one SBOM, lets a single SBOM answer multiple operational questions. If you are introducing an SBOM for the first time, starting with the NTIA seven fields as a base but including the four new fields from the CISA 2025 draft — especially hash and license — from the outset saves the effort of rebuilding it later.

Sources

NTIA (2021). The Minimum Elements For a Software Bill of Materials (SBOM). https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf. CISA (2024). Framing Software Component Transparency, Third Edition. https://www.cisa.gov/resources-tools/resources/framing-software-component-transparency-2024. CISA (2025). 2025 Minimum Elements for a Software Bill of Materials (SBOM) (public comment draft). https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom. (All retrieved: 2026-06-14)

2.2 - Identifiers and Licenses

If the same component is named differently across SBOMs, automated matching breaks down, because there is no way for a machine to know that “Apache Tomcat,” “tomcat,” and “Apache Software Foundation Tomcat” are the same thing. This is why an identifier system that consistently points to components, and a convention for notating licenses with standard codes, are both necessary.

Three Identifiers: PURL, CPE, SWID

The three identifiers used together in practice serve different roles. They are not mutually exclusive, so recording them together where possible is recommended.

Table 1. Identifiers used together in an SBOM (source: purl-spec, NIST NVD, ISO/IEC 19770-2. Retrieved 2026-06-14)

A Package URL points to a component within a package manager ecosystem in the following format.

pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1
pkg:npm/lodash@4.17.21
pkg:pypi/requests@2.31.0

After pkg: come the ecosystem type (maven, npm, pypi, etc.), namespace, name, and version. Because the same component can be pointed to with the same string everywhere, it links automatically to vulnerability databases and license databases.

CPE was developed by MITRE in the mid-2000s and is now maintained by NIST. It notates products under a fixed naming rule and is used to look up the vulnerabilities (CVEs) corresponding to a product. SWID is a tag format standardized as ISO/IEC 19770-2 that structurally describes a product’s version and producing/distributing entity, and it is mainly used in asset management. The CISA 2025 minimum elements draft updating “Other Unique Identifiers” to “Software Identifiers” also reflects the maturing of this identifier ecosystem.

License Notation: SPDX License Identifiers

License management is one of the earliest use cases for an SBOM. Recording exactly which license each component is distributed under is what prevents obligation violations and conflicts in advance. Free-text descriptions cannot be matched automatically, so standard codes are used.

SPDX license identifiers assign each license a unique code such as Apache-2.0, MIT, or GPL-3.0-only. When multiple licenses apply together, they are combined with a license expression.

Apache-2.0 OR MIT
GPL-2.0-only WITH Classpath-exception-2.0
(MIT AND BSD-3-Clause)

OR indicates a choice among multiple licenses, AND indicates multiple licenses applying simultaneously, and WITH indicates combination with an exception clause.

The principles to follow in practice are as follows.

• The license of every individual component, not just the license of the product as a whole, must be visible.
• When encountering a license not on the standard list, assign it an identifier with a prefix indicating its source (for example, a LicenseRef- prefix) to track it.
• If the license text has been trivially modified but its meaning has not changed materially, use the same identifier as the original.
• Analyze license compatibility to identify in advance the conflicts that can arise when combining components under different licenses.

Even when a license field is auto-extracted by a tool, its accuracy is a separate matter. Precisely identifying non-standard licenses, handling dual licensing, and confirming compliance with licenses that carry field-of-use restrictions remain the responsibility of people and policy. The boundary of automation is covered in 5. Tools and Automation.

Sources

Package URL specification https://github.com/package-url/purl-spec. NIST. Common Platform Enumeration (CPE) https://nvd.nist.gov/products/cpe. ISO/IEC 19770-2:2015. SPDX License List https://spdx.org/licenses/. SPDX License Expressions https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/. (All retrieved: 2026-06-14)

3 - Regulatory Trends

The regulatory standing of SBOM differs by jurisdiction. The United States takes an executive-order pathway that leverages federal procurement, the European Union takes a directly effective legislative pathway, and most other countries remain at the stage of advisory guidelines. This section covers the United States first, followed by the EU Cyber Resilience Act and other jurisdictions such as India and Korea.

Regulatory Standing by Jurisdiction at a Glance

Table 1. SBOM regulatory standing in major jurisdictions (source: primary source for each item; collected June 14, 2026)

United States: Leveraging Federal Procurement

US SBOM policy originates from an executive order. On May 12, 2021, shortly after the SolarWinds incident, Executive Order 14028 (“Improving the Nation’s Cybersecurity”) was signed and published in the Federal Register as 86 FR 26633. Section 10(j) of the order defined SBOM as “a formal record containing the details and supply chain relationships of various components used in building software,” and Section 4(f) directed the Secretary of Commerce, working with NTIA, to publish minimum elements for an SBOM within 60 days. This was the moment SBOM was elevated from a recommendation of the research community to a candidate requirement for federal procurement.

Under this mandate, NTIA published the minimum elements in July 2021, and responsibility for the work subsequently moved to CISA. Under Office of Management and Budget (OMB) Memorandum M-22-18, CISA holds the authority to update the NTIA minimum elements and has focused on tooling and operationalization. The results are the 2024 Framing Software Component Transparency, Third Edition, and the 2025 draft revision of the minimum elements. Changes in the data fields between the two documents are covered in Minimum Elements.

It is important to understand the exact nature of the US pathway. Executive Order 14028 is the basis for guidance requiring vendors that supply software to the federal government to provide an SBOM; it is not a general statute that applies to all software. CISA’s two documents themselves state that they do not create new federal requirements. The normative standing remains that of a procurement criterion and technical reference. Nonetheless, because the vast federal procurement market operates on this basis, it functions as a de facto requirement for companies that supply software to the US government.

Figure 1. Lineage of US SBOM policy documents (source: Executive Order 14028, NTIA 2021, CISA 2024 and 2025; collected June 14, 2026)

Sources

The White House (2021). Executive Order 14028 — Improving the Nation’s Cybersecurity, 86 FR 26633. https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity. OMB (2022). M-22-18. https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf. CISA SBOM Resource Hub https://www.cisa.gov/sbom. (all accessed: June 14, 2026)

3.1 - EU Cyber Resilience Act (CRA)

The first major piece of legislation to establish SBOM as an explicit legal obligation is the EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847). Whereas the United States effectively mandates SBOM through the market of federal procurement, the CRA is a directly effective law that applies horizontally across products with digital elements.

Legal Basis of the SBOM Obligation

In the CRA, the SBOM obligation appears in Annex I, Part II (vulnerability handling requirements), point (1). Manufacturers must identify and document the vulnerabilities and components contained in a product, and as a means of doing so, the CRA specifies that they must “draw up a software bill of materials, in a commonly used and machine-readable format, covering at the very least the top-level dependencies of the product.”

Two points that matter in practice differ from the US pathway.

• The scope of the obligation is top-level dependencies: There is no obligation to expand the entire dependency tree; covering at least the top-level dependencies is sufficient. That said, going deeper than this is clearly the recommended direction.
• It is an obligation to retain and submit, not to disclose: There is no obligation to disclose the SBOM to the general public. It is sufficient to retain it so that it can be submitted when a market surveillance authority makes a reasoned request.

The core of the CRA is that producing an SBOM is not a recommendation but a legal obligation backed by a system of fines.

Implementation Timeline

Figure 1. Phased implementation timeline of the EU CRA (source: Regulation (EU) 2024/2847; collected June 14, 2026)

The CRA was published in the Official Journal on November 20, 2024, and entered into force on December 10, 2024. Its application is staged: the Article 14 obligation to report exploited vulnerabilities and severe incidents applies from September 11, 2026, and full application of the essential cybersecurity requirements, including SBOM, begins on December 11, 2027.

Absence of Format Implementing Rules and a Practical Reference Point

As of June 2026, no official CRA-level implementing rule for SBOM format has been published. This means there is not yet a document that establishes, as an EU-wide binding norm, which schema and fields must be used to conform to the CRA.

The current practical reference point is Technical Guideline TR-03183-2 v2.1.0, published in August 2025 by Germany’s Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI). This document provides specific field mappings for CRA-conformant SBOM for both CycloneDX and SPDX. Note, however, that this is a German guideline, not an EU-wide binding norm.

Considerations for Open Source

The CRA uses commercial activity as its applicability criterion, and in principle excludes non-commercial open source that is distributed free of charge without commercial activity. This is a mechanism to avoid imposing manufacturer-level obligations directly on open source maintainers. However, the obligations still apply in full to manufacturers who integrate open source into a product and supply it commercially, so obtaining and managing SBOMs for open source components remains the manufacturer’s responsibility.

Sources

European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng. European Commission, DG CNECT. Cyber Resilience Act. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act. BSI. Technical Guideline TR-03183-2. (all accessed: June 14, 2026)

3.2 - India, Korea, and Other Jurisdictions

Jurisdictions outside the United States and the European Union are generally at the recommendation stage. There is no legal enforcement or sanction, but these function as best practices that influence procurement and contracting practices.

India: CERT-In Technical Guidelines

The Indian Computer Emergency Response Team (CERT-In) published the Technical Guidelines on Software Bill of Materials (SBOM). This is a voluntary guideline aimed at government agencies, the public sector, essential services, and software producing and service companies, covering the value of SBOMs, best practices, minimum elements, and vulnerability tracking procedures. It has no legal force, but it influences government procurement and contracting practices.

In July 2025, CERT-In expanded this guideline to also cover Quantum BOM (QBOM), Cryptography BOM (CBOM), AI BOM (AIBOM), and Hardware BOM (HBOM). This is an example of how the bill of materials concept is spreading beyond software into cryptography, AI, and hardware. The expansion into AI BOM is covered further in 5. Tools and Automation and in the separate AI SBOM Compliance Guide.

The first edition of this guide began as a Korean translation of this CERT-In document. The current edition updates that skeleton with current primary sources from the United States and the European Union, and broadens it to a general practitioner’s perspective.

Korea: Software Supply Chain Security Guidelines

In Korea, the Ministry of Science and ICT, the National Intelligence Service, and the Korea Internet & Security Agency (KISA), among others, published the Software Supply Chain Security Guidelines 1.0 in May 2024. It recommends SBOM generation and vulnerability inspection procedures, and the use of the National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF).

However, this is only an administrative guideline, and Korea’s current legal system does not yet have legislation that imposes a mandatory reporting obligation at the product level, as the EU Cyber Resilience Act does. Even so, Korean companies exporting software to the EU and the United States must directly meet the requirements of those markets, so building SBOM capability is a practical necessity regardless of domestic regulation.

Practical Implications

The legal standing differs by jurisdiction, but the skeleton of the data required converges. A well-built SBOM system, built once, can satisfy the requirements of multiple jurisdictions at the same time. If the system is designed around the strictest requirement among your export markets (currently the EU CRA), the recommendations of other jurisdictions are largely subsumed within it.

Sources

Indian Computer Emergency Response Team (CERT-In). Technical Guidelines on Software Bill of Materials (SBOM), CIGU-2024-0002. https://www.cert-in.org.in/. Ministry of Science and ICT, National Intelligence Service, Korea Internet & Security Agency (2024). Software Supply Chain Security Guidelines 1.0. https://www.kisa.or.kr/. (all accessed: June 14, 2026)

4 - Adoption Roadmap

Introducing an SBOM program into an organization is not a one-time effort. A staged approach is more realistic: establish the foundation (Foundational), settle generation and integration into practice (Developing), and mature operations (Scaling). The stage breakdown below is the common framework presented by both the US NTIA and India’s CERT-In guidelines; the order of activities is only illustrative and can be adjusted to fit an organization’s security needs, timeline, and resources.

Figure 1. The three stages of SBOM adoption (source: reconstructed from NTIA 2021 and CERT-In technical guidelines; collected June 14, 2026)

Stage 1: Building the Foundation

The first SBOM an organization encounters is usually one received from a supplier during procurement. The purpose of this stage is to establish how the organization handles SBOM in the first place.

• Identify critical assets and establish a plan: Develop a plan that defines roles and responsibilities, timelines, and resource requirements, and obtain stakeholder buy-in for the new process.
• Decide on the format and minimum requirements: Before creating SBOMs, determine the format (SPDX or CycloneDX) and the minimum data requirements. This ensures a standard structure that can be processed consistently across the supply chain.
• Identify security requirements, storage, and tools: Define classification and handling procedures, and set up a secure repository for SBOMs.
• Obtain SBOMs through procurement: Specify the requirement for suppliers to provide SBOMs in purchase orders or contracts, and specify which elements are to be provided, when, and by what method.

Stage 2: Generation and Integration

This stage involves establishing secure configuration management, consistently referencing components with unique identifiers, and embedding generation itself into the development process.

• Assign unique identifiers: Pin each component with an identifier such as PURL so that traceability is not lost even if a supplier or component name changes, or a different version is released under the same name.
• Map supplier SBOMs to internal SBOMs: Create internal SBOMs based on the SBOMs suppliers provide, and record the author and timestamp to manage integrity and update history.
• Integrate with the SSDLC and CI/CD: Integrate SBOM generation into the Secure Software Development Life Cycle (SSDLC) and continuous integration/continuous deployment (CI/CD) pipeline. Generating SBOMs automatically at build time improves both accuracy and timeliness. See 5. Tools and Automation for tool selection.
• Secure configuration management: Apply access control, encryption, and regular audits to manage SBOMs securely.

Stage 3: Operational Maturity and Scaling

The final stage involves fully weaving SBOM into vulnerability management and incident response, and continuously updating the program.

• Strengthen vulnerability tracking: Establish a process for cross-referencing SBOM components against vulnerability databases to assess impact and mitigation. Detailed methods are covered in 6. Vulnerability Management.
• Integrate incident response: Establish a process for using SBOM to quickly determine, for a newly disclosed vulnerability, whether the organization is affected or has already been compromised.
• Maintain regular review and awareness: Periodically check that components and dependencies match the latest records, and keep the organization aware of new formats, data elements, and industry trends.

Choosing a Starting Point

Follow the three stages in order, but there is no need to aim for perfection from the start. A realistic first step is to pick one or two of the most important products, automatically generate SBOMs in the build pipeline, and feed them into a vulnerability scanner. Once you confirm the program works for one product, expanding it across the full portfolio reduces the cost of trial and error.

Sources

NTIA (2021). The Minimum Elements For a Software Bill of Materials (SBOM). CERT-In. Technical Guidelines on Software Bill of Materials (SBOM). CISA SBOM Resource Hub https://www.cisa.gov/sbom. (all accessed: June 14, 2026)

5 - Tools and Automation

An SBOM workflow is not completed by a single tool. The three capabilities of generation, vulnerability matching, and lifecycle management are split across different tools, and the common conclusion of recent tool comparison analyses is that no single tool covers all three areas completely. It is more accurate to think of it as assembling a pipeline from a combination of tools.

The Division of Labor Among Generation, Management, and Scanning

Figure 1. The three roles of SBOM tools (source: compiled from tool comparison analyses, 2026-01. Retrieved 2026-06-14)

In the generation space, Anchore’s Syft is regarded as “the dedicated tool that does SBOM generation, and only that, best.” Its attestation workflow, combined with the signing tool cosign, is mature. OWASP CycloneDX’s cdxgen is distinguished by broad support for multiple languages and container images, and by a dedicated AI BOM mode.

In the management space, OWASP Dependency-Track has established itself as a platform for monitoring component usage and security/license compliance across an organization’s entire application portfolio. Eclipse SW360 is another option centered on license compliance.

In the scanning space, Grype takes an SBOM as input and matches it against vulnerabilities, while Aqua Security’s Trivy is both a scanner and an SBOM generator.

Table 1. Classification of SBOM tools by role (source: compiled from tool comparison analyses, 2026-01. Retrieved 2026-06-14)

How Far Does Automation Go

It is important to honestly distinguish between areas where automation works well and areas that people must fill in.

Table 2. Automation maturity of SBOM tasks (source: compiled from tool comparison analyses. Retrieved 2026-06-14)

Tools do generation well. Put Syft or cdxgen into the build pipeline, and the component list fills in automatically. But whether the license field of a generated SBOM is accurate, whether the obligations of a non-standard license are met, and whether obligations propagate downstream without omission are things no tool guarantees automatically. This area is filled by policy and human review.

The Tool Itself Is an Attack Surface

Before trusting an automation tool, its own integrity must be verified. In January 2026, a case was reported in which an SBOM tool was implicated in two supply chain attacks within a short period, with the damage spreading to downstream projects. On this basis, some pipeline operators removed the tool in question.

The fact that an SBOM generation tool can itself become a target of supply chain risk requires combining hashes, signatures, and attestations at the generation and verification stages. This same concern lies behind CISA’s 2025 minimum elements draft adding Tool Name, Generation Context, and Component Hash as new fields. Avoiding the paradox that “an SBOM made by an untrustworthy tool cannot be trusted” requires pinning tool versions, verifying provenance, and signing the output.

Sources

Anchore. Syft https://github.com/anchore/syft, Grype https://github.com/anchore/grype. OWASP. cdxgen https://github.com/CycloneDX/cdxgen, Dependency-Track https://dependencytrack.org/. Aqua Security. Trivy https://github.com/aquasecurity/trivy. Eclipse SW360 https://www.eclipse.org/sw360/. (All retrieved: 2026-06-14)

6 - Vulnerability Management and VEX

The most direct use of an SBOM is vulnerability management. With a component list in hand, affected assets can be looked up immediately when a new vulnerability is disclosed. But listing components in an SBOM brings along every past CVE for those components, creating a problem of exploding false positives. Vulnerability Exploitability eXchange (VEX) is what solves this problem.

SBOM-Based Vulnerability Tracking

The basic flow of tracking is simple. Each component in an SBOM is matched against vulnerability databases (NVD, CVE) using an identifier such as PURL or CPE to map known vulnerabilities. A supplier can pre-map vulnerability information into an SBOM and provide customers with an enriched SBOM, while a consumer can link its own SBOM to vulnerability data through an API or data feed to set response priorities.

To increase effectiveness, a shift-left approach that moves checks earlier in development is recommended. Integrating security tools into the development pipeline and automatically analyzing SBOM data at early stages such as build and packaging catches vulnerabilities before release.

VEX: Sorting Out Exploitability

VEX is a document in which a manufacturer asserts “is this vulnerability actually exploitable in our product,” helping consumers make priority judgments. Where an SBOM answers “what is inside,” VEX answers “does a known vulnerability inside actually affect this product.” Even if a component has a vulnerability, it may be unexploitable if the affected code path is never invoked; VEX states this status explicitly, reducing unnecessary response effort.

A VEX document notates the vulnerability status of a specific product using the following four states.

• Not affected: No remediation is needed for this vulnerability.
• Affected: A fix or mitigating action is recommended.
• Fixed: The vulnerability fix is included in the given product version.
• Under Investigation: Whether the product is affected has not yet been confirmed and will be updated later.

VEX is not a single format; CSAF VEX, OpenVEX, and CycloneDX VEX coexist. CycloneDX is distinguished by expressing VEX natively within the format itself.

CSAF: Structuring Advisories

Common Security Advisory Framework (CSAF) 2.0 is a standard that structures security advisories in a machine-readable form, and it includes a VEX profile. OASIS approved it as a formal standard in November 2022. Where VEX communicates exploitability status, CSAF delivers a detailed advisory that includes a vulnerability description, affected versions, a severity assessment (CVSS score), and recommended mitigation steps.

The practical turning point for adoption was Red Hat. Red Hat’s Product Security team began publishing CSAF/VEX files for every CVE in its database in 2023, and has since moved to full production, publishing them on an ongoing basis.

Case Study: Log4Shell

The Log4j vulnerability (Log4Shell), disclosed in December 2021, is a case that shows how SBOM, VEX, and CSAF interlock.

Figure 1. The interplay of SBOM, VEX, and CSAF in the Log4Shell response (source: reconstructed from CERT-In technical guidelines. Retrieved 2026-06-14)

When the vulnerability was disclosed, maintainers issued a VEX stating the exploitable status, followed by a CSAF advisory containing the vulnerability description, affected versions, CVSS 10.0 (the highest severity), and mitigation steps. Organizations that included Log4j as a component integrated this VEX and CSAF data into their own SBOMs, identifying the affected parts of their systems and setting response priorities. The core point of this case is that, had an SBOM already been in place, “where is Log4j” could have been answered with a single query.

Sources

OASIS Open (2022). CSAF 2.0. https://www.oasis-open.org/2022/11/21/new-version-of-csaf-standard/. CISA. Vulnerability Exploitability eXchange (VEX). https://www.cisa.gov/sbom. OpenVEX https://github.com/openvex. NVD. CVE-2021-44228. https://nvd.nist.gov/vuln/detail/CVE-2021-44228. Red Hat (2023). VEX files now available. (All retrieved: 2026-06-14)

7 - Sharing and Governance

An SBOM creates value only when it is delivered along the supply chain, but it is also sensitive material that contains trade secrets and attack surface. Without governance that determines who shares what, and how, excessive disclosure heightens risk, and excessive restriction forfeits value.

Access Control and Disclosure Scope

Access to SBOM data is managed through Role-Based Access Control (RBAC). Because access needs differ by stakeholder, general users are granted read-only access, administrators are granted edit and update access, and sensitive information is granted restricted access.

For disclosure scope, maintaining two versions is common practice.

• Public SBOM: Contains non-sensitive information that can be shared with all stakeholders.
• Private SBOM: Contains sensitive information, such as vulnerabilities, and only approved parties can access it.

Regulation reflects this distinction as well. The EU Cyber Resilience Act does not require an SBOM to be disclosed to the general public, but requires it to be retained in case market surveillance authorities request it. Amid the tension between consumers wanting a more complete SBOM and producers wanting to reduce disclosure, the public/private split is a practical device that reconciles the two.

Secure Sharing Channels

When delivering an SBOM, both integrity and confidentiality need to be preserved.

• Use a secure protocol such as HTTPS for transmission, and ensure integrity and confidentiality through digital signatures or encryption.
• Use a sharing platform equipped with access control and audit capabilities.
• Use API integration for automated exchange between systems, and dedicated repositories for industry- or community-level sharing.

Attach a digital signature to the document so recipients can verify its authenticity and check for tampering, and clearly mark which information is public and which is private.

Roles and Responsibilities

An SBOM program works only when multiple departments share responsibility for it. It should include an executive sponsor, project leads, systems and design engineers, procurement specialists, and operations personnel, adding IT, cybersecurity, and maintenance staff as security needs require. When roles are scattered, responsibility scatters with them, so establishing clear ownership is the starting point.

The key activities in building governance are as follows.

• Identify key stakeholders: Include representatives from development, IT operations, security, procurement, legal, and business leadership, and be sure to include a cybersecurity expert.
• Define responsibilities and assign ownership: Decide who will handle SBOM generation and consumption, vulnerability monitoring, supplier engagement, and security data management, and designate a cybersecurity expert as the program owner or co-owner.
• Establish a governance structure: A governance body with participation from stakeholders across the organization develops policies, standards, and processes, and implements data protection controls.
• Train and monitor: Train personnel on SBOM security requirements and secure data handling, and continuously assess the program’s security posture through regular audits, adjusting it to evolving threats and compliance requirements.

Sources

CISA (2024). Framing Software Component Transparency, Third Edition. CERT-In. Technical Guidelines on Software Bill of Materials (SBOM). Regulation (EU) 2024/2847 — Cyber Resilience Act, Annex I Part II. (all accessed: June 14, 2026)

8 - Recommendations and Checklist

This section organizes the content covered in the preceding sections into practical recommendations and a checklist. Organizations adopting SBOM for the first time can follow the checklist in order, while organizations already operating one can use it to check for missing items.

Key Recommendations

Procurement and Generation

• When procuring software, specify the SBOM provision requirement in contracts and purchase terms. Specify which elements are to be provided, in what format, and when.
• Generate SBOMs in the SPDX or CycloneDX format, choosing based on your counterparty’s requirements and your own toolchain.
• Automatically generate SBOMs at build time within the SSDLC and CI/CD pipeline to ensure accuracy and timeliness.
• Put in place a workflow to regenerate the SBOM whenever a new component is introduced or an existing component is updated.

Data Quality

• Include complete metadata such as component name, version, license, and unique identifier. Because the minimum elements are only a floor, add fields to fit your own use case.
• Pin components with PURL or CPE so that traceability is not lost even when names or versions change.
• Pin the version of the generation tool, verify its provenance, and attach hashes and signatures to the output to ensure integrity.

Vulnerabilities and Licenses

• Link the SBOM to vulnerability databases and advisories to maintain continuous visibility into security posture.
• Reflect any applied patches or mitigations in your own SBOM.
• Exchange vulnerability exploitability status using VEX and CSAF, and prioritize response based on risk.
• Analyze the license compatibility of all components to identify conflicts that may arise from combining them, in advance.

Storage and Operations

• Store and transmit SBOMs securely using encryption and access control, and clearly distinguish between public and private scope.
• Check the accuracy and completeness of SBOMs through regular audits.
• Run training and awareness programs on the role of SBOM, from developers to the security team.

Adoption Checklist

A checklist for reviewing what has been done at each stage.

Next Steps

If you develop AI systems or exchange them across the supply chain, you need to add an AI-specific layer — models, datasets, and training compute — on top of the SBOM capabilities covered in this guide. The component, license, and vulnerability management practices of a general SBOM carry over directly into the software layer of an AI BOM. This is covered in detail in the separate AI SBOM Compliance Guide.

Sources

NTIA (2021). The Minimum Elements For a Software Bill of Materials (SBOM). CISA (2024). Framing Software Component Transparency, Third Edition. CERT-In. Technical Guidelines on Software Bill of Materials (SBOM). Regulation (EU) 2024/2847 — Cyber Resilience Act. (all accessed: June 14, 2026)