Your CISO Cannot Answer the Question Your CFO Is About to Ask

 

Your CISO Cannot Answer the Question Your CFO Is About to Ask

By Jacqueline Winter, CFO & CISO, ActiveState

AI-assisted development created an accountability gap that most security leaders cannot fill. The regulatory and financial consequences are arriving on schedule.

A CFO reading the current software supply chain security headlines would ask their CISO one question: who approved the packages your AI coding tools installed last sprint? Most CISOs do not have a satisfying answer yet. That gap is not a technology failure. It is a governance failure with a specific regulatory and financial consequence attached to it.

I have watched organizations make this mistake in other domains. A financial control looks adequate until an auditor asks who owned the decision at a specific point in time, and the organization discovers that the control existed but accountability did not. The resulting exposure is not measured by the size of the mistake. It is measured by the documented evidence of whether someone was accountable for it.

The current AI coding agent software supply chain problem is that failure mode, running at development speed.

Here is what has changed. Before AI coding tools entered the development workflow, there was a decision moment. A developer searched for a package, chose it, and committed it. That decision was uninformed in many cases and ungoverned in most, but it was traceable. A package arrived because someone made a choice.

Now the package arrives by AI suggestion. The developer accepts with a single keystroke. The suggestion looks authoritative. The provenance question, where did this come from and who is accountable for it, never surfaces. There is no owner. Security teams are discovering this when a CVE drops in a dependency that nobody recalled selecting, because nobody did select it. An AI tool made the recommendation and the developer took the path of least resistance.

The CSO reporting on supply chain attacks targeting AI coding agents names the specific attack pattern this accountability gap enables: attackers are now creating packages specifically designed to be recommended or installed by autonomous coding tools. The attack works because the governance layer that would intercept it was never built. It is not that organizations have weak governance for AI-suggested packages. It is that most organizations have no governance category for AI-suggested packages at all. 

From where I sit as a CFO, that is a liability that does not appear on any ledger the board reviews. It should.

The regulatory environment is making that argument for me. EU CRA vulnerability reporting obligations apply from September 2026, including for products already on the market. SSDF compliance is already a federal contracting condition. EO 14028 established SBOM requirements that organizations have been treating as aspirational while their AI coding tools accumulate dependency debt with no provenance chain attached. The organizations that will face the most difficulty when a regulator asks about their software supply chain provenance are the ones where the answer depends on reconstructing what an AI tool suggested and a developer accepted, with no governance record in between.

That reconstruction is not hypothetical. It is the conversation that happens after a breach, when the question is not just whether you were attacked but whether you had a defensible security posture before the attack. The organizations that can point to SLSA Level 3 attestation, a contractual remediation SLA, and a documented ingestion policy for AI-suggested dependencies are in a fundamentally different position than the organizations pointing to a scanner that found the problem after it was already in production.

The VentureBeat piece on the agent integration layer gap names something I want organizations to sit with: there is no detection category in current SAST, SCA, SBOM, or CVE workflows for malicious SKILL.md files and agent instruction sets that can poison AI coding agents. Security teams are being asked to defend a perimeter their tools do not cover. The gap is not a tooling lag. It is a governance architecture gap. The decision about who owns that layer has not been made.

I am not interested in pointing fingers at the security leaders working inside these constraints. The organizations I talk to have CISOs who understand the problem clearly and are operating within organizational conditions that make the right decision difficult to fund and harder to staff. That is itself a governance failure, and it starts above the CISO's desk.

The question for executive leadership is not whether the CISO has a plan. The question is whether the organization has made the governance decision that gives the plan authority, resources, and accountability. Most organizations have not. They have a security function. They do not have a board-level commitment to the governance posture that function requires to actually work.

The AI acceleration makes this unavoidable in a way it was not twelve months ago. AI tools are pulling in dependencies at a volume and velocity that human-scale governance was never designed to manage. The organizations that respond by adding more scanners are managing symptoms. The organizations that respond by governing the ingestion point, by establishing what the AI agent is allowed to install and attesting to where it came from, are building the posture that survives the regulatory inquiry and the post-breach review.

The CFO question I opened with is not hypothetical. It is the question that arrives after a breach, inside a regulatory inquiry, or on the day a board member reads a headline and calls the CISO directly. The organizations where that question has a documented answer are the ones where someone in the executive suite decided that open source governance was their problem, not just the security team's problem.

Most organizations are not there yet. The regulatory clock and the AI acceleration mean they are running out of time to get there.