The EU Cyber Resilience Act is currently top of mind for manufacturers, importers, and distributors across Europe and beyond. For many organizations, the regulation clarifies the distance between having a Software Bill of Materials (SBOM) tool and having an SBOM practice.
Shane Fry, Chief Technology Officer at RunSafe Security, works with organizations in the aviation, defense, industrial, and energy sectors to address exactly that gap. We asked him what complying with EU CRA SBOM requirements actually demands, where most organizations have room to grow, and what it takes to build the governance infrastructure the regulation requires.
The CRA doesn’t exist in isolation—you’ve got the FDA’s device cybersecurity guidance, CISA’s work in the US, the BIS Connected Vehicle Rule. Where are all these frameworks pointing?
Shane: If you look at what regulators across sectors are converging on—the CRA in Europe, the FDA’s cybersecurity guidance for medical devices, CISA’s work in the US, the BIS Connected Vehicle Rule—they all share a common assumption: organizations need to know what software they are shipping, where it came from, and what vulnerabilities it contains. That’s the baseline.
What’s changing is how far that expectation extends across the software supply chain. The CRA, in particular, places clear obligations on economic operators—manufacturers, importers, and distributors placing products on the EU market. While it does not directly regulate every upstream participant, it creates downstream pressure that affects the entire ecosystem. Manufacturers cannot meet their obligations without visibility into the components they rely on, which means they will increasingly require transparency, SBOMs, and vulnerability disclosure practices from their suppliers.
This has important implications for different actors. Commercial software vendors and suppliers are likely to face increased scrutiny and contractual requirements, as their components directly impact the compliance posture of the final product. The result is not universal regulation of all actors, but a shift in expectations that propagates through the software supply chain via procurement and integration requirements.
The CRA SBOM requirements go beyond maintaining a component list. What do they actually demand in practice?
Shane: The CRA sets out specific obligations that SBOMs are uniquely well-positioned to support, but only if they’re built the right way.
The regulation requires manufacturers to identify and document vulnerabilities in their products, address those vulnerabilities without undue delay, and report actively exploited vulnerabilities to relevant authorities. To do any of that at scale, you need a complete, accurate, and machine-readable inventory of your software components. That is the foundational function of the SBOM.
In practice, a well-constructed SBOM enables you to run continuous matching against vulnerability databases like the NVD, EUVD, or vendor advisories. When a new CVE is disclosed, you can immediately determine which of your products are affected, at which version, and what the blast radius looks like across your portfolio. Without that, you’re doing manual triage across product lines, and in a world where vulnerability disclosure is constant, that doesn’t scale.
Beyond vulnerability management, SBOMs become the connective tissue between your development organization and the market. When regulators, enterprise customers, or downstream integrators ask what’s in your software and whether a specific component is present, you need to be able to answer quickly and accurately. An SBOM that’s properly maintained and tied to a specific build artifact can answer that question in minutes rather than days. SBOMs are the mechanism through which that visibility becomes structured and actionable.
Security teams talk about continuous governance, but most organizations were built around periodic audits. What’s actually forcing that change?
Shane: Several things are converging at once, and I think it’s worth separating them out because they’re mutually reinforcing.
The threat environment is the most fundamental driver. The volume of disclosed vulnerabilities has grown year over year for a decade. Now that AI is in the picture, the time from disclosure to exploitation has compressed dramatically. In some cases, AI-driven vulnerability identification and exploit development has cut that time down to hours or minutes. A reactive posture, where you patch when something breaks or respond when a customer reports an issue, is no longer viable. By the time you’re reacting, the window is already open.
The second driver is regulatory maturity. The CRA is a good example of what I mean. Earlier cybersecurity frameworks were often principles-based, telling you what outcomes to achieve but leaving implementation largely undefined. What we’re seeing now is regulations that specify ongoing obligations: continuous monitoring, documented vulnerability management processes, timely disclosure, and lifecycle accountability. That architecture doesn’t accommodate a point-in-time compliance approach. Instead, it requires an organization to build governance infrastructure rather than just pass an audit.
The third driver, which often gets underestimated, is the software-defined nature of modern products. In industries like automotive, industrial control, and medical devices, software is now the primary determinant of product behavior and software changes continuously
What continuous governance actually means in practice is building the instrumentation, processes, and organizational accountability so that security and compliance questions can be answered at any point in time and not just at scheduled review cycles. SBOMs, build-time provenance, automated vulnerability matching, and clear ownership of remediation are the building blocks for treating security as an ongoing state.
If you could get organizations to change one thing about how they generate SBOMs, what would it be?
Shane: I’d change where they generate their SBOMs.
The overwhelming majority of organizations produce SBOMs by scanning finished build artifacts—running a tool against a compiled binary or a container image after the fact and inferring what went into it. However, in an analogy I like to use, that’s like guessing what ingredients went into a pizza based on what you see in the finished product versus watching what ingredients the chef used step by step.
Instead of inferring composition from the output, build-time SBOMs observe the build as it happens, recording which source files, libraries, toolchains, and configurations contributed to each artifact as the software is being constructed. That gives you something a post-build scan can never fully recover: accurate, defensible attribution at the point where it actually exists. It’s not reconstructed or approximated, but an actual list of the components in your software.
The practical difference matters enormously when you’re trying to meet CRA obligations. If a vulnerability is disclosed in a commercial library that was statically linked into your firmware six months ago, a post-build scanner may or may not surface it. A build-time SBOM knows it was there because it was recorded when it entered the build. That’s the difference between a compliance artifact you can stand behind and one you’re hoping holds up under scrutiny.
For more on EU CRA compliance, learn how RunSafe supports SBOM generation, vulnerability risk management, and lifecycle security for CRA readiness.
