The Liability Nobody Put on the Balance Sheet

 

The Liability Nobody Put on the Balance Sheet

By Jacqueline Winter, CFO & CISO, ActiveState

Most organizations have detailed processes for approving financial instruments they take onto their books. Open source software does not seem to get the same treatment. This week's events are a useful reminder of what that inconsistency costs.

Every CFO understands that an unmanaged liability is a governance failure.

When a company takes on a contractual commitment, it runs due diligence. It documents the decision. It assigns ownership of the ongoing risk. It does not simply accept the commitment because it arrived through an approved channel with valid paperwork.

Open source software is on every balance sheet in the industry, and in most organizations, it has never been through that process.

I have seen this failure mode in other domains. In financial controls, in vendor risk, in operational infrastructure. The pattern is identical every time: an organization builds processes for the risk categories it recognizes as serious, and accumulates exposure in the categories it has not yet named as its own. The category eventually gets named, usually at a point that is considerably more expensive than the process would have been.

Open source software governance is at that point now.

What This Week Named Plainly

The Mini Shai-Hulud campaign compromised hundreds of open source packages across major registries by using valid credentials to sign malicious releases through legitimate CI/CD pipelines. TanStack. UiPath. MistralAI. OpenAI confirmed an incident tied to the same attack, affecting employee devices and a limited amount of credential material.

The packages passed signature verification. They passed the scanner. The SBOM recorded them accurately. None of that mattered, because the compromise happened upstream of every check the organization ran.

CISA and G7 partners released AI SBOM guidance in the same week, expanding the minimum elements for bills of materials to cover AI models, datasets, and AI-specific dependencies. The guidance is correct in what it asks for. It also includes a sentence worth putting in front of every board that is treating SBOM compliance as its primary software supply chain strategy: disclosure alone does not prove an AI system is trustworthy in production.

That sentence is not specific to AI. A bill of materials is documentation. Documentation records what entered your environment. It does not change the conditions under which it entered, and it does not make a defensible governance decision retroactively.

"We have a scanner" is load-bearing corporate for "we have no idea what is in our software, but we have a tool that produces a document that suggests otherwise." The SBOM expands that document. It does not close the gap.

The Decision That Was Never Made

Due diligence is not a concept invented for security. It has governed every material decision in finance, M&A, and vendor risk for decades. The question of whether a counterparty is who they say they are, whether the instrument is what it claims to be, whether the ongoing risk has a named owner: these are standard practice in every domain where accountability is taken seriously.

Software supply chain governance requires the same decisions. Which open source software components are eligible to enter this organization's environment? Who made that determination? On what basis? Who owns the ongoing provenance?

In most organizations, those questions produce a pause.

The pause is the governance gap.

The sourcing decision, which packages are eligible to enter at all, has defaulted in most organizations to: whatever the trusted registry lists, whatever has a valid signature, whatever the scanner does not flag. No one explicitly made that decision. It was inherited, one dependency at a time, by developers working against deadlines in conditions that were never designed to support a different outcome.

The people doing that work are not the problem. The absence of a decision made above them is the problem. I have seen this before. When accountability is distributed across too many owners, or assigned to no one in particular, the outcome is the same regardless of domain: no one is responsible, so nothing changes, until the moment when someone has to explain what happened.

Where AI Moves the Stakes

AI coding tools have accelerated this exposure in a way that should change the urgency of the conversation at the executive level.

Before AI-assisted development, there was at least a moment of human judgment in the dependency selection process. Not a rigorous security review. But a developer searching for a package, checking its maintenance status, considering alternatives. That friction filtered things out.

AI tools removed that pause. A suggestion appears inline. Accepting it is a single keystroke. The volume of open source software entering enterprise environments is increasing at a rate that no manual governance process was designed to handle. The scrutiny applied to each component is decreasing at the same rate.

The accountability gap, the gap between what is actually in your software environment and what any executive could defensibly explain about how it got there, is growing every sprint.

The regulatory environment has been moving toward personal accountability for exactly this gap. EU CRA Phase 1 takes effect September 11, 2026. SSDF compliance is already a federal contracting condition. SEC disclosure rules require a materiality determination that puts the defensible-decision question in front of legal and finance, not just security.

These are not new requirements arriving at an inconvenient time. They are the formalization of an accountability standard that has always applied to material risk. Software supply chain exposure is material risk. It is on every balance sheet. Most organizations simply have not put it there yet.

What a Defensible Posture Actually Requires

The organizations that will answer a regulator's questions without incident, or navigate the aftermath of a supply chain event without compounding the damage, are the ones that can point to governance decisions, not tooling outputs.

That means being able to answer, in advance: which open source software components are eligible to enter this environment, who determined that, on what basis, and who owns the ongoing provenance. It means the documentation reflects a decision, not just a record of what arrived.

 A scanner produced both answers, only one of them is something an executive can defend. The distinction is not technical.

The financial analogy holds here, as it does in most domains where governance has been taken seriously. Organizations do not accept financial instruments onto their books because the paperwork looked valid. They run due diligence. They assign ownership. They document the decision.

Open source software is not different. It is simply the category where most organizations have not yet applied the standard they already hold everywhere else.

The gap between current practice and a defensible posture is not a technical problem. It is a governance decision that the executive team has not yet made. The question is whether that decision gets made before the event that makes it unavoidable.