The real question from the EU CRA: What was sent and when did you know it?

What a maintainer’s disclosure inbox already knows about the question the EU Cyber ​​Resilience Act will ask every software provider.

Written by: Shane Warden, Principal Architect, ActiveState

Last year someone sent a vulnerability report to a security address for a free software project that I help review. The report followed our reporting guidelines, with a GPG signature and a proper responsible disclosure ceremony, and was aimed only at those who should have seen it.

It reportedly contained 95 vulnerabilities. We took it seriously because that is exactly why this security process exists.

But something felt off because how many security researchers would put together a list of 95 people and move on, rather than stopping at three or four and asking for a longer commitment.

Two or three of the 95 turned out to be real. That’s a small percentage, and it didn’t matter because we still had to work through all 95 to find the two or three where that was the case. Then came the second email: Pay $100,000 or the report would be published in the press, Heartbleed-style.

The report itself was inflated. The threat behind it was non-existent because the blast radius of such a disclosure includes any deployment of the affected software that an attacker can find by searching the open Internet for the person still running it.

I’m not the only one who has seen this, and I think the problems that open source maintainers are currently facing are the problems that other companies will face very soon. The informal reality of volunteers becomes the operational reality of the entire software world.

On September 11, 2026, something similar to what I just described will no longer be a problem for volunteers, but will become a legal problem for a very large number of companies.

Then the reporting requirements of the EU Cyber ​​​​Resilience Act come into force: any manufacturer that sells a product with digital elements into the EU must notify ENISA within 24 hours of learning that a vulnerability in that product is being actively exploited and submit a more detailed report within 72 hours.

The part of the law that actually dictates how you build and maintain the product, the technical requirements, comes into force from December 11, 2027.

That gives us fifteen months to “tell us quick” before the rest of the law requires us to prove we did everything right.

Our CEO, Abby Kearns, recently wrote about this gap: For the length of this runway, the CRA is functionally a visibility requirement, not a safety requirement. I agree! I have personally experienced this part: “What was shipped and when did we first know there was a problem with it?” is not a question that compliance teams will be answering for the first time in September.

Every open source maintainer with a disclosure process is already answering this question, informally, under pressure, using the tools they cobbled together because no one built them for us.

The challenge is knowing what was actually sent

We’ve seen this tussle together before. When the US issued Executive Order 14028 in 2021 and began requiring software bills of materials (SBOMs) from federal suppliers, many organizations created an SBOM the way one would create any compliance artifact: one-time, under time pressure, for the exact moment it was created, and outdated when someone asked to see it again.

A document created in March last year that no one has touched since then does not tell you what you are executing today. Here’s what you did in March. The EU CRA is more explicit than this implementing regulation. Article 13 provides that the SBOM is current.

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

Manufacturers now have to prove what they sent and when they knew about it, within a legal deadline. The industry’s own numbers on how long it takes to get a fix are also not encouraging: the average time to fix a high or critical application vulnerability is about 55 days (Edgescan, Vulnerability Statistics Report 2026).

EU CRA enforcement will live in the gap between a 24-hour early warning and a 72-hour full notification clock and this remedial baseline (European Commission, Cyber ​​Resilience Act Article 14 Reporting Requirements).

Organizations are bridging this gap in two ways. Some build the muscles in-house: Instrumenting your own pipelines to automatically regenerate SBOMs, Have a documented vulnerability management process with a named owner and treat provenance as a property of the software supply chain you are building, rather than a report you create under audit pressure.

Others decide that re-derivating provenance for every open source component they use in every language ecosystem their teams touch is not a core technical skill set. Instead, they use already tested, already attested components so that the provenance question is answered before the component even enters a build.

Both approaches work, but it’s risky to find out in the fourteenth month of the runway that “we’re following the rules” didn’t have the support: “We can actually answer the question when it’s asked.”

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

We built Curated catalogs from ActiveState to close this gap: open source components across 12 language ecosystems, delivered with immutable build-time provenance and remedied against contractual SLAs, 5 business days for Critical severity once an upstream fix is ​​available, 10 for High, 30 for the rest.

This complements your existing process and removes “Who put this into our build and when?” from the list of questions your team must answer manually every 72 hours.

I don’t yet know how strictly ENISA will enforce the wording of Article 14 in the first year, and I am skeptical of anyone who tells you they are doing so with confidence. I know that the 95-point report I described earlier did not wait for regulation to force the question. All I was asked was a deadline and a price tag, asking if I actually knew what I was doing and how quickly I could prove it.

The EU-CRA is about to do so Ask every manufacturer selling to the EU the same questionon a large scale while the clock ticks down to legal enforcement.

Don’t wait until 9/11. Pick a product that your team shipped six months ago and measure how long it takes for someone to tell you what was in it and when you first learned about the last critical CVE it contained. If it takes longer than 72 hours, you already have your answer.

author

Shane Warden, Principal Architect, ActiveState

Shane Warden is chief 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.