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