Mandatory SBOMs: Why CRA matters

New regulations are elevating software bills of materials from a best practice nice-to-have to a must-have for organizations to meet compliance requirements.

SBOMs have been gaining traction since 2021, when the White House issued an executive order mandating their availability for federal agencies. That was followed up with guidance on SBOM contents issued by both the National Telecommunications and Information Administration and the U.S. Cybersecurity and Infrastructure Security Agency, the latter of which just last year expanded the metadata required in SBOMs to include fields for provenance, authenticity, and deeper cybersecurity integration.

Meanwhile, the European Union adopted the Cyber Resilience Act. As explained in a blog post on the website of the Open Source Security Foundation (OpenSSF), the CRA introduces a legally binding obligation for manufacturers to create, maintain, and retain an SBOM for all products with digital elements marketed within the EU.

“This elevates the SBOM from a voluntary best practice to a legally required element of technical documentation, essential for conformity assessment, security assurance, and incident response throughout a product’s lifecycle. In essence, the CRA transforms this form of software transparency from a recommendation into a condition for market access."

OpenSSF post

The authors added that CISA’s minimum elements framework and automation initiatives are shaping global SBOM practices — and directly influencing Europe’s focus on interoperability and structured vulnerability handling under the CRA. “This transatlantic alignment helps ensure SBOM data models and processes evolve toward a consistent, globally recognized baseline,” they wrote.

Here’s what your organization needs to know about the CRA — and how to get ahead of it. 

See webinar: SBOM Power Hour: Inside the Next Generation of SBOMs

A spectrum of external influences 

Regulations focused on improving software supply chain security are a positive development, Charlie Jones, director of product management at ReversingLabs (RL), said at the Open Source Summit Europe 2025. 

I think, contrary to popular belief, the aim of regulators isn’t simply to stifle innovation in the software manufacturing sector. It’s ultimately to protect the end consumer by uplifting software supply chain security posture across the board.

Charlie Jones

While it’s true that much of the regulatory burden will fall on software producers, Jones said, the majority of commercial software sold today contains open-source software, and he doesn’t expect that to change as a result of this regulation.

I only expect more involvement, more collaboration, and more engagement from the private sector, who is now going to be heavily incentivized toward contributing to open-source software to make it more secure at the end of the day, because it’s their head on the line in front of the regulators.

Charlie Jones

Jones noted that a misconception held by many organizations is that all software security standards exert the same level of external influence on their operations. But a spectrum of external influences exists, with legal requirements — cybersecurity requirements issued by a government, such as laws and executive orders — at the top. Failure to meet those requirements is punishable, with enforcement by government agencies or delegated to regulatory bodies.

The spectrum continues with regulatory requirements, which are issued by regulatory bodies; mandatory requirements, which define a minimum baseline required to operate in a specific industry or to deliver a specific offering; voluntary frameworks, which are a set of best practices designed to manage cybersecurity risk; and advisories and alerts, which are solely informational and not structured as frameworks.

If software were a vehicle …

Complying with external influences is a lot like maintaining a motor vehicle, said Kadi McKean, open-source community manager at RL, who also spoke at the Open Source Summit. Just as careful motorists make sure their headlights are working before driving at night, security teams should scan an application for exposed secrets before committing it to production, she said. The driver avoids a ticket and the security team a breach.

Vehicle owners want their turn signals to be working, she continued, just as downstream consumers need signals that can be provided by a clear SBOM from the application provider.

And just as vehicle owners regularly check their oil, security teams need to assess the dependencies their organizations’ apps are using. “There are tons and tons of them, but you want to make sure you’re not dragging anything in that might contain malware or maybe is leaking secrets or might contain tampering,” McKean said.

Watch your mirrors, she added: “In other words, monitor for malware and packages.”

I know everybody’s running around like a chicken with their head cut off worrying about vulnerabilities, but any day that you have malware coming in, for me, should trump a vulnerability.

Kadi McKean

She also urged organizations to embrace DevSecOps culture, “where you’re bringing everybody who has a hand in the development process to the table so they can have some say about these issues.” 

Make compliance your guidance system

McKean said organizations shouldn’t look at compliance as a detour from their goal of producing software. “It’s more of a GPS,” she said, “a guidance system to help you get where you need to go safely.”

SBOMs can be an important part of that guidance system, wrote the authors of the OpenSSF blog post, but they have to be widely embraced as such. “To fully achieve global cyber resilience, SBOMs must not be merely considered as a compliance artifact to be created and ignored, but instead as an operational tool to support security and augment asset management processes,” they wrote.

The post recommends that organizations drive shared governance for SBOMs by actively engaging in multistakeholder governance initiatives (CEN/CENELEC, ISO/IEC, CISA, ETSI, OpenSSF) to unify technical standards and policy globally.

The authors also advise organizations to enable decision-ready processes that build on SBOMs by implementing advanced SBOM processes that link component data with exploitability and vulnerability context, transforming static reports into actionable security intelligence.

By embracing this shared vision, spanning, among many others, the CRA, CISA, METI, KISA, NTIA, ETSI, and BSI frameworks, we can definitively move from merely fulfilling compliance obligations to achieving verifiable confidence. This collective commitment to transparency and interoperability is the essential step in building a truly global, actionable, and resilient software ecosystem.

OpenSSF post

Ultimately, the evolution toward global, actionable SBOMs depends on automation, lifecycle integrity, and intelligence linkage, they authors added. That means organizations should embed automated SBOM generation and validation (using tools such as Protobom, BomCTL, and SBOMit) into CI/CD workflows, ensuring continuous updates and cryptographic signing for traceable trust.

By connecting SBOM information with vulnerability data in internal databases, the SBOM data becomes decision-ready, capable of helping identify exploitable or end-of-life components and driving proactive remediation.

OpenSSF post