The Challenge
Imagine receiving a GPG-signed vulnerability report listing 95 issues in your open source project. It follows proper disclosure protocol, arrives at the designated security addresses, and demands $100,000 to prevent public exposure with "Heartbleed-style press."
Two or three vulnerabilities are real; the rest are noise. Yet, you must investigate all 95 to find the legitimate ones, because a public disclosure could impact every deployment an attacker can find online.
This scenario happened to Shane Warden, Principal Architect at ActiveState, while reviewing security disclosures for a free software project. Open source maintainers often handle such pressure informally, using whatever tools they've put together, as there's no built-in infrastructure for this workflow.
On September 11, 2026, this informal reality becomes a legal requirement for every manufacturer selling products with digital elements in the EU. The Cyber Resilience Act's reporting obligations take effect: notify ENISA within 24 hours of learning a vulnerability is being actively exploited, with a full report due in 72 hours.
The engineering requirements, the part of the law that mandates how you build and maintain the product, don't start until December 11, 2027. That's fifteen months to "tell us fast" before proving you built things right.
The Environment and Constraints
This isn't just theoretical. 98% of applications contain open source components (Black Duck, 2026 Open Source Security and Risk Analysis Report). Nearly every manufacturer selling into the EU must answer the CRA's core question: what shipped, and when did you first know there was a problem?
The industry's remediation numbers aren't encouraging. The average time to fix a high or critical application vulnerability is about 55 days (Edgescan, 2026 Vulnerability Statistics Report). CRA enforcement will operate in the gap between that 55-day baseline and a 24-hour early warning clock.
Most organizations generated their first SBOMs like any compliance artifact: once, under deadline pressure, accurate for the moment it was produced, and outdated by the time anyone asked to see it again. A document from last March doesn't reflect what you're running today; it shows what you were running then.
Article 13 of the CRA requires the SBOM to be current. Article 14 sets the reporting timeline. The gap between these requirements is larger than most teams expect, because "we'll be compliant" doesn't mean "we can answer the question when asked."
The Approach Taken
Organizations are closing that gap in two ways.
Some are building the capability in-house: automating SBOM generation, establishing a documented vulnerability-handling process with a named owner, and treating provenance as a software supply chain property rather than a report created under audit pressure.
Others decide that re-deriving provenance for every open source component across every language ecosystem isn't a core skill. They use already-vetted, already-attested components, so the provenance question is answered before the component enters a build.
ActiveState developed Curated Catalogs for this second approach: open source components across 12 language ecosystems, delivered with immutable, build-time provenance, and remediated against contractual SLAs. Critical severity issues are addressed within five business days once an upstream fix exists, ten for high, and thirty for others.
This removes "who put this in our build, and when" from the list of questions your team must answer manually on a 72-hour clock.
Results and Metrics
The 95-item extortion report didn't wait for regulation to force the question. It asked, with a deadline and a price tag, whether the maintainer knew what was running and how fast they could prove it.
The CRA will soon ask every manufacturer selling into the EU the same question, at scale, with a clock ticking down to legal enforcement. There's a fifteen-month runway between reporting obligations and engineering requirements. That's enough time to build the capability if you start now. It's not enough if you're still deciding whether this applies to you.
What They Would Do Differently
Nobody knows yet how strictly ENISA will enforce Article 14 in its first year. Anyone claiming certainty is guessing.
But the pressure open source maintainers already face, the 95-item reports, the disclosure timelines, the need to know what shipped and when, is about to become the operational reality for the entire software world.
The mistake is treating September 11, 2026, as the finish line. It's the start of enforcement for a question you should already be able to answer.
Takeaways for Your Team
Pick a product your team shipped six months ago. Time how long it takes to determine 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.
Don't wait for the deadline to discover that "we'll be compliant" didn't mean "we can actually answer the question when asked."
The CRA's fifteen-month runway is a visibility requirement, not a security one. You're not being asked to fix everything before September 2026. You're being asked to know what you shipped and prove when you learned about problems with it.
That's the question the extortion report asked. That's the question ENISA will ask. The only variable is whether you're answering it under legal pressure or because you built the capability before you needed it.
