EU Cyber Resilience Act Spurs Rush to Track Software Vulnerabilities

"what shipped, and when did we first know there was a problem with it." — Shane Warden, Principal Architect, ActiveState

ENISA notification: the 24‑hour / 72‑hour clock that starts on September 11, 2026

On September 11, 2026 the EU Cyber Resilience Act's reporting obligations take effect. Under Article 14, any manufacturer with a product with digital elements sold into the EU must notify ENISA within 24 hours of learning that a vulnerability in that product is being actively exploited, and provide a fuller report within 72 hours. The law’s substantive engineering requirements, the parts that dictate how products are built and maintained, do not begin to apply until December 11, 2027 — creating a fifteen‑month runway in which reporting is enforced before the design rules kick in.

A maintainer’s inbox: a 95‑item disclosure, two real bugs, and a $100,000 demand

Shane Warden describes a real incident from his work as an open‑source maintainer: a responsible disclosure submitted with GPG signature and following reporting guidelines that listed 95 purported vulnerabilities. Only two or three of the 95 were real, but the maintainer team still had to triage all 95 entries. Days later the reporter demanded $100,000, threatening public disclosure “with Heartbleed‑style press.” Warden uses that episode to illustrate the blast radius of public disclosure: every deployment reachable by internet scanning becomes exposed once a disclosure goes public.

Article 13 and SBOM currency: why a single SBOM is not enough

The CRA explicitly demands current software‑bill‑of‑materials (SBOM) data. Warden draws a parallel to Executive Order 14028’s earlier SBOM push, where many organizations produced a one‑off SBOM under deadline pressure and let it go stale. Article 13’s requirement that SBOMs be kept current raises a practical problem: a document generated months earlier may be accurate for that moment, but it will not tell regulators or incident responders what is actually running when a vulnerability is discovered.

Remediation realities vs. legal timelines (Edgescan, 2026)

Industry data Warden cites underscore the timing mismatch regulators will encounter. The Edgescan 2026 Vulnerability Statistics Report shows average time to remediate a high or critical application vulnerability at about 55 days. The CRA’s 24‑hour/72‑hour notification windows therefore collide with an operational baseline where fixes often take nearly two months to reach deployed systems. Warden frames enforcement as living in that gap between rapid reporting and much slower remediation cycles.

ActiveState’s technical answer: Curated Catalogs and SLAs

Warden outlines two broad approaches organizations are taking to close the gap: instrumenting pipelines to regenerate SBOMs automatically and building an owned vulnerability‑handling process, or consuming already‑vetted components so provenance is resolved before a component enters a build. ActiveState’s offering — its Curated Catalogs — is presented as an example of the latter. According to Warden, the catalog spans 12 language ecosystems, provides immutable build‑time provenance, and is remediated under contractual SLAs: 5 business days for critical severity once an upstream fix exists, 10 days for high, and 30 days for the rest.

What this means for open‑source maintainers, manufacturers, and procurement leaders

• Open‑source maintainers: the disclosure Warden recounts is already the practical reality many maintainers face — triage large, sometimes inflated reports, and manage extortion threats. The CRA will move that pressure from volunteers to firms shipping software into the EU.
• Manufacturers selling into the EU: they must be able to answer “what shipped, and when did we first know” within a 24‑ to 72‑hour window for actively exploited vulnerabilities, even though remediation averages cited in industry reports are far longer.
• Procurement and product teams: Warden suggests treating provenance as a property of your supply chain (instrumented and continuous) or buying for‑attestation components so provenance questions are answered before build time — emphasising an operational choice between building in‑house capability or buying it.

Warden closes with a practical test: pick a product your team shipped six months ago, and time how long it takes to list what’s in it and when you first knew about the last critical CVE. “If that takes longer than 72 hours, you already have your answer,” he writes. For organizations selling into the EU, September 11, 2026 will convert volunteer‑era questions about disclosure and provenance into legal obligations — and the clock starts ticking.

Original story