The technology gap closed years ago. The documentation gap is what regulators are about to test.

A scanner tells a security team what entered their environment. It does not tell them who decided it was allowed to. That distinction has mattered for years and cost almost nothing, because almost no one was asking the second question. That changes in September 2026, when the EU Cyber Resilience Act's vulnerability reporting requirements take effect, with full compliance, including SBOM generation and documented governance, following in December 2027.¹ For CISOs in regulated industries, the next six months are not a technology sprint. They are a documentation deadline.

The Question Most CISOs Cannot Answer

The question worth asking first: who approved the packages an organization's AI coding tools installed last sprint? Not who runs the scanner. Not who owns the vulnerability management program. Who approved the packages, and where is the record of that decision?

Most CISOs cannot answer it, and the gap is not a technology failure. It is a governance failure with a regulatory and financial consequence attached. The pattern is not new. It shows up in financial controls, in vendor risk, and in operational infrastructure the same way it is now showing up in open source software: a control exists, but when an auditor asks who owned a decision at a specific point in time, the organization discovers that the control and the accountability were never the same thing. Exposure is not measured by the size of the mistake. It is measured by whether a decision was documented at all.

The Exception Nobody Approved

The reason the gap opened is instructive. Most organizations have a dependency governance policy. Somewhere inside it is an exception nobody signed off on: code suggested by an AI assistant. When developers adopted AI coding tools, the governance question was never raised at the executive level. It was not a decision. It was an adoption, gradual, distributed, and mostly invisible to the people responsible for governing it. Most organizations now have a documented policy describing how open source components are evaluated and approved, running alongside a real intake process that bypasses that policy every time a developer accepts an AI suggestion. That is exactly the kind of gap a regulator or an auditor will find when they look, and the next six months are the window to close it deliberately, before someone else surfaces it.

A Scanner Is Not a Governance Program

Closing it requires a distinction most organizations have not made cleanly: a scanner is not a governance program. A scanner reports what entered an environment after it entered. An SBOM documents what accumulated. A patch workflow closes the gap after a vulnerable component is already in production. None of the three is a governance decision, and none produces the record that answers the question a board, an auditor, or a regulator is actually asking: who decided what open source software was allowed into this environment, when did they decide it, and where is the evidence? Treating the existence of a scanner as evidence of a governance program is a category error, and it is the error the CRA's reporting requirements are built to catch.

The Liability Nobody Priced

This is where the CISO conversation has to become a CFO conversation, because the underlying problem is a liability question, not a security question. Most CFOs who have managed an unpriced contractual obligation will recognize the shape of this one immediately: open source software has been acquired at scale, for years, under conditions that trigger no acquisition review, no due diligence process, and no documented ownership of the ongoing obligation. That it arrived for free is not evidence that it carries no obligation. It is evidence that the obligation was never tracked. Framed this way, the ask changes. Most security arguments ask a CFO to fund risk reduction. This argument asks a CFO to recognize an existing, unquantified liability, which is a problem finance already has processes for handling. For CISOs in regulated industries, that is a more productive conversation to have in the next six months than the traditional security pitch.

Free is not the same as without obligation, and finance leaders already know this from other domains. Land that cost nothing to acquire accrued environmental remediation costs over decades. Infrastructure that was already paid for accumulated deferred maintenance until deferred became immediate. The mechanism is consistent: when something costs nothing to acquire, it passes through no acquisition review, and the obligation attached to consuming it goes untracked until someone comes to collect. Open source software is the current version of that pattern, and the EU CRA is the mechanism converting it from a pattern into a dated obligation.

The Gap to Close, Not the Tools to Add

None of this is an argument for slowing AI-assisted development or treating open source software as the threat. It is an argument that the accountability gap in most organizations' governance is a documentation and ownership problem, not a tooling problem. The tools exist. Scanners run. SBOMs generate. What is missing in most programs is the record of who decided what was allowed, when, and why: the evidence that satisfies a board, an auditor, or a regulator before they ask for it.

The next six months are the window before the September 2026 reporting requirement changes what “we had a scanner” is worth as an answer. For CISOs in regulated industries, the priority is not more detection tooling. It is closing the accountability gap and building the governance infrastructure that turns security activity into documented decisions with an assigned owner. That is the conversation worth having with your CFO, your board, and your legal team, before someone external has it for you.