Open Source Governance Has to Decide What Gets In Before AI Pulls It
Eric Gallagher
November 3, 2026
Share post:
An open source governance program can show the board what reached production, release by release, in a software bill of materials (SBOM) and a dependency dashboard.
Ask who decided each of those components should be there, and when. In most enterprises, that question produces a pause.
The pause is the governance gap.
Security leaders see the same gap. In The AI Remediation Bill, research ActiveState published on October 20, 2026 with Moving Horizon, 55% of 307 enterprise security, governance, platform, and engineering leaders said control, defined as preventing unapproved open source from entering, is a bigger challenge than visibility.[1]
Key Takeaways.
SBOMs and dependency dashboards record what entered an organization's software after the decision to let it in was made, or never made.
AI coding assistants and agents now add open source dependencies faster than anyone reviews that record.
In The AI Remediation Bill, 55% of enterprise leaders name control as a bigger challenge than visibility, and 83% say reducing breach risk is the strongest argument for leadership.
Governing at the right layer means deciding which components are eligible before anyone requests them, so every developer and agent inherits the decision and the inventory shows that it held.
How open source governance programs work today
A typical governance program is built around a record. It lists the open source components in each build and checks that list against advisories and license rules. Each match becomes a ticket with an owner.
That work is useful. It answers an auditor's first question and catches known problems at scale, and a CFO reading the program description would reasonably conclude the exposure is managed.
The design assumes someone already decided which components belonged in the build. The program's job is to describe the result.
Where the dashboard hits its ceiling
That assumption held while a person chose each dependency. It fails when coding assistants suggest imports inline and agents install whatever a task needs, because one accepted suggestion brings an entire dependency tree nobody chose. The same research measured the pace: 94% say AI has increased open source consumption, and 96% say it has increased dependency growth. Half say new dependencies can reach production without prior review or approval.[1] The mechanism is laid out in why your open source policy assumes a human picked the package.
The limit is in the design, so better tooling doesn't move it. A more complete inventory or a faster scan reports the same arrivals in more detail or sooner, and the decision still happens after the package is in.
In the same research, 63% of respondents say they address open source vulnerabilities only after scanners or security tools identify them, and 64% say most governance activity occurs after alerts or newly disclosed vulnerabilities.[1] A program built around the record produces exactly that.
Some risks the record cannot express at all. In October, the security firm Bloom described how npm's trusted publishing could, before a package's first trusted publish, recognize a source repository by its owner and name rather than its permanent ID. If that name was freed by a rename or deletion, someone else could claim it, and a release from the new repository could keep the package's familiar name. Bloom demonstrated the path in a controlled test.[2] GitHub had already changed npm on October 2, 2026 so that unvalidated trusted publishing configurations expire 48 hours after creation.[3] An inventory would have listed the same package name before and after the source changed. What mattered was whether anyone had approved the new source.
The fair objection is that you cannot govern what you cannot see. The report agrees: "Visibility matters. An organization cannot govern what it cannot see."[1] Every program needs the inventory, and it comes first. The decision about what may enter has to come before the arrival as well. Why a scanner on its own no longer settles the question is covered in "We Had a Scanner" Is Not a Defense Anymore.
What governing at the right layer requires
Governing intake means moving the decision to the place every request passes through: the source developers and agents pull from.
The organization decides in advance which open source components and versions are eligible, and every request from a developer or an agent resolves against that decision. An agent gets the same answer a senior engineer would have given. The inventory and the scanner keep running as the backstop, now showing that the decision held.
That changes what a CISO can report upward: the risks the program declined to take before anything shipped, alongside the findings it caught after. In the same research, 83% say reducing breach risk is the strongest argument for leadership.[1]
This is the layer ActiveState works at. The ActiveState Curated Catalog is a private, vetted repository of open source components, and the dependencies AI coding assistants request resolve from it, so the decision is made once, at the source, and inherited by every developer and agent. The model is described from the security leader's side in AI Coding Tools Pick Your Dependencies. Put Control at the Source.
Within the next audit cycle, programs that decide at intake will show fewer findings than programs that only improve their inventory.
The question to bring to your next governance review
Pick the last ten open source dependencies that reached production. For each one, ask where the decision to accept it was made, and by whom. Where the answer is a rule set that existed before the request, the program governs that dependency. Where the answer is a pause, that is the place to start.
An inventory records what got in. Governance decides what gets in.
Programs that move the decision to intake shrink the remediation bill. Programs that stay at the dashboard report it in more detail.
Eric Gallagher is Principal Strategist, Open Source Governance, at ActiveState.
Footnotes
ActiveState, research by Moving Horizon, "The AI Remediation Bill: Why the software supply chain needs a new control model," September 2026, published October 20, 2026 (307 survey respondents and 10 interviews, July and August 2026). https://go.activestate.com/ai-remediation-bill. Figures: 94% and 96% (p3, p12); "half" (p3, p15); 63% and 64% (p15); 55% and 45%, and the quoted line (p14); 83% (Approved Claims entry). Self-reported.
What is the difference between visibility and control in open source governance?
Visibility records which open source components are present and flags known problems after they arrive. Control decides which components may enter before anyone requests them. In The AI Remediation Bill, 55% of 307 enterprise leaders named control as the bigger challenge.
Is an SBOM enough to govern open source dependencies?
An SBOM is the record auditors ask for first, and every program needs one. It describes what a build contains after the dependencies were chosen. Governance also needs a decision, made in advance, about which components are eligible to enter.
Why do AI coding assistants make visibility-led governance harder?
Assistants suggest imports inline and agents install what a task needs, so dependencies enter faster than review can follow. One accepted suggestion brings a full tree of transitive dependencies. In The AI Remediation Bill, half of respondents say new dependencies can reach production without prior review or approval.
Do scanners still matter if governance moves to intake?
Scanners stay as the backstop. When the eligible set is decided at the source, scanners have less to find and a cleaner signal, and their findings become evidence that the decision held.
How can a CISO tell whether the program governs or describes?
Ask where the decision to accept each recent production dependency was made and who made it. A program that can point to a rule set before the request governs intake. A program that points to the inventory describes what already arrived.
