TL;DR overview

• Software Bill of Materials (SBOM) serves as a vital compliance artifact that documents software composition to help organizations manage open-source risks, satisfy regulatory requirements, and accelerate vulnerability management.
•  Code verification tools provide essential software composition analysis to map dependencies, track security risks, and export compliant inventory formats.
• Major global frameworks explicitly mandate these machine-readable inventories to enforce supply chain transparency.
• While some regional frameworks don't mandate the artifact by name, they heavily rely on its underlying functionality for robust asset management and supplier registries.

Software Bill of Materials (SBOM) has been used for years in software supply chain security policy, procurement, and related compliance settings, and it is now appearing more explicitly in broader software regulation. It is recognized as a compliance artifact because it gives organizations a structured way to document software composition, manage third-party and open-source risk, and respond more effectively to vulnerability, procurement, audit, and regulatory requests. This page looks at what SBOM is from a compliance standpoint, how it fits into SonarQube, and which major active and near-active instruments require it or use it as a control artifact. 

For a deeper dive into what SBOM is from technical POV, visit the SBOM Developer Guide. 

What is an SBOM and why does it matter for software security?

An SBOM is a formal, machine-readable inventory of the components inside a software application or product. It records packages, libraries, modules, versions, and related dependency information so teams can see what the software is actually built from.

Modern software is rarely only built with first-party code. It usually combines internal code with open-source, commercial, and third-party components, which means security and compliance depend partly on the components an organization brings into the product, not only on the code it writes itself. In practice, that makes SBOM useful for vulnerability response, dependency governance, supplier review, procurement and audit evidence, and general software supply chain transparency. 

Put simply, SBOM is a machine-readable inventory of the software components inside a product or application, used to support vulnerability management, third-party risk control, and software supply chain security transparency. 

Why does SBOM matter for software security and compliance?

SBOM matters because a large share of modern software risk sits in dependencies and third-party components. When a vulnerable library is disclosed, teams need to know quickly whether it is present, where it sits, and whether it affects the product they ship. Since the broad introduction of AI has reduced time to exploit from weeks to days (and projected to reach hours), the ability to quickly navigate component structure is imperative.

That is also why SBOM appears in procurement, medical-device cybersecurity, software supply chain guidance, and broader product security regulation. It gives regulators, buyers, and assessors a structured way to ask what is in a product and whether the organization can manage the resulting risk.

Which regulations require an SBOM?

The SBOM compliance landscape is best read in two layers. The first layer contains instruments that explicitly require an SBOM or directly operationalize it as a compliance artifact. The second contains adjacent regimes that do not require an SBOM by name, but do require organizations to control software components, dependencies, supplier software, provenance, or lifecycle updates in ways that an SBOM can help support.

Regulations that require SBOM are:

• EU Cyber Resilience Act
• U.S. FDA cyber-device requirements under section 524B
• U.S. federal procurement framework after OMB M-26-05
• Australia’s ASD Information Security Manual software development guidance
• Japan’s MHLW and PMDA medical device cybersecurity materials

Jurisdiction / instrument	Legal force	Status	How SBOM appears
EU Cyber Resilience Act	Binding regulation	In force; Article 14 reporting starts 11 Sep 2026; main obligations apply 11 Dec 2027	Direct requirement to identify and document components, including by drawing up an SBOM
U.S. FDA section 524B for cyber devices	Binding statutory and submission requirement	Active since 29 Mar 2023	SBOM must be included in premarket submissions for cyber devices
U.S. federal procurement after OMB M-26-05	Active procurement and assurance framework	Active; centralized M-22-18 / M-23-16 model rescinded on 23 Jan 2026	Agencies may require a current SBOM by contract or on request
Australia ASD ISM software-development guidance	Active government control baseline	Active in the March 2026 guidance set	Produce an SBOM for software consumers and use available third-party SBOMs during development
Japan MHLW / PMDA medical-device cybersecurity materials	Active regulatory review expectation	Active	SBOM should be created, identified, and kept available for review

Related component-control regimes where SBOM can help

Some major regulations do not mandate an SBOM directly, but they still require organizations to inventory components, map dependencies, control supplier software, manage software lifecycle risks, or maintain traceable information about the hardware and software used in ICT products and services. In those cases, SBOM is often not the legal requirement itself, but it can be a practical way to satisfy part of the control objective.

