It’s 3 days before the release. The sprint is full, the team is heads down, and a CVE surfaces in a dependency nobody remembers pulling in.

Security flags it. Engineering looks at the ticket and sees a two-point fix that will almost certainly turn into a ten-point investigation once someone starts pulling the thread. The release window is already tight. Someone is going to have to make a call about whether to ship or fix, and whoever makes it is going to own the consequences.

What follows is a familiar negotiation. Security holds the line on risk. Engineering holds the line on the roadmap. Both teams are right. Both are doing exactly what their role demands. And somewhere in the middle of the argument, the actual problem gets lost entirely.

Because neither team pulled that dependency in. The AI coding assistant did.

For many security leaders, this feels like an inevitable evolution. The industry is moving past the illusion of 100% prevention. Driven by rigid regulatory mandates like Europe’s DORA and the SEC’s disclosure rules, the corporate board no longer just asks, “Are we secure?” They ask, “How fast can we recover and maintain operational continuity when a disruption happens?”

But a rebrand is just semantic window dressing if your underlying strategy remains purely reactive.

True cyber resilience isn’t built during an incident response drill; it is built by eliminating systemic vulnerability long before an incident can occur. And in modern enterprise software development, that means securing the absolute foundation of your software supply chain: open source software (OSS).

The Argument Nobody Is Winning

Security and engineering have been running versions of this negotiation for as long as software development has had a security function. The CVE changes. The sprint changes. The dynamic doesn’t.

Security sees unvetted open source entering the codebase and flags it as a risk management failure. Engineering sees a last-minute requirement change and flags it as a planning failure. Both interpretations are accurate. Both are incomplete. And the friction between them is so familiar that most organizations have stopped questioning whether the argument itself is the problem.

It is.

The conflict isn’t a culture gap. It isn’t a communication failure. It’s what happens when two teams with different accountability structures and different success metrics are both trying to manage a problem that neither of them created and neither of them has the authority to fully solve. That problem has a name: unmanaged open source software. And in the era of AI-assisted development, it has become significantly harder to contain.

What AI Changed, and What It Didn’t

Open source software has always carried governance risk. Modern applications depend on hundreds of open source components, each with its own transitive dependencies, maintenance history, and vulnerability profile. Managing that dependency graph has never been easy. Security teams built processes around it. Engineering teams built tooling around it. The problem persisted anyway, because the volume was always growing faster than the governance.

AI coding assistants didn’t create that dynamic. They accelerated it past the point where existing workarounds can keep up.

Before AI tools, a developer pulling in a new dependency made a decision, however briefly. They searched for the package, looked at the README, checked the last commit date. That wasn’t rigorous security review. But it created enough friction that the most obviously problematic packages got filtered out naturally.

AI removes that pause entirely. A suggestion appears inline, the developer accepts it with a single keystroke, and a new open source dependency enters the codebase without the moment of human evaluation that used to happen by default. Multiply that across a development organization using AI tools at scale, and the volume of unvetted open source entering production environments is growing at a rate that no human review process was designed to handle.

Nobody chose that dependency deliberately. Nobody reviewed it. Nobody owns it. Security didn’t miss it. Engineering didn’t ignore it. The governance layer that should have caught it before it reached the pipeline simply wasn’t there.

The Common Enemy Both Teams Share

Here’s what changes when you frame it that way: security and engineering stop being adversaries and start being two teams who both got handed the consequences of a gap neither of them caused.

Security’s job is to make sure that what ships doesn’t become a liability. Engineering’s job is to ship reliable software on a predictable schedule. When unvetted open source dependencies are entering the codebase through AI suggestions and surfacing as CVEs in future sprints, neither team can do their job. The sprint disruptions, the release delays, the remediation work that derails planned features: these aren’t the cost of doing business. They’re the cost of an unsolved governance problem landing on whichever team was closest to it.

Both teams are losing the same fight. They’re just losing it from different positions.

We heard this dynamic described repeatedly in conversations with security and technology leaders across regulated industries. One security leader put it plainly: “We cannot tell engineering what tools to use.” Policy authority and resource authority were in different hands, and the gap between them was exactly where unmanaged open source lived. As another leader described it, when a CVE fires, the question of “who ultimately decides and fixes this” stalls remediation every time. Not because either team is failing. Because the accountability structure wasn’t built for the problem they’re actually dealing with.

What a Shared Solution Looks Like

The organizations making the most progress on this aren’t the ones that have negotiated a better relationship between security and engineering. They’re the ones that removed the source of the conflict from the critical path entirely.

The approach that works: governing open source at the point of ingestion, before it reaches the pipeline, before it reaches the sprint, before it reaches the 2 a.m. CVE alert. Making the governed path the default path, so that the dependency the AI suggests and the developer accepts is already vetted before it ever becomes anyone’s problem.

This is what the ActiveState Curated Catalog does. Every component is built from verified source code inside a SLSA Level 3 environment, scored for real-world risk across the full dependency tree including transitive dependencies, and shipped with a signed attestation and complete software bill of materials. When an AI coding assistant suggests a dependency and a developer accepts it, the package that gets resolved comes from the governed catalog, not from the public registry. Governance holds at the point where the decision is being made, not three days before the release when it’s already too late.

For security, that means policy is enforced before packages enter the environment. The allow list becomes the catalog. When a CVE drops, there’s a provenance chain that answers the question in minutes rather than days of archaeology through CI logs.

For engineering, that means the sprint interruptions stop. Developers pull packages the same way they always have. AI coding assistants suggest dependencies the same way they always do. What changes is that the packages being resolved have already cleared a security threshold. No builds blocked at 4 p.m. No refactoring to fix a dependency nobody chose. No last-minute negotiation about whether to ship.

The conflict that’s been running for 30 years doesn’t get resolved through better communication or clearer accountability mandates. It gets resolved because the thing that was causing it stops entering the environment ungoverned.

The Sprint That Doesn’t Get Derailed

Back to that CVE, 3 days before the release.

When governance lives at the pipeline layer, that conversation doesn’t happen. The dependency the AI suggested was resolved from the catalog, already vetted, already with a provenance chain attached. If a new vulnerability is disclosed against it, the remediation SLA is already running and the rebuild is already in progress on a contractual timeline, without anyone having to escalate or negotiate or decide whose sprint it lands in.

Security doesn’t have to flag it. Engineering doesn’t have to fight about it. The release ships.

That’s not a future state. It’s what happens when the governance layer is in the right place.

If you’re navigating the security-versus-engineering friction we described here, the ownership problem that sits underneath it is worth understanding first.

Read: Cybersecurity Has Had 30 Years to Solve the Ownership Problem. Why Hasn’t It?