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 wait for the problem to be solved upstream, the plan no longer has a mechanism. The direction of travel is not toward less accountability for the organizations consuming this software. It is toward more, and on someone else’s timeline.

Accountability Now Has a Name on It

The shift that matters most for security leaders is not the regulation itself. It is who answers for it. A security failure tied to an unmanaged dependency is no longer only a company problem. It is a personal one for the executives whose titles include the word chief, and the question of whether the team made defensible decisions before the incident is now the question that determines how the aftermath goes. The CRA does not invent that accountability. It writes a deadline next to it.

The Exposure Was Never Put Through a Process

The obligation now landing on your desk was never put through the process that would have made it defensible. Every other material liability your organization carries went through one. Someone evaluated it, priced the risk, and signed. Open source software is the exception. A vendor contract triggers procurement, a legal review, and a signature. A package pulled into a build on a Friday afternoon triggers none of those. The due diligence your finance function applies to a five-figure software contract was never applied to a dependency that now runs in production across every product you ship.

The obligation did not disappear because no one logged it. It compounded off the books. That is the same failure pattern as an unmanaged liability in any other part of the business. When no one at the top owns the exposure, no one at the bottom can resolve it. By the time it surfaces, it surfaces as a finding in an audit or a clause in an acquisition, not as a line item anyone chose to carry.

A Scanner Alone Is Not a Defensible Decision

A new class of CI/CD vulnerability got past the security teams at Microsoft, Google, and the Python Software Foundation, because their scanners read each workflow in isolation and the attack lived in the chain between them. This is not a criticism of anyone’s tooling. It matters because of what it means in a regulatory filing or a customer audit.

“We had a scanner” is not a defensible decision. It describes a tool. The question a regulator, a board, or an acquirer asks after an incident is narrower and harder to answer. Who decided this component was allowed into the environment, on what basis, and can you produce the record. For most organizations the honest answer is that no one decided, because the decision was never owned by anyone in particular. That is what the filing looks like when the answer to a hard question is the name of a product instead of the name of a person.

AI Turned a Slow Problem Into a Fast One

AI-assisted development is accelerating open source consumption faster than any review process was built to handle, and the same disclosure found AI agents reproducing insecure patterns at machine speed across millions of repositories. This is not a future concern. The exposure that used to compound over years now compounds over sprints, and the governance built for deliberate human dependency choices was never designed for machine-speed ones.

Consider how the newest open source AI coding models reach production. A capable model is published, freely downloadable and modifiable, and within days an engineering team has adopted it as a daily tool. That is the same frictionless path every other dependency took, applied now to the systems that write and review your code. The component count grows, the provenance questions multiply, and none of it routed through a control that would have asked who approved it or on what basis.

The defensible position was never about having the most tools. It was about being able to show that someone made a decision, before the incident, about what the organization was willing to run.

Open source software earned its place in modern software by being frictionless to adopt. That same frictionlessness is the reason the liability never went through the process that would have made it defensible. The gap closes one of two ways. You close it on your own schedule, with a documented decision about what is allowed into your environment and a name attached to it. Or a regulator, a customer, or an attacker closes it for you, on theirs.