Open Source Is Free. Until Someone Comes to Collect.

 

Open Source Is Free. Until Someone Comes to Collect.

By Jacqueline Winter, CFO & CISO, ActiveState

Finance has a long history of discovering that the liabilities nobody tracked were the ones nobody paid for. Open source software is the current version of that story.

Free is not the same as without obligation. Every finance leader knows this. The land that cost nothing to use accrued environmental remediation costs over decades. The infrastructure that was already paid for accumulated deferred maintenance until the deferred became immediate. The financial instruments that required no upfront payment carried contingent liabilities that materialized at the worst possible moment.

The pattern is consistent across domains, and the mechanism is always the same: when something costs nothing to acquire, it goes through no acquisition review. No due diligence process triggers. No risk register entry is created. The obligation that attaches to the consumption never gets tracked, because tracking was designed for things with price tags.

Open source software is free. It is also, in every enterprise that has consumed it at scale without a governance process, a contingent liability that has never been formally accounted for. It carries known vulnerability profiles that change over time. It has licensing conditions that create legal exposure if left unmonitored. It has provenance characteristics that determine whether it is a defensible component of your software supply chain or an undisclosed risk sitting in production.

None of that showed up on an invoice. So none of it went through a review.

The TeamPCP campaign is a concrete example of what that unreviewed obligation looks like when an adversary finds it before an auditor does. Hundreds of compromised open source packages propagated through developer credentials and CI/CD pipelines into build environments that had established no intake criteria for what was eligible to enter. The packages arrived because they were free, because developers needed them, and because nothing in the procurement or governance process had been designed to evaluate software that did not cost anything.

That is not a security failure. It is a governance architecture that was never built for free things.

Some organizations have recognized this and responded with institutional structure. The Open Source Program Office, or OSPO, is the model that emerged from that recognition: a dedicated function responsible for open source intake policy, licensing compliance, and consumption governance. Companies that have built them treat open source the same way they treat any other material vendor relationship. They define what is eligible to enter the environment, who is accountable for that decision, and what happens when something that entered yesterday becomes a problem today.

The OSPO model works. It also remains uncommon. Across enterprises, adoption sits at roughly 26%. Which means that for the remaining 74% of organizations consuming open source at scale, the governance architecture does not exist. The intake review that would catch a compromised package before it reaches a CI/CD pipeline has not been built. The policy that would make the TeamPCP scenario harder to replicate is sitting on someone's roadmap, not in production.

Free things will keep arriving. The question is whether anyone in the organization has been formally tasked with deciding which ones are eligible to enter. The ones that were not reviewed do not stay free. They just defer the invoice. 

The Regulatory Environment Does Not Care What You Paid for It

The EU Cyber Resilience Act does not have an exemption for open source software consumed at no cost. SSDF compliance does not adjust its evidentiary standard based on the acquisition price of the components in question. SEC cybersecurity disclosure rules operate on a four-business-day timeline for material incidents that assumes an executive can explain what governance decisions were in place before the exposure, regardless of whether the underlying software was purchased or downloaded for free.

This is the moment the finance frame becomes more than analogy. Regulators are applying the same due diligence standard to open source software that finance has always applied to instruments with acquisition costs. The fact that open source was free is not a mitigating factor. In several interpretations of the CRA's scope, it is closer to an aggravating one: consuming a component without paying for it does not reduce your obligation to govern it, and in some cases signals that the formal vendor accountability structures that purchasing creates were also absent.

The EU CRA vulnerability and incident reporting obligations take effect September 11, 2026. SSDF compliance is already a federal contracting condition. Each framework is asking the same question in different language: did the organization make a documented, defensible decision about what was eligible to enter its software environment, and can it produce that documentation when asked.

Most organizations cannot. Not because the security team failed. Because the procurement process, the risk register, and the governance infrastructure were all designed around things that had price tags. The free software went in through a different door, and nobody built a review process for that door.

AI Opened That Door Wider

Before AI coding assistants, a developer choosing an open source dependency had to make a deliberate choice. Search for it, read the documentation, evaluate the maintenance history, decide. That effort was not a governance process. But it created friction, and friction slows accumulation. Packages that looked abandoned got skipped. The obligation that attached to each intake decision was, at least, attached to a moment of human judgment.

AI coding assistants removed the deliberate choice. A suggestion appears inline, looks authoritative, and accepting it takes a single keystroke. No evaluation step. No provenance check. No record of who decided what. JFrog's most recent data shows the steepest acceleration in malicious open source package volume in precisely the period AI-assisted development became standard practice. The volume of unreviewed components entering production environments is now growing faster than any manual governance process was designed to handle.

This is not a new category of liability. It is the existing unaccounted obligation accumulating faster, through a channel that generates no paper trail and triggers no review, because it still costs nothing.

NanoCo AI raised $12 million on the premise that AI agents need sandboxing, policy gateways, and human approval loops before they can be trusted in enterprise environments. That governance architecture is being applied to the agent layer. The open source software those agents consume when they generate and suggest code is, in most organizations, still going through the same unreviewed door it always has. The agent has controls. The free software the agent recommends does not.

Microsoft's release of RAMPART and Clarity for AI agent security testing reflects the correct instinct: governance needs to move earlier in the development process. The same instinct applied to open source dependency intake would address the underlying unaccounted liability before it becomes the subject of a regulatory inquiry.

What Accounting for It Actually RequiresThe Regulatory Environment Does Not Care What You Paid for It

Governing free software requires the same three things that governing any contingent liability requires, applied before the obligation materializes rather than after.

The first is a defined intake process: explicit criteria a component must meet before it enters the environment, owned by a named function, applied at the point of admission. Not a scan run after the fact. A decision made before the component arrives, the same way a procurement review happens before a contract is signed.

The second is ongoing accountability: a named owner and a documented timeline for every known vulnerability in the environment, with a record showing the organization acted on what it knew within a reasonable window. This is the equivalent of the remediation schedule that attaches to any identified liability on a risk register. The obligation was there. Someone owned addressing it. There is documentation showing they did.

The third is provenance: the ability to account for any component in production, where it came from, what criteria it met at admission, and who was accountable for the decision. This is not an SBOM generated after a breach. It is the audit trail that predates the question.

None of these require that open source software appear on a balance sheet. They require that the obligations attached to consuming it are tracked with the same discipline applied to anything else the organization is accountable for. The NIST NVD enrichment gap, acknowledged in April 2026 as a permanent structural limitation, is already degrading the scanner-based model most organizations have used as a proxy for this accountability. The proxy is failing at the same time the regulatory standard for the real thing is rising.

The board conversation that most organizations have not yet had is a simple one: who owns the governance process for what enters the software supply chain, what are the documented criteria, and what does the accountability structure look like when a regulator asks.

Contingent liabilities that go untracked do not disappear. They compound. And they are always more expensive to address after the inquiry than before it.