CRA Didn't Invent Your OSS Governance Problem. It Priced It.

Blog

CRA Didn't Invent Your OSS Governance Problem. It Priced It.

Jonny Rivera

August 21, 2026

The average time to remediate a critical CVE runs around 54 days industry-wide. The EU Cyber Resilience Act's Article 14 requires something different: a 24-hour early warning to ENISA once you're aware a vulnerability is being actively exploited. The reporting mandate goes into effect on Sept 11, 2026, followed by a fuller notification 72 HOURS once a fix exists. It adds a documented awareness-and-disclosure obligation in addition to your security measures. This is probably something your team has never had to produce before.

What matters for your planning purposes is there is now a documentation and governance obligation your team has to fulfill. It has a deadline, a name, and regulations to back it up.

Key Takeaways

EU CRA Article 14 requires a 24-hour early warning for actively exploited vulnerabilities starting September 11, 2026, for products already on the market. Full compliance, including SBOM and CE marking requirements, is enforced from December 11, 2027.
CRA's legal floor for SBOMs is top-level dependencies only, but 64% of open source components in production are transitive. This means that a bare bones SBOM leaves most of your exposure undocumented.
Roughly 14% of developer time already goes to security work. CRA will add additional time to a developer’s workday due to documentation, reporting, and audit trail requirements.
This is a build versus buy decision, and the build path is slower than it looks on a roadmap.
This post reflects our current understanding of CRA and isn't legal advice. Confirm scope and applicability with your legal team.

The 24-hour window is a different kind of problem than the ones you've solved in the past

Your team has gotten good at triaging CVEs against actual exploitability and runtime relevance. That's the right instinct, and it's saved a lot of wasted remediation cycles. But the EU CRA isn't asking you to triage faster. It's actually asking you to do something different:

Can you map a new vulnerability to every affected product and version within hours?
Can you produce a documented record of when you became aware of the issue, what you did as a result of it, and how long it took you?

That's a distinct governance layer sitting on top of the vulnerability detection layer most teams already have: rapid mapping, documentation, and a timestamped record of awareness and action.

Transitive dependencies are the coverage gap, and they're the majority of your risk

About sixty-four percent of open source components in production are transitive dependencies, meaning your team didn't necessarily choose them directly. In addition, ninety-eight percent of applications include open source. If your SBOM stops at the packages your team explicitly picked, you're meeting CRA's top-level floor on paper while covering only the smaller share of your actual exposure. There’s a significant chance that the vulnerabilities you need to report aren’t listed within that SBOM.

I'd ask your team two direct questions:

Is your SBOM in a standard machine-readable format like SPDX or CycloneDX, not a spreadsheet someone updates before an audit?
Is your SBOM current as of this week, or as of your last release?

Those two answers determine whether you're covered or exposed, and most teams I talk to are more exposed than they think on the second one.

What this actually costs, and why it's worth pricing out

At 4 to 8 developer hours per CVE remediation, the annual engineering cost of unmanaged open source adds up fast, and CRA adds a documentation and audit trail requirement on top of every one of those hours. That's the real build-versus-buy math: can your team maintain a validated, current package inventory across every language ecosystem you ship, with defined SLAs for critical and high CVEs, while also standing up an ENISA reporting pipeline and the technical documentation CRA requires, all without pulling capacity from your actual roadmap.

For some organizations, the answer is yes, and building it makes sense. For most, the answer is that it's a full-time and ongoing obligation competing directly with feature work with no end date.

The split-ownership problem is where deadlines get missed

CRA creates a specific structural issue: security owns the compliance requirement, and engineering owns the implementation. Without a named owner bridging both sides, the work tends to get done twice, or not at all until it's urgent. If a CVE dropped tonight, does your team know whether they're responsible for the 24-hour filing, or whether that sits entirely with security? If the answer is "we'd sort it out," that's worth resolving before September, not during an incident.

The paved road is the model that scales past this

This is the same principle behind the ActiveState Curated Catalog: governance gets embedded at the point where your team already pulls packages, not bolted on as a separate review step. Developers and AI coding assistants keep resolving dependencies the same way they always have. What's different is that the packages they receive are already built from source, scored across the full dependency tree, and shipped with a provenance record and an SBOM attached. When a CVE surfaces, the rebuild and redelivery happen on a contractual SLA.

Whether your specific products and business model satisfy CRA is a determination your legal team needs to confirm. What it does is remove the manual reconstruction work the moment a vulnerability in your stack is confirmed under active exploitation, so your team is answering the regulator's question from a record that already exists instead of building one under a 24-hour clock.

Where to start

Ask your team the following questions:

Does your SBOM cover transitive dependencies in a standard format?
Do your remediation SLAs have formal documentation?
Who owns the 24 hour filing if a CVE was reported today?

Standing up a process that holds up under regulatory scrutiny takes most companies at least 60 to 90 days, September 11 isn't going to move to accommodate a busy roadmap.

AI is accelerating how fast your team pulls in open source. The governance layer underneath it is what makes that sustainable instead of a liability with a filing deadline attached.

Talk to an ActiveState expert about where your organization stands.

About the Author: Jonny Rivera is ActiveState's Senior Director of Product Management, working closely with the ActiveState engineering team on open source software security. ActiveState provides a curated, provenance-backed library of built-from-source open source components and contractual remediation SLAs, so teams can build secure, reproducible software environments without trading away developer velocity. Learn more at ActiveState.com.

Frequently Asked Questions

What does the EU CRA actually require engineering teams to build or maintain?

CRA requires a machine-readable SBOM covering direct and transitive dependencies, kept current as your dependency graph changes, plus a documented vulnerability handling process your team can execute and demonstrate to a regulator. It also requires the operational ability to map an actively exploited vulnerability to every affected product and version within hours.

How does the CRA reporting timeline compare to how teams currently handle CVEs?

The average time to remediate a critical CVE across the software industry is around 54 days. CRA's Article 14 requires something on a different clock: a 24-hour early warning to ENISA once your team becomes aware a vulnerability is being actively exploited, with a fuller notification at 72 hours and a final report once a fix exists. Meeting that requires an awareness-and-documentation capability most remediation workflows were never built to produce.

Why does transitive dependency coverage matter so much for CRA compliance?

Sixty-four percent of open source components in production are transitive dependencies that a team didn't choose directly. Most existing dependency inventories stop at direct dependencies. The EU CRA's legal minimum only requires coverage of top-level dependencies, but an inventory that stops there leaves the majority of a team's actual risk undocumented. That creates a lack of tracking and documentation for vulnerabilities that do hit your organization.

Should engineering build CRA-readiness internally or buy it?

That depends on capacity and roadmap priorities. Building it means maintaining a validated package inventory across every language ecosystem you ship, current SBOM generation, defined remediation SLAs, and a tested ENISA reporting pipeline, on an ongoing basis, not as a one-time project. At 4 to 8 developer hours per CVE remediation, it's worth pricing out honestly against what your team could ship instead.

Who is actually responsible for CRA compliance, security or engineering?

CRA creates a split obligation. Security typically owns the compliance requirement, and engineering owns the technical implementation, including SBOM generation and remediation execution. Without a named owner bridging both functions, work tends to get duplicated or delayed until it becomes urgent. Confirming this ownership internally, before September, is one of the more common gaps we see.