Key takeaways

• AI coding assistants are accelerating open source adoption faster than governance can keep pace.

• Accountability for AI-introduced package dependencies is becoming a board-level concern for CISOs.

• Software provenance and supply chain governance are now essential for audit and regulatory readiness.

• Governing software before it enters production reduces risk and creates clearer accountability.

Ninety eight percent of organizations increased or maintained their use of open source software over the past year.

This should come as no surprise, especially in today’s landscape of AI-suggested packages. In fact, it’s now faster than ever before to discover, suggest, and integrate open source components into modern applications, and 84% of developers already use (or are planning to use) AI tools in their daily workflows.

But while software consumption has accelerated dramatically, governance hasn’t necessarily kept pace, and only 29% of developers actually trust their AI coding outputs to be accurate.

That is creating a growing accountability challenge.  As AI-assisted development becomes the norm, organizations need to move beyond asking about what types of packages have entered production and start assigning responsibility to the teams who are owning these decisions. 

This is critically important. Why? Because as things stand, 60% of enterprise engineering teams report dedicating at least half of their time maintaining and fixing open source vulnerabilities, which means less time on developing net new features and software capabilities.

In this article, we explore why AI-assisted development is exposing long-standing accountability gaps in software supply chains and break down what security leaders can do to establish clearer governance before vulnerabilities become incidents.

At a glance: AI has changed how software decisions get made

Not so long ago, introducing a new open source package into an application was a deliberate and intentional process.

Developers would typically search for a package, compare different options, read documentation, review maintenance activity and decide whether it was appropriate for the project. And although this wasn’t a formal governance process, it did introduce a degree of human scrutiny before software entered production.

AI coding assistants changed that workflow, and today package recommendations appear inline as developers write code. With each package, a set of package dependency components is pulled in that no human has reviewed; quickly and unintentionally expanding a production environment’s open source footprint. 

According to Open Logic’s 2026 State of Open Source Report, only 27.8% of organizations have governance policies to guide open source adoption and risk management, despite open source now underpinning the vast majority of modern software.

Instead of a clearly attributable human decision making, the ownership of these decisions is becoming increasingly difficult to define and AI velocity has distributed the responsibility of open source vulnerabilities across the developer who accepted the suggestion, the AI model that generated it, the public repositories it learned from, and the organization’s existing governance processes.

The question, then, is not just “How did a package get here?” but “Who was actually responsible for allowing it to enter into production?”

Accountability is now a board-level problem

When a team of engineers (and their AI-supported development workflows) find a vulnerability in their production environment, it’s the C-Suite who ultimately pays the price. Sure, engineering teams will lose time locating and remediating a vulnerable package, but security leaders should be more concerned about the broader consequences.

Customers may question whether their data was exposed and lose trust in your organization’s brand, for example. Or, regulators may ask how a vulnerability entered production in the first place. Worst of all, auditors may request evidence of where the affected component came from and what controls governed its introduction. 

And if that isn’t enough, your board will scrutinize the incident and want confidence that the issue has been fully contained. They want answers to questions like:

• Why didn’t existing controls identify the risk sooner?
• Can we prove where this component came from?
• Are other systems exposed to the same issue?
• Can we produce a complete provenance chain for auditors or regulators?

Good governance is becoming more important than remediation alone

The industry is already feeling this kind of pressure. So much so that 38.1% of organizations managing large data environments say data quality and governance is their biggest challenge.

Frameworks such as the Cyber Resilience Act (CRA) and the Secure Software Development Framework (SSDF) are helping leaders provide answers to these questions, and they’re placing greater emphasis on the importance of supply chain visibility.

This is why AI governance has become a business issue rather than a simple engineering concern. And the organizations who are successfully governing AI-assisted development will be the ones who can clearly demonstrate how software enters production, who is accountable for that process and what controls exist to manage the risk before it becomes an incident.

The goal: To ensure governance keeps pace with AI-assisted velocity

It would be irresponsible to ask your engineering teams to stop using AI coding assistants. That ship has sailed and for very good reason. AI is helping engineering teams build software faster than ever before.

That said, it’s vital you find ways to ensure your production environments are kept safe from vulnerable packages introduced by AI. That’s becoming increasingly important as the volume of vulnerabilities continues to rise. 

In 2025 alone, a record 48,185 new CVEs were published, while the average time to remediate high and critical application vulnerabilities stretched to 54.8 days. 

Today’s attackers are weaponizing newly disclosed vulnerabilities within hours and leaving organizations with an ever-shrinking window to respond. So, rather than relying on developers to evaluate every AI-generated recommendation, you should establish governance at the point where software enters the environment. 

That means sourcing components from a curated, approved catalog with built-in provenance, signed attestations, SBOMs and automated policy enforcement before a dependency ever reaches production.

This is the principle behind the ActiveState Curated Catalog.

Instead of pulling packages directly from public repositories, engineering teams (and the AI coding assistants they use) can consume components that have already been built from a verified source, as well as vetted against organizational security policies and accompanied by a documented provenance chain. Your teams can work with the same suite of tools and workflows they already use, but your enterprise gains a clear record of how every approved component entered production.

This creates a different kind of accountability model, and instead of asking “Who accepted this dependency?” you can now ask the more important question: “What governance process approved it?” 

This accountability problem existed long before AI

As AI accelerates open source adoption, it’s also exposing governance gaps that many organizations didn’t realize they had. For CISOs, the challenge is to definitively demonstrate how software entered production, where it came from and what controls governed that process. 

Without this kind of visibility, today’s vulnerabilities quickly become tomorrow’s governance failures. As the 2026 Edgescan Vulnerability Statistics Report found, 37% of vulnerabilities discovered in large enterprises remain unresolved after 12 months.

Good governance, then, is urgently needed, and CISOs must work night and day to create a clear chain of accountability from the very beginning.

To learn more about how Active State can help you build accountability into your AI-assisted development workflows, discover how the ActiveState Curated Catalog governs software before it reaches production.