Open Source Is on Every Balance Sheet. Most Organizations Have Just Not Found It Yet.
By Jacqueline Winter, CFO & CISO, ActiveState
Every CFO understands that an unmanaged liability is a governance failure. It does not matter whether the liability is in the loan portfolio, the vendor contract stack, or the software supply chain. The principle is identical: if you have assumed exposure you have not priced, quantified, or assigned to an owner, you have a governance gap. And governance gaps do not stay academic.
Recent systemic failures have turned this abstraction into a hard reality for a number of organizations. The elementary-data package, downloaded more than 1 million times per month from PyPI, was pushing malicious code to production environments after attackers used a compromised GitHub Actions workflow to access signing keys and publish a credential-harvesting version. The Bitwarden CLI NPM package was compromised in a coordinated campaign designed to sweep credentials across cloud platforms, code repositories, SSH configurations, and AI tooling in a single execution. These are not hypothetical risk scenarios from a vendor pitch deck. They are documented, dated, and attributed incidents with organizations on the receiving end that had no idea the exposure existed until it materialized.
The Governance Gap Has a Name
Most enterprise organizations have treated open source security as a function owned by engineering. The security team runs scans. Findings go into a report. The report goes into a queue. The queue is managed by people who did not create the problem and cannot fully solve it with the authority they have. In every organization where I have seen this pattern, the document exists and the discipline does not.This is not a failure of effort or intention. It is a failure of structure. Open source software powers the majority of enterprise applications. It was adopted at velocity, without the governance infrastructure that velocity required, because the decision to adopt it was made at the speed of development rather than at the speed of risk management. Finance teams would recognize this pattern immediately. It is what happens when a procurement category grows past its controls. The exposure compounds, the controls lag, and at some point the gap becomes an incident.
The accountability question that has changed since 2025 is not whether organizations owe their customers and shareholders a defensible security posture. That was always true. The question that has changed is whether the executives at the top of those organizations now own the personal consequences of failing to build one. The SEC frameworks and the EU Cyber Resilience Act have both moved in the same direction: from company-level to individual-level accountability. A breach that followed from a governance gap the executive team was aware of, or should have been aware of, is no longer just a reputational and financial event for the company. It is a personal liability event for the people whose titles include the word "chief."
What Open Source Autonomy Actually Costs
The 2026 State of Open Source survey found that organizations are increasingly drawn to open source as a path to digital autonomy, specifically the ability to reduce vendor lock-in and maintain control over critical systems. That is a legitimate and well-reasoned motivation. But autonomy has a cost, and the cost is governance.
When you choose open source over a commercial alternative, you are accepting operational responsibility for the maintenance, vulnerability management, and supply chain verification that a commercial vendor would otherwise own. In a well-governed organization, that tradeoff is explicit, documented, and priced into the operational model. In most organizations, it is implicit, unpriced, and distributed across a dependency graph that no one has fully mapped. The organization that consumed the malicious version of elementary-data did not make a governance decision. It inherited the consequences of not making one.
Cisco's release of the Model Provenance Kit as an open-source tool for verifying AI model lineage is worth noting here because it points toward the direction governance needs to go. The tool asks a simple question for AI models: is this model what it claims to be, and can we verify its origin? That question applies with equal force to every open source package in every production build. Most organizations cannot answer it. The answer requires knowing not just what packages you have declared, but what packages actually entered your build, through what workflow, from what source, and whether any of that changed between declaration and execution.
The CFO's Version of the Problem
I want to be precise about what the financial and executive accountability framing actually requires, because I have watched it get misapplied. The point is not that executives should be afraid of breaches. Fear is not a governance strategy. The point is that the regulatory and legal environment has changed the structure of the incentives, and governance should reflect that change.
Specifically: the organizations most exposed in the current environment are those where security decisions are being made at the wrong level with the wrong information. The CISO who cannot get budget for software supply chain governance is not the problem. The governance model that makes software supply chain risk invisible to the people who control the budget is the problem. The federal guidance that has reframed the software supply chain as an active breach vector, not a compliance domain, is pointing at something real: the decisions that determine blast radius are not made during an incident. They are made in the architecture reviews, the procurement processes, and the budget cycles that happen long before any attacker shows up.
The organizations that treated open source governance as a technical problem to be solved below the CFO's visibility are now discovering that the CFO's visibility does not protect the CFO. The breach notification letter, the regulatory inquiry, the class action filing, they do not check whether the CFO knew about the dependency graph. They check whether the governance infrastructure that should have governed it was in place. In most enterprises, it was not.
The correct frame for the executive team is the same one that applies to every other material liability: documented due diligence, assigned ownership, and a defensible record of the decisions made. Open source is infrastructure. It is in production. It is in your AI development stack, your CI/CD pipelines, your developer tooling, and your build environments. The governance it requires is not different in kind from the governance you apply to financial instruments, vendor contracts, or data assets.
The organizations that pulled in the compromised elementary-data package had no provenance chain to consult and no record of a governance decision made before that package entered the build. The Bitwarden CLI compromise swept credentials across cloud platforms, code repositories, and AI tooling simultaneously, and the organizations on the receiving end discovered the exposure after the fact, not through governance. Both incidents share the same root: the tradeoff of choosing open source was accepted implicitly, distributed across a dependency graph, and never assigned to an owner. That is what unpriced autonomy looks like when it collects its cost.
It is different in the fact that most organizations have not yet applied it. The incidents of the last week are a signal about what that gap costs.



Comments
Post a Comment