Your Scanner Is Not a Governance Decision

Your Scanner Is Not a Governance Decision

By Jacqueline Winter, Chief Financial and Operations Officer, ActiveState

IBM just committed $5B to open source security. A cluster of software supply chain campaigns has stolen cloud credentials, SSH keys, and developer secrets across three registries. You have a scanner running. Here is the problem: none of those three things answer the question your organization will be asked when something goes wrong. Who decided what open source software was allowed in your environment? When did they decide it? Where is the record?

Most organizations cannot answer that question. Not because they lack tools. Because they have never treated it as a question that required a decision.

A scanner tells you what entered your 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 those is a governance decision. None of them produces the documentation that a breach investigation, a regulatory audit, or a board conversation will actually demand.

IBM's Project Lightwell, $5 billion to build an industry clearinghouse for open source flaws and vetted fixes, is the market's answer to a governance gap that individual organizations were supposed to close internally. The size of the investment is a signal: the gap is larger than most organizations have acknowledged, and it has been open longer than most boards realize.

What the Balance Sheet Is Not Showing You

Open source software is a liability instrument that most organizations have never put on a ledger. It powers 98% of enterprise applications. Most of it was never selected with formal security criteria. None of it is being managed at the velocity that AI-assisted development now requires. The provenance is unknown. The management obligations are unassigned. The exposure window when something goes wrong is measured in months, not days.

A recent cluster of software supply chain incidents makes that liability concrete. TrapDoor seeded malicious packages across npm, PyPI, and Crates.io and stole cloud credentials, SSH keys, and environment variables. Cloud credentials are not an abstract security finding. They are access to infrastructure on the financial statements. The Glassworm botnet poisoned more than 300 GitHub repositories by targeting developer trust directly. BadHost, a known and patched Starlette vulnerability, sits unpatched in production at a significant share of AI agent framework deployments. EU CRA Phase 1 enforcement begins September 11, 2026, with mandatory reporting of actively exploited vulnerabilities within 24 hours, applying to products already on the market. Known unpatched vulnerabilities in production are now a compliance deadline, not just a security gap.

The governance question this raises is not whether your organization is secure. It is whether your organization made defensible decisions about its open source software, documented them, and named someone accountable for the gap between policy and actual exposure.

That is a different question than “Are we patched? It has a different answer. And it is the question that will be asked.

The Pattern I Have Watched in Other Domains

I have spent 20 years building financial and operational infrastructure across industries. The pattern that precedes a significant governance failure is identical whether the domain is financial controls, vendor risk, or software dependencies: organizations invest in tooling without changing how decisions are made, and the tooling solves symptoms while the structural problem compounds.

In financial governance, the equivalent of “we have a scanner” is “we have an auditor.” An auditor documents what happened. A governance structure determines what is permitted and who is accountable when permissions are violated. Organizations that conflate the two discover the distinction at the worst possible moment.

The security version of that moment is a breach followed by a board conversation about why no one documented the governance decisions that preceded it. “We had a scanner” does not survive that conversation. A scanner is a record of what you found. It is not a record of what you decided.

IBM's Project Lightwell and GitHub's new 2FA-gated npm publishing controls are both scanner-side improvements: they help organizations find problems faster and make registry exploitation harder. Both have genuine value. Neither one is the governance decision. Neither one produces the documentation of defensible choices that the post-incident conversation will require.

What the Regulatory Shift Actually Means

The EU Cyber Resilience Act and the SEC's disclosure requirements have changed the calculus in a specific way that I think is underweighted in most security conversations: the accountability is now explicitly personal.

This is not a general statement about organizational liability. It is a structural argument. The regulatory environment in 2026 has created personal exposure for executives who cannot demonstrate that they made defensible decisions before a breach, not just that they had tools running.

I sit in both chairs. That means I understand the personal accountability dimension from both sides. The CFO who cannot explain the financial exposure from an open source incident and the CISO who cannot produce the governance documentation are the same conversation. When those titles belong to different people, the gap between them is where the accountability falls through. When they belong to the same person, you cannot pretend the gap does not exist.

That is the clarifying thing about my position. I cannot hand this off to myself.

What a Defensible Posture Requires

I have worked through what it actually takes to close the gap between the CFO view and the CISO view on open source governance. It comes down to three things that most organizations have not yet made explicit:

• A formal decision about what open source software is eligible to enter the environment, made at the right organizational level and documented so it survives the person who made it

• Named accountability for that decision and for the ongoing management of what is in production, so that when a CVE drops there is someone who already owns the remediation, not someone who gets assigned to investigate

• A provenance record for every component in production, generated automatically, so that the question “are we affected’ takes minutes rather than the 54-day industry average for critical CVE remediation

None of this requires new technology. It requires a governance decision that most organizations have deferred because the cost of deferral was not visible until it became unavoidable.

IBM's $5 billion is the market making that cost visible at scale. The incident pattern that surrounds it is the threat environment making it operational.

The organizations that handle the next incident well are not the ones with the most sophisticated scanners. They are the ones where the CFO and the CISO, whether those are the same person or two different people, have already had the conversation and produced the documentation that proves it.