Jurisdiction / instrument	Legal force	What the instrument requires	How SBOM can help
EU DORA	In force since 16 Jan 2023; applies from 17 Jan 2025	Financial entities must identify, classify, and document ICT-supported business functions, information assets, and ICT assets and map their configurations, links, and interdependencies	Supports software dependency visibility, change impact analysis, and supplier-software evidence inside broader ICT inventories
EU NIS2 and Implementing Regulation (EU) 2024/2690	NIS2 measures applied from 18 Oct 2024; Implementing Regulation 2024/2690 is active	Requires supply chain security, secure acquisition/development/maintenance, asset management, supplier registries, security-update requirements, and information describing hardware and software components in acquired ICT products and services	A strong fit for component inventories, supplier-software transparency, and lifecycle update evidence
PCI DSS 4.0 requirement 6.3.2	Required since 31 Mar 2025	Requires an inventory of bespoke and custom software and third-party software components incorporated into it to support vulnerability and patch management	Very close to an application-level SBOM use case for custom software
NIST SP 800-161r1 Update 1	Current version published 1 Nov 2024	Addresses component inventory, provenance, supplier inventory, acquisition controls, and includes CM-8(10) on SBOMs for open source projects	Useful implementation model for inventory, provenance, and supplier-risk controls
UNECE UN R155 / R156 automotive regime	UN regulations in force since Jan 2021; local implementation dates vary	Requires cybersecurity management systems, current risk assessments, supplier-related risk mitigation, and software update management systems	Helps maintain traceability of embedded software, supplier components, and update impact across the vehicle lifecycle
Singapore HSA GL-04-R4 for software medical devices	Revision 4 effective 31 Dec 2025	Requires software versioning and traceability, lifecycle cybersecurity planning, operating-system end-of-support handling, and detailed technical information for ML-enabled devices	Useful for tracking software versions, libraries, operating-system dependencies, and ML-related software components

Where is an SBOM explicitly required by law today?

EU Cyber Resilience Act

The EU Cyber Resilience Act is the clearest horizontal SBOM rule currently on the books.

Its SBOM language is direct: manufacturers of products with digital elements must identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used and machine-readable format that covers at least the top-level dependencies.

In the CRA, SBOM is not treated as optional disclosure. It is part of the product’s technical documentation and part of the broader secure-by-design and vulnerability-management model. The regulation also links software composition to third-party due diligence and supervisory review.

U.S. FDA Section 524B for Cyber Devices

The strongest active U.S. SBOM requirement is sector-specific rather than cross-sector. Under section 524B of the Federal Food, Drug, and Cosmetic Act, premarket submissions for cyber devices must include an SBOM.

FDA’s cybersecurity FAQ explains that these requirements became effective for submissions on March 29, 2023. FDA also states that the SBOM should cover commercial, open-source, and off-the-shelf software components. FDA’s February 2026 premarket cybersecurity guidance continues that model and places SBOM inside the broader cybersecurity evidence expected for regulated devices.

This makes the FDA framework one of the clearest examples of SBOM as a submission artifact: the SBOM exists for direct regulatory review and lifecycle cybersecurity management.

U.S. Federal Procurement after OMB M-26-05

The U.S. federal procurement model is active, but it is more targeted than a blanket SBOM mandate.

Executive Order 14028 made software supply chain assurance a federal priority and defined SBOM as a formal record of software components and supply-chain relationships. Later OMB memoranda standardized this further. But OMB M-26-05, issued on January 23, 2026, rescinded M-22-18 and M-23-16 and replaced that government-wide standardization with a risk-based approach.

Under M-26-05, agencies may adopt contract terms requiring software producers to provide a current SBOM upon request. For cloud platforms, the memo says agencies adopting such a term should specify that the producer must provide an SBOM of the runtime production environment upon request.

That means SBOM remains active in federal procurement, but now primarily as a contractual and agency-level assurance artifact rather than as a universal government-wide filing requirement.

Australia ASD Information Security Manual

Australia’s ASD Information Security Manual software-development guidance is one of the clearest examples of SBOM being used both directly and as a third-party control.

