The Comprehensive Guide to SBOM Compliance Requirements
As software supply chain threats continue to increase across the globe, a number of regulatory bodies have adopted SBOM (software bill of materials) requirements to help strengthen security.
Introduction to SBOM Compliance Requirements
As software supply chain threats continue to increase across the globe, a number of regulatory bodies have adopted SBOM (software bill of materials) requirements to help strengthen security.
From Los Angeles to London and plenty of locations in between, governments and industry groups now require organizations in certain industries to be able to generate and distribute comprehensive SBOMs, often in service of specific vulnerability management objectives.
This guide will break down the biggest SBOM compliance regulations in effect today, including timelines, impacted organizations, and technical requirements. It will also provide a brief overview of SBOM recommendations that could conceivably become requirements in the years ahead.
What Makes an SBOM Compliant?
A compliant SBOM must typically include:
- Component identification (name, version, supplier)
- Relationship information (dependencies)
- Timestamp and author data
- Standard machine-readable format (usually SPDX or CycloneDX)
- Component metadata (licenses, known vulnerabilities)
- Complete dependency tree to a specified depth
Specific requirements may vary by regulatory framework, but these elements form the baseline for most compliance scenarios.
Evolution of SBOM Compliance Requirements
NTIA Software Component Transparency
NTIA SBOM Format Initiative
FDA Premarket Cybersecurity Guidance
Executive Order 14028
CISA SBOM Requirements
EU Cyber Resilience Act Proposal
Expanded Healthcare Requirements
Global SBOM Adoption
Executive Order 14028
Executive Order 14028
The U.S. Government's Cybersecurity Executive Order 14028 represents a concerted effort to improve the nation's cybersecurity posture. Issued in May 2021, the order directs federal agencies to enhance cybersecurity through various measures, including the requirement for software vendors to provide an SBOM for software used by federal agencies.
While the executive order itself does not specify the format or content of the SBOM, subsequent guidance from the National Telecommunications and Information Administration (NTIA) has established the minimum elements for an SBOM, providing software vendors with a framework to follow.
Who It Impacts
Entities that develop software for federal agencies, including software that is available commercially and not developed specifically for the government.
Timeline for Compliance
Guidelines established during 2021; agencies are actively incorporating requirements into their procurement processes.
Requirement Text
Section 4(e) of Executive Order 14028 states:
Within 60 days of the date of this order, the Secretary of Commerce, in coordination with the Assistant Secretary for Communications and Information and the Administrator of the National Telecommunications and Information Administration, shall publish minimum elements for an SBOM.
Requirement Analysis
The key parts of the Executive Order as they relate to SBOMs include:
SBOM Requirement for Government Vendors
Section 4(e) of the Executive Order directs federal agencies to require an SBOM from vendors selling software to the federal government. This means companies that want to sell software to the U.S. federal government must produce an SBOM that follows the NTIA guidelines.
NTIA Minimum Elements
In July 2021, the NTIA published 'The Minimum Elements for an SBOM.' This document outlines the required data fields, the depth of dependency analysis, and formats for SBOM creation. The three accepted formats are SPDX, CycloneDX, and SWID tags.
OMB Implementation
In September 2022, the Office of Management and Budget (OMB) issued memorandum M-22-18, specifying how agencies should implement the Executive Order, including the requirements for SBOMs in procurement.
FDA (Food and Drug Administration)
FDA (Food and Drug Administration)
The U.S. FDA (Food and Drug Administration) now requires manufacturers of certain medical devices to submit an SBOM during the premarket review process. The requirement applies to "cyber devices," which are defined as those that can connect to the internet, have characteristics that could be vulnerable to cyber threats, and include software.
In addition to requiring an SBOM with commonly used data fields, the FDA mandates device manufacturers to provide information about end-of-life date and support level for each software component, along with an assessment (and remediation plan) of known vulnerabilities.
Who It Impacts
Manufacturers of medical "cyber devices" who wish to sell their products in the United States. 510(k), premarket approval application (PMA), Product Development Protocol (PDP), De Novo, and Humanitarian Device Exemption (HDE) submissions (among others) must be delivered with an SBOM.
Timeline for Compliance
The requirement applies to applications submitted to the FDA on or after March 29, 2023.
Requirement Text
Section 524B, 'Ensuring Cybersecurity of Devices,' of the U.S. government's amendment to the Federal Food, Drug, and Cosmetic Act (FD&C Act) reads in part:
Provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components…
Requirement Analysis
There are three primary elements to the FDA's SBOM regulation; device manufacturers must fulfill all three to ensure compliance:
Generating the SBOM itself
The key consideration is to ensure the document meets or exceeds the NTIA's minimum requirements discussed earlier in this article.
Providing end-of-life and level-of-support information for all software components included in the SBOM
This requirement applies to all types of components, including open source.
Including an assessment of known vulnerabilities along with mitigations that address the vulnerability
There are multiple ways to communicate vulnerability information. One approach is by using VEX (Vulnerability Exploitability eXchange), which has standardized fields for communicating exploitability and mitigation status.
PCI DSS
PCI DSS (Payment Card Industry Data Security Standard)
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment. PCI DSS 4.0, released in March 2022, includes provisions related to software component management that are closely related to SBOM concepts.
While PCI DSS 4.0 does not explicitly use the term "SBOM," it requires organizations to maintain an inventory of software components, including open source, which functionally resembles an SBOM.
Who It Impacts
All entities that store, process, or transmit cardholder data, including merchants, service providers, payment processors, issuers, and acquirers.
Timeline for Compliance
PCI DSS v4.0 was released in March 2022, with a multi-year transition period. The software inventory requirement took effect on March 31, 2025.
Requirement Text
PCI DSS Section 6.3.2 reads in part:
An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.
Requirement Analysis
The PCI DSS 4.0 requirements closely align with SBOM practices in several ways:
Component Inventory
Requirement 6.3.2 mandates maintaining an inventory of all software components. This is fundamentally similar to an SBOM, which catalogs all components within a software product.
Vulnerability and Patch Management
The standard requires using the inventory for vulnerability and patch management—precisely one of the primary use cases for SBOMs.
Securing Development Processes
Requirements 6.2.1 and 6.2.2 focus on secure development processes and change control, which can be facilitated by accurate software component tracking.
Third-Party Components
The standard explicitly mentions third-party components (such as open source software), which are a significant focus of SBOM initiatives.
CRA (Cyber Resilience Act)
CRA (Cyber Resilience Act)
The European Union's proposed Cyber Resilience Act (CRA) aims to establish cybersecurity rules for products with digital elements sold within EU markets. The CRA includes a transparency requirement that may make SBOM disclosure a necessity. SBOMs, while not explicitly mandated in the current draft, are referenced in the recitals.
Who It Impacts
Manufacturers, importers, and distributors of products with digital elements that are placed on the EU market. This includes hardware and software products.
Timeline for Compliance
The CRA was entered into force in December, 2024. Organizations will need to have vulnerability and incident reporting in place by Sept. 11, 2026, while other requirements (such as those related to SBOMs) will take effect on December 11, 2027.
Requirement Text
Provision 22 of the CRA reads in part:
Market surveillance authorities should be able to request manufacturers of categories of products... to submit the software bills of materials (SBOMs)
Requirement Analysis
The CRA defines an SBOM as 'a formal record containing details and supply chain relationships of various components used in building software.' The proposed regulation would require SBOMs for:
All products with digital elements
This includes hardware devices with software components and standalone software products.
Documentation of third-party components
The SBOM must include all third-party components, including open-source software, used in the product.
Vulnerability management processes
Manufacturers must implement processes to identify and address vulnerabilities in their products, including those in third-party components.
The CRA also requires manufacturers to ensure that their products are secure by design and to provide security updates for a reasonable period. An SBOM helps manufacturers identify vulnerabilities in their products and respond quickly to security threats.
DORA (Digital Operational Resilience Act)
DORA (Digital Operational Resilience Act)
The European Union's Digital Operational Resilience Act (DORA) is designed to ensure that financial entities can withstand, respond to, and recover from ICT-related incidents. Among its requirements is a provision for ICT third-party service providers to share information about their IT systems and applications, which is a potential fit for SBOM disclosure.
Who It Impacts
Financial entities operating within the EU, including banks, insurance companies, investment firms, and critical ICT third-party service providers to the financial sector.
Timeline for Compliance
DORA was approved by the European Parliament on November 10, 2022, and entered into force on January 17, 2023. Financial entities must comply with DORA by January 17, 2025.
Requirement Text
While DORA does not explicitly mandate SBOMs, it requires financial entities to:
Maintain up-to-date information on all ICT dependencies and have in place sound, comprehensive and well-documented ICT risk management frameworks.
Requirement Analysis
DORA mandates several risk management practices that can be supported by SBOMs:
Third-party and ICT dependency management
Financial entities must maintain updated information about their ICT dependencies, which includes software components and third-party services.
Vulnerability management
Entities must implement processes to identify, track, and remediate vulnerabilities in their ICT systems, which requires knowledge of all software components.
Assessing ICT third-party risk
Financial entities must assess and monitor risks related to ICT third-party providers, including software suppliers.
While SBOMs are not explicitly required by DORA, they are a powerful tool for meeting the regulation's requirements for ICT dependency management, vulnerability management, and third-party risk assessment. By maintaining SBOMs for their software systems, financial entities can more easily comply with DORA's requirements.
NIST (National Institute of Standards and Technology)
NIST (National Institute of Standards and Technology)
The National Institute of Standards and Technology (NIST) has developed several guidelines and frameworks that recommend the use of SBOMs for effective cybersecurity risk management. While not regulatory requirements themselves, these guidelines often inform actual regulations and are widely adopted as industry best practices.
Who It Impacts
Organizations that follow NIST guidelines, particularly federal agencies and their contractors. Many private sector organizations also voluntarily adopt NIST frameworks as best practices.
Key NIST Publications
NIST SP 800-218 (Secure Software Development Framework), NIST SP 800-161 (Supply Chain Risk Management Practices), and the NIST Cybersecurity Framework all reference SBOMs.
Guidance Text
NIST Special Publication 800-218, the Secure Software Development Framework (SSDF), states:
Identify and confirm the provenance of software components... The organization maintains accurate and up-to-date data, including an inventory of all software components, their sources, licenses, and other attributes.
Key NIST SBOM Guidance
NIST has published several resources related to SBOMs:
NIST SP 800-218: Secure Software Development Framework
Recommends maintaining an accurate inventory of software components as part of secure software development.
NIST SP 800-161: Supply Chain Risk Management Practices
Highlights the importance of understanding software components for effective supply chain risk management.
NIST Cybersecurity Framework
Includes asset management and supply chain risk management as key components of effective cybersecurity programs.
While NIST guidelines are not regulatory requirements in themselves, they often inform actual regulations and are widely adopted as industry best practices. Many regulatory requirements, including the Executive Order 14028, explicitly reference NIST guidelines.
Other SBOM Guidelines and Guidance
Other SBOM Guidelines and Guidance
A number of government bodies and regulators have published SBOM guidance. Below is a sampling of these guidelines and recommendations.
International Medical Device Regulators Forum
IMDRF — the International Medical Device Regulators Forum — is a global organization that aims to promote effective regulation of medical devices. In 2023, the IMDRF published "Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity," a technical document with SBOM-related guidance.
Australian Cyber Security Centre
The Australian Cyber Security Centre's "Guidelines for Software Development" recommends that "a software bill of materials is produced and made available to consumers of software." This guidance aligns with global trends toward greater software supply chain transparency.
U.S. National Highway Traffic Safety Administration
The U.S. NHTSA's "Cybersecurity Best Practices for the Safety of Modern Vehicles" publication recommends auto manufacturers and suppliers to maintain an SBOM. Section 4.2.6 states that suppliers and vehicle manufacturers should maintain a database of their operational hardware and software components used in each automotive ECU.
Canadian Forum for Digital Infrastructure Resilience
The Canadian Forum for Digital Infrastructure Resilience published "Recommendations to Improve the Resilience of Canada's Digital Supply Chain" recommending organizations use SBOMs to better understand and reduce software supply chain risks. This aligns with the Canadian Centre for Cyber Security's guidance on software supply chain security.
German BSI (Federal Office for Information Security)
The German BSI published Technical Guideline TR-03183 with concrete guidance on SBOM requirements. The TR-03183 attempts to fill the void in the EU's proposed CRA regarding SBOM format, data fields, and update frequency. The document aims to "provide manufacturers with advance access to future requirements."
CERT-In (Indian Computer Emergency Response Team)
CERT-In published "Technical Guidelines on SBOM" in October 2024, providing detailed guidance for government bodies, the public sector, essential services, and software producers on managing an effective SBOM program. The document covers data fields, automation, processes, and SBOM sharing best practices.
FOSSA: Your SBOM Compliance Solution
FOSSA: Your SBOM Compliance Solution
FOSSA provides a comprehensive solution for generating, managing, and sharing SBOMs, helping organizations comply with the various regulatory requirements discussed in this article.
With FOSSA, you can:
Generate Comprehensive SBOMs
FOSSA automatically scans your codebase to identify all third-party components, including direct and transitive dependencies, and generates SBOMs in industry-standard formats (CycloneDX, SPDX).
Identify and Manage Vulnerabilities
FOSSA integrates with vulnerability databases to identify security vulnerabilities in your dependencies and provides remediation recommendations. This helps you comply with requirements for vulnerability assessment and remediation.
License Compliance Management
FOSSA identifies the licenses of all third-party components and helps you ensure compliance with license obligations, which is an important part of effective SBOM management.
Monitor for New Vulnerabilities
FOSSA continuously monitors your dependencies for new vulnerabilities, ensuring that you can respond quickly to emerging threats and maintain compliance with regulatory requirements.
Industry-Leading SBOM Generation
FOSSA's SBOM generation capabilities include:
Support for multiple languages and package managers
FOSSA can generate SBOMs for projects using a wide range of programming languages and package managers.
Industry-standard SBOM formats
FOSSA generates SBOMs in CycloneDX and SPDX formats, which are widely accepted and meet regulatory requirements.
Integration with CI/CD pipelines
FOSSA can be integrated into your CI/CD pipeline to automatically generate SBOMs as part of your build process.
SBOM sharing and distribution
FOSSA makes it easy to share SBOMs with customers, regulators, and other stakeholders, helping you meet disclosure requirements.
Ready to Meet SBOM Compliance Requirements?
FOSSA helps organizations of all sizes comply with SBOM requirements across all the regulatory frameworks discussed in this article. Whether you need to meet the requirements of Executive Order 14028, the FDA, PCI DSS, CRA, DORA, or follow NIST guidelines, FOSSA provides the tools you need to generate comprehensive SBOMs and manage third-party software components effectively.
Ready to take the next step?
Learn more about how FOSSA can help your organization