The EU CRA's Real Question: What Shipped, and When Did You Know?

What a maintainer's disclosure inbox already knows about the question the EU Cyber Resilience Act is about to ask every software vendor.

Written by: Shane Warden, Principal Architect, ActiveState 

Last year, someone submitted a vulnerability report to a security address for a free software project I help to review. The report followed our reporting guidelines, with a GPG signature and proper responsible disclosure ceremony, addressed only to the people who should have seen it.

It contained 95 vulnerabilities, purportedly. We took it seriously, because that security process exists for exactly this reason.

Yet something felt off, because how many human security researchers would compile a list 95 long and keep going instead of stopping at three or four and asking for a longer engagement.

Two or three of the 95 turned out to be real. That's a low percentage, and it didn't matter, because we still had to work through all 95 to find the two or three that did. Then came the second email: pay $100,000, or the report would go public with Heartbleed-style press.

The report itself was inflated. The threat behind it was not, because the blast radius of a disclosure like that is every deployment of the affected software an attacker can find by scanning the open internet for who's still running it.

I’m not the only person who’s seen this, and I think the problems open source maintainers are wrestling with now are the problems other enterprises will encounter very soon. The informal reality of volunteers becomes the operational reality of the entire software world.

On September 11, 2026, something adjacent to what I just described stops being a volunteer's problem and becomes a legal one for a very large number of companies.

The EU Cyber Resilience Act's reporting obligations take effect then: any manufacturer with a product with digital elements sold into the EU has to notify ENISA within 24 hours of learning a vulnerability in that product is being actively exploited, with a fuller report inside 72 hours.

The part of the law that actually mandates how you build and maintain the product, the engineering requirements, starts to apply on December 11, 2027.

That gives us fifteen months of "tell us fast" before the rest of the law requires us to prove that we’ve built things right.

Our CEO, Abby Kearns, wrote about that gap recently: for the length of that runway, the CRA is functionally a visibility requirement, not a security one. I agree! I've lived this part personally: "what shipped, and when did we first know there was a problem with it" is not a question compliance teams are going to be answering for the first time in September.

Every open source maintainer with a disclosure process already answers this question, informally, under pressure, with whatever tooling they cobbled together themselves, because nobody built it for us.

The challenge is knowing what actually shipped

We've collectively watched this scramble before. When the US issued Executive Order 14028 in 2021 and started requiring software bills of materials (SBOMs) from federal vendors, a lot of organizations generated an SBOM the way you'd generate any compliance artifact: once, under deadline pressure, accurate for the exact moment it was produced and stale by the time anyone asked to see it again.

A document generated last March that nobody has touched since doesn't tell you what you're running today. It tells you what you were running in March. The EU CRA is more explicit than that executive order was. Article 13 wants the SBOM current.

That gap is bigger than most teams expect. 98% of applications contain open source components (Black Duck, 2026 Open Source Security and Risk Analysis Report), so nearly every manufacturer selling into the EU has to answer this, not a handful of edge cases.

Manufacturers now have to prove what shipped and when they knew about it, with a legal clock ticking. The industry's own numbers on how long a fix takes to land aren't encouraging either: average time to remediate a high or critical application vulnerability runs about 55 days (Edgescan, 2026 Vulnerability Statistics Report).

The EU CRA enforcement will live in the gap between a 24-hour early warning and 72-hour full notification clock and that remediation baseline (European Commission, Cyber Resilience Act Article 14 reporting obligations). 

Organizations close that gap in two ways. Some are building the muscle in house: instrumenting their own pipelines to regenerate SBOMs automatically, standing up a documented vulnerability-handling process with a named owner, treating provenance as a property of the software supply chain you build, not a report you assemble under audit pressure.

Others are deciding that re-deriving provenance for every open source component they consume, across every language ecosystem their teams touch, isn’t a core technical skill, so they consume already-vetted, already-attested components instead so the provenance question is answered before the component ever enters a build.

Both approaches work, but it’s risky to find out in month fourteen of the runway that "we'll be compliant" didn’t have the backing of "we can actually answer the question when asked."

Most teams can only answer 2 of these 5 EU CRA questions. What about yours?

The EU Cyber Resilience Act's reporting clock starts September 11, 2026, and most security and engineering teams can only answer two or three of the five questions regulators will actually ask.

Get the CRA Readiness Assessment security and engineering leaders are using to find their gaps before ENISA does.

Get the Readiness Assessment

Most engineers I talk to want to focus on building great software, not adding deep introspection into their software supply chains.

We built ActiveState's Curated Catalogs to close that gap: open source components across 12 language ecosystems, delivered with immutable, build-time provenance, and remediated against contractual SLAs, 5 business days for critical severity once an upstream fix exists, 10 for high, 30 for the rest.

That complements your existing process, and it removes "who put this in our build, and when" from the list of questions your team has to answer by hand on a 72-hour clock.

I don't know yet how strictly ENISA will enforce the letter of Article 14 in its first year, and I'm skeptical of anyone who tells you they do with confidence. I do know that the 95-item report I described earlier didn't wait for a regulation to force the question. It just asked me, with a deadline and a price tag attached, whether I actually knew what I was running and how fast I could prove it.

The EU CRA is about to ask every manufacturer selling into the EU the same question, at scale, with a clock ticking down to legal enforcement.

Don’t wait for September 11. Pick a product your team shipped 6 months ago, and time how long it takes someone to tell you what's in it and when you first knew about the last critical CVE inside it. If that takes longer than 72 hours, you already have your answer.

Author

Shane Warden, Principal Architect, ActiveState

Shane Warden is Principal Architect at ActiveState, where he has worked for almost seven years. He has been active in open source since the late 1990s and is a practicing maintainer with direct responsibility for his own project's security disclosure process.

Sponsored and written by ActiveState.