Skip to main content

The EU CRA Doesn't Change What Good Open Source Governance Looks Like. It Just Makes the Accountability Visible.

The EU CRA Doesn't Change What Good Open Source Governance Looks Like. It Just Makes the Accountability Visible.

By Jacqueline Winter, CISO & CFO, ActiveState

The Linux Foundation's 2026 CRA Awareness and Readiness Report documents where the industry stands. CFOs and CISOs who have already built a defensible governance posture are not reading it as a warning. They are reading it as context.


Due diligence is not a concept invented for cybersecurity regulation.


It has governed every material decision in finance, M&A, and vendor risk management for decades. The question is not whether open source software risk requires due diligence. The question is why most organizations accepted a lower standard for it than they would for any other contractual commitment.


The EU Cyber Resilience Act (EU CRA) provides the answer: because no one required otherwise. That changes in December 2027.


The Linux Foundation's 2026 CRA Awareness and Readiness Report surveys 843 respondents on where the industry stands. The headline findings are informative. Two-thirds of respondents are not yet familiar with the regulation, essentially unchanged from 2025. Only 41% of manufacturers expect to be compliant by the December 2027 full enforcement date.


These numbers describe a real readiness gap. They also describe a gap that is entirely closable with the right governance decisions made at the right level of the organization.

What the EU CRA Formalizes

The EU CRA applies to manufacturers that place products with digital elements on the EU market. For those organizations, it creates obligations around vulnerability handling, software transparency, and active due diligence over the open source components integrated into their products. Fines for non-compliance reach up to €15 million or 2.5% of global annual turnover.


I read the EU CRA as a formalization of accountability that was always implied but never enforced. The CFOs and CISOs who have already treated open source software as a managed liability, with documented evaluation criteria, continuous SBOM generation, and an auditable record of what was approved and why, are not doing new work to meet these requirements. They are reporting on work they were already doing.


The organizations that are further behind are the ones that treated open source as assumed infrastructure rather than a managed asset. That posture was always a governance gap. The CRA makes it a compliance gap with a specific deadline.


The CFO Question That Changes the Conversation

I have found that one question moves the EU CRA from a security team concern to an executive concern faster than any amount of briefing material.


Does your organization have a documented process for how open source software components are approved before they enter your products? And is that documentation something you could show an EU regulator in September?


If yes, you are in substantially better shape than most of the industry. If no, the path is clear and the timeline is workable.


The September 2026 deadline is when manufacturers must begin reporting actively exploited vulnerabilities and severe security incidents. That deadline requires a process for identifying those vulnerabilities across your dependency tree, not just a record of what is in it. It requires an accountability owner who can answer questions about the process. It requires documentation that was built continuously, not assembled the week before the audit.


None of those things require new technology. They require an organizational decision, and they require that decision to be made above the security team.

The Cost Structure of the Current Default

The report surfaces a data point that belongs in a CFO's line of sight. Organizations maintaining private forks of open source components as a compliance workaround spend an average of $258,000 in labor per release cycle. For large organizations, that exceeds 11,000 labor hours.


This cost does not appear on any standard financial report. It is absorbed into engineering headcount, invisible to the governance layer above it. And under the EU CRA's requirements for an auditable provenance chain, it may not be producing the compliance posture it is intended to justify. A private fork with a patch history that diverges from the upstream project is not a clean provenance record.


The report makes the economics explicit: contributing fixes upstream produces the kind of transparent, well-documented software supply chain the CRA demands, and it amortizes maintenance costs across the broader user community rather than carrying them entirely internally. The financially rational path and the compliant path converge. That is not an accident. It is how well-designed regulation works.


The Accountability Structure the CRA Builds

The regulatory environment has made open source governance a C-suite accountability matter. The EU CRA, the SEC's cybersecurity disclosure requirements, and EO 14028's SBOM mandates are consistent in direction: the documentation of defensible security decisions is now the minimum standard for organizations operating in regulated markets.


I have spent my career building financial and operational infrastructure that creates accountability at the right level of an organization. The pattern I have watched repeat across domains is consistent: organizations that treat a material risk as someone else's problem accumulate exposure until regulation requires them to treat it as their own.


The EU CRA is that inflection point for open source software governance. The organizations that reach it with a defensible posture already built will experience it as a compliance milestone. The ones that reach it without one will experience it as a deadline.



The difference between those two outcomes is a governance decision. It does not require new technology. It requires the question to be asked at the right level.


The organizations that make that decision this quarter are the ones that will be ahead of it.
Labels:

Comments

Post a Comment

Popular posts from this blog

Open Source Compliance Now Has a Deadline. Accountability Now Has a Name.

Open Source Compliance Now Has a Deadline. Accountability Now Has a Name. The US federal safety net that followed Log4j has thinned in the same window the EU Cyber Resilience Act wrote obligations for commercial users of open source software into law, with reporting requirements beginning September 2026. The accountability for what enters your products is moving toward the organizations that consume it, on someone else's timeline. Two things happened to open source software security in the same window, and together they change who is on the hook. The US federal effort that grew after the 2021 Log4j crisis has largely lapsed, with key personnel gone and the initiatives quiet. At the same time, the EU Cyber Resilience Act turned obligations for commercial users of open source software into law, with vulnerability and incident reporting requirements applying from September 2026. One backstop thinned. The other became a requirement with a date attached to it. If the plan was to wai...
Post a Comment
Read more

The SBOM Just Became a Liability With a Date on It

The SBOM Just Became a Liability With a Date on It When a best practice becomes a product requirement, it stops being a security artifact and starts being a financial one. The question now is whether the document you are obligated to produce is true. The EU Cyber Resilience Act is moving the software bill of materials from a best practice to a product security requirement, with the law’s full application arriving in December 2027 . If your company ships software into the EU, the character of one of your obligations just changed. The software bill of materials you used to produce because it was responsible is becoming one you are legally required to produce because a regulator says so. That is not a procedural change. It moves the bill of materials off the security team’s task list and onto the company’s books, and most organizations have not adjusted to what that means. A best practice and a requirement are not the same liability Every CFO understands that an unmanaged liability is a ...
Post a Comment
Read more

Discovery Is Outrunning Remediation Everywhere. That Is Not Just a Technology Problem.

Discovery Is Outrunning Remediation Everywhere. That Is Not Just a Technology Problem. A model found 1,596 unpatched vulnerabilities in open source projects last month. The industry’s answer was more infrastructure for finding problems. That was never the part that was broken. Anthropic, Google, OpenAI, Microsoft, and more than a dozen other organizations just did something companies rarely do voluntarily. They pooled money into a shared body, called Akrites and hosted by the Linux Foundation, because none of them could keep pace with open source vulnerability discovery and remediation on their own. Organizations build shared infrastructure at this speed for one reason. A risk got too expensive for any single balance sheet to absorb quietly. That is what a captive insurance pool is. A group of companies decides a risk is real and common enough that carrying it alone costs more than carrying it together. Nobody calls that admission a taskforce. They call it underwriting, and they usual...
Post a Comment
Read more