Last year, a vulnerability report landed in the inbox of an open-source project I help maintain. It claimed 95 vulnerabilities, delivered with a **GPG** signature and proper responsible disclosure. Yet, something felt off. While two or three of the 95 were legitimate, the sheer volume of the report, followed by a demand for $100,000 to prevent public disclosure, highlighted a growing challenge. This incident, though informal, mirrors the operational realities that the **EU Cyber Resilience Act (CRA)** will soon impose on the entire software world. Effective September 11, 2026, manufacturers with products containing digital elements sold into the EU must notify **ENISA** within 24 hours of discovering an actively exploited vulnerability, with a full report due within 72 hours. The engineering requirements of the law, dictating how products are built and maintained, will follow on December 11, 2027. This 15-month gap means the initial phase of the **CRA** is primarily a visibility requirement, not an immediate mandate for improved security engineering. As **ActiveState** CEO **Abby Kearns** noted, the core question will be: "what shipped, and when did we first know there was a problem with it?" Open-source maintainers already grapple with this, often with cobbled-together tools and under immense pressure. ## The Challenge is Knowing What Actually Shipped We've seen similar scrambles before. When the U.S. issued **Executive Order 14028** in 2021, requiring **Software Bills of Materials (SBOMs)** from federal vendors, many organizations generated them as a one-time compliance artifact. These **SBOMs** were often stale by the time they were needed, failing to reflect the current state of software. The **EU CRA** is more explicit; Article 13 demands a current **SBOM**. This gap in understanding what's in production is significant. With 98% of applications containing open-source components (according to **Black Duck**'s 2026 Open Source Security and Risk Analysis Report), nearly every manufacturer selling into the EU will face this challenge. They must prove what shipped and when they knew about any issues, all while a legal clock ticks. The industry's own statistics on remediation times are not encouraging. The average time to fix a high or critical application vulnerability is about 55 days (Edgescan's 2026 Vulnerability Statistics Report). The **EU CRA**'s enforcement will operate within the stark contrast of a 24-hour early warning and 72-hour full notification window against this remediation baseline. Organizations are addressing this in two ways: 1. **In-house Muscle Building:** Instrumenting their pipelines to automatically regenerate **SBOMs**, establishing documented vulnerability-handling processes, and treating provenance as an inherent property of the software supply chain. 2. **Consuming Vetted Components:** Opting to use already-attested and curated open-source components, where provenance questions are answered before the component even enters a build. Both approaches can work, but waiting until month fourteen of the runway to discover a lack of actual capability is a significant risk. Most engineers prefer to focus on building great software, not deep introspection into their supply chains. **ActiveState**'s Curated Catalogs aim to bridge this gap, offering open-source components across 12 language ecosystems with immutable, build-time provenance. They also provide remediation against contractual **SLAs**: 5 business days for critical severity once an upstream fix exists, 10 for high, and 30 for the rest. This approach complements existing processes and removes the burden of manually tracking component origins and vulnerability timelines within a tight 72-hour window. While the strictness of **ENISA**'s enforcement in the first year remains to be seen, the 95-item report I described earlier serves as a stark reminder: the question of knowing what you're running and how quickly you can prove it doesn't wait for regulations. The **EU CRA** is simply about to ask this question of every manufacturer selling into the EU, at scale, with legal implications. Don't wait for September 11, 2026. Pick a product your team shipped six months ago. Time how long it takes someone to detail its components and when you first learned about its last critical **CVE**. 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.