The guidance says that a software bill of materials is produced and made available to consumers of software. It also says that, if an SBOM is available for imported third-party software components, it is used during software development to ensure those components have no known vulnerabilities.

The same guidance also introduces the cryptographic bill of materials, or CBOM, as a related concept for understanding cryptographic dependencies and implementations. That combination matters. It means the Australian ISM treats SBOM as an artifact for the software producer to generate, and also as an upstream control to help evaluate software brought in from others.

Japan MHLW / PMDA Medical-Device Cybersecurity materials

Japan is another active SBOM regime, but with a different compliance posture from both the CRA and the FDA.

PMDA’s training and Q&A materials state that the configuration-management process should be confirmed by appropriately creating an SBOM. They also state that, although the SBOM does not need to be submitted with the application itself, applicants should indicate that it has been created and be ready to present it during review.

The same materials explain that the SBOM should cover components within the scope of the configuration-management process, including in-house and externally procured software, including open source, and should contain specified metadata about those components.

How do regulators frame SBOM requirements differently?

One reason SBOM can seem confusing in regulation is that the requirement is not phrased the same way everywhere. The control objective may be similar, but the wording is not.

Direct artifact requirement

The CRA is the clearest example of direct wording. The obligation is to identify and document components, including by drawing up an SBOM; it is part of required technical documentation.

Submission artifact

The FDA model is more procedural. The SBOM must be included in the premarket submission for a cyber device: the artifact exists for direct regulatory review.

Contractual or agency-requested artifact

The current U.S. federal procurement model uses a different posture. Agencies may require a current SBOM on a risk-based basis, especially through contract terms. The SBOM functions as procurement and assurance evidence.

Internal evidence that must exist and be ready

Japan is the clearest example of this model. The emphasis is not always “submit the full SBOM now,” but rather “create it, govern it, and have it available as part of the evidence set.”

Third-party control artifact

Australia makes this explicit. The ISM expects organizations both to produce an SBOM and to use available third-party SBOMs when evaluating imported components.

Inventory, dependency, or supplier-control requirement

Some regimes do not ask for an SBOM by name. Instead, they ask for inventories of software or ICT components, registries of suppliers and service providers, information about the hardware and software used in ICT products, software version traceability, or evidence that updates and vulnerabilities can be managed across the lifecycle. In those cases, an SBOM is often one practical implementation method rather than the named legal artifact.

Why do regulators require an SBOM?

Across the major programming frameworks, the reasons are consistent even when the wording differs.

Component transparency

Regulators increasingly expect organizations to know what their software contains. SBOM provides a formal, reviewable structure for that inventory.

Faster vulnerability impact analysis

When a package or library is disclosed as vulnerable, teams need to know quickly whether it is present: SBOM makes that analysis faster and more reliable.

Better third-party and open source control

Because modern software relies heavily on external components, regulators increasingly treat component inventories as part of supplier and dependency governance.

Better evidence for procurement and review

SBOM is attractive to buyers, regulators, and assessors because it is inspectable evidence. It is more concrete than a general claim that secure development took place.

Lifecycle maintenance and safety

In medical-device regulation, software composition is directly tied to patching, vulnerability response, maintenance, and safety across the product lifecycle.

SBOM in SonarQube

We treat SBOM as a practical software composition analysis (SCA) artifact. The focus is on visibility into the components inside an application and on using that visibility to manage vulnerability and license risk. In SonarQube, SBOM is part of SonarQube Advanced Security broader dependency and software composition analysis workflow. SonarQube can analyze direct and transitive dependencies, show dependency chains, surface license and vulnerability context, and export SBOMs in standard formats such as SPDX and CycloneDX.

This approach makes SBOM useful both as a reporting output, and as an operational artifact. The main goal here is to help teams answer software supply chain, procurement, and compliance questions with more specificity.

Closing

SBOM has become a real compliance artifact in multiple important sets of regimes. The direction is clear: regulators increasingly expect organizations to know what components are inside their software, to manage vulnerabilities with more precision, and to govern third-party software more explicitly.

That does not mean every software regulation is now an SBOM rule. But it does mean SBOM has moved into the mainstream of software compliance, especially where software supply chain visibility, vulnerability handling, and supplier control are central concerns.

SBOM is available in SonarQube Advanced Security. Check out the product page to learn more, and get in touch.