Software Bills of Materials have gone from a niche concept discussed at security conferences to a regulatory requirement enforced by governments worldwide. In 2025, the question is no longer whether your organization needs SBOMs, but whether your SBOM program is mature enough to meet the rapidly expanding regulatory landscape.
This post maps the current state of SBOM compliance requirements, what is coming next, and practical steps for building a program that satisfies regulators without drowning your teams in paperwork.
The Regulatory Foundation
US Executive Order 14028
The catalyst for SBOM adoption was Executive Order 14028, "Improving the Nation's Cybersecurity," signed in May 2021. The EO directed NIST to publish guidance on SBOM practices and required federal agencies to obtain SBOMs from their software suppliers.
Key developments since the EO:
- NIST SP 800-218 (Secure Software Development Framework) established baseline SBOM practices for software producers selling to the federal government.
- OMB M-22-18 required federal agencies to collect self-attestation forms from software vendors, with SBOM submission as a potential requirement for higher-risk software.
- CISA's SBOM guidance provided practical recommendations for SBOM generation, consumption, and analysis.
By 2025, SBOM requirements are embedded in federal procurement processes. Software vendors selling to US government agencies are expected to produce SBOMs in SPDX or CycloneDX format as part of their delivery.
EU Cyber Resilience Act (CRA)
The EU Cyber Resilience Act, which entered into force in 2024 with enforcement beginning in 2027, is the most comprehensive SBOM mandate globally. The CRA requires:
- All products with digital elements sold in the EU market to include an SBOM.
- Vulnerability handling processes that include monitoring SBOM components for known vulnerabilities.
- Security updates for the expected product lifetime, not just the vendor's support window.
- Incident reporting within 24 hours of becoming aware of an actively exploited vulnerability.
The CRA applies to hardware and software manufacturers, importers, and distributors. Its scope is far broader than the US EO, covering consumer products, industrial equipment, and IoT devices in addition to enterprise software.
FDA Cybersecurity Requirements
The FDA's 2023 Refuse to Accept (RTA) policy requires medical device manufacturers to include SBOMs in premarket submissions. By 2025, this requirement is firmly established:
- Every new medical device submission must include a machine-readable SBOM.
- The SBOM must cover commercial, open-source, and off-the-shelf components.
- Manufacturers must demonstrate a process for monitoring and addressing vulnerabilities in SBOM components throughout the device's lifecycle.
Industry-Specific Requirements
Beyond government regulations, industry-specific standards are incorporating SBOM requirements:
- PCI DSS 4.0 (effective March 2025) emphasizes software inventory management and vulnerability monitoring that aligns with SBOM practices.
- NERC CIP standards for the energy sector increasingly reference SBOM-like inventory requirements for operational technology.
- Financial services regulators (OCC, FFIEC) are incorporating software supply chain risk management into examination guidance, with SBOM capability as a key indicator.
Where Organizations Stand
Despite the regulatory push, SBOM adoption remains uneven. Based on industry surveys and our experience working with organizations across sectors:
Mature organizations (approximately 15%) have automated SBOM generation integrated into their CI/CD pipelines, maintain SBOM databases for their deployed software, and actively monitor for vulnerabilities in SBOM components.
Developing organizations (approximately 35%) generate SBOMs for some products, typically driven by a specific customer or regulatory requirement, but do not have organization-wide SBOM programs.
Early-stage organizations (approximately 50%) are aware of SBOM requirements but have not implemented systematic SBOM generation or management. They may produce SBOMs manually or on request, but do not have automated processes.
The gap between regulatory expectations and organizational readiness is concerning. As enforcement begins in earnest -- particularly under the EU CRA -- organizations without mature SBOM programs will face compliance challenges and potential market access restrictions.
Building a Practical SBOM Program
Start with Generation
SBOM generation is the foundation. Every build should produce an SBOM automatically, captured as a build artifact alongside the software itself.
Key decisions:
- Format: SPDX and CycloneDX are the two dominant standards. Pick one as your primary format and use tooling that can export to both.
- Scope: Start with direct dependencies and expand to transitive dependencies. Include build tools, compilers, and runtime components.
- Automation: Integrate SBOM generation into your CI/CD pipeline. Tools like Syft, Trivy, and cdxgen can generate SBOMs automatically during the build process.
Add Vulnerability Monitoring
An SBOM without vulnerability monitoring is just an inventory list. The value of SBOMs comes from knowing when components in your bill of materials have known vulnerabilities.
This requires:
- Continuous correlation of SBOM components against CVE databases, NVD, and vendor advisories.
- Alerting when new vulnerabilities affect components in your deployed SBOMs.
- Prioritization that accounts for severity, exploitability, and your specific usage of the vulnerable component.
Implement Governance
Governance transforms SBOM from a technical artifact into a compliance asset:
- Define policies for acceptable component risk levels.
- Establish remediation timelines based on vulnerability severity.
- Track SBOM completeness and accuracy metrics.
- Map SBOM activities to specific regulatory requirements.
Plan for Scale
SBOM programs that work for a handful of applications often break down at scale. Consider:
- How will you manage SBOMs for hundreds or thousands of applications?
- How will you handle SBOMs from third-party vendors?
- How will you correlate vulnerabilities across your entire SBOM inventory?
- How will you report compliance status to auditors and regulators?
How Safeguard.sh Helps
Safeguard.sh is purpose-built for the SBOM compliance landscape of 2025. From automated SBOM generation to continuous vulnerability monitoring to compliance reporting, Safeguard provides the complete platform organizations need to build and maintain a regulatory-ready SBOM program.
Key capabilities for compliance:
- Multi-format SBOM support for SPDX and CycloneDX, with automatic format conversion.
- Automated vulnerability correlation that monitors your SBOM inventory 24/7 and alerts on new findings.
- Policy gates that enforce your organization's security standards in CI/CD pipelines.
- Compliance dashboards that map your SBOM activities to specific regulatory requirements, generating audit-ready reports.
- Vendor SBOM management for ingesting and analyzing SBOMs from your software suppliers.
Whether you are starting your SBOM journey or scaling an existing program, Safeguard.sh provides the foundation you need for compliance in 2025 and beyond.