Your sprint is planned, the team is heads down, and three days before the release, security work surfaces. The feature shipment is blocked. Your roadmap item moves to your next sprint. And your next sprint is already full.
This recurring issue has become a compounding, industry-wide problem over the past few years as AI drives more and more code development. Dependencies are entering codebases faster than anyone planned for, sprints are getting backlogged, roadmaps are slipping, and organizations are absorbing it as a new reality in the era of agentic AI.
And the disruptions compound. Leadership stops believing roadmaps mean anything. Teams stop feeling like good work leads to shipped work. What started as a security problem becomes an organizational trust problem.
Most engineering leaders attribute this to the nature of security work. Vulnerabilities are unpredictable. Remediation is unplanned by definition. So you build a buffer and you manage it. But that framing isn’t fully accurate in the growing era of agentic AI.
The pause that disappeared
Open source dependency selection used to involve a moment of human judgment. Developers weren’t running rigorous security reviews on every import, but searching for a package, reading the README, and checking the last commit date created friction. Friction filtered things out, packages that looked abandoned got skipped, and libraries that felt off didn’t make it in.
AI coding assistants removed that pause. A suggestion appears inline, looks authoritative, and accepting it takes a single keystroke. The dependency gets added without the evaluation that used to happen naturally. The volume of dependencies entering codebases is increasing exponentially, and the quiet filtering that used to happen during selection no longer does.
Your CI scanner catches what enters the codebase, but it doesn’t change the rate at which things enter, or the volume of remediation tickets that generates downstream. Those are different problems, and only one of them is being addressed by your current tooling.
Where the planning math breaks
Five years ago, the average enterprise application had hundreds of open source dependencies. Today it has thousands. Not because developers got less disciplined, but because the ecosystem grew, frameworks got more modular, and pulling in a package became cheaper than writing the functionality yourself. AI tools accelerated that trend and changed its character: it’s not just that more dependencies are being added, it’s that the decision to add them no longer requires a human to stop and think.
That shift has direct consequences for sprints and roadmap planning, and it’s not the one most engineering organizations are modeling.
Security tickets now arrive with hidden complexity attached. A two-point remediation becomes a ten-point investigation when the upgrade introduces breaking changes, the transitive dependency pulls in three other things, and the library turns out to be load-bearing in ways nobody had mapped. A planned release becomes a negotiation with the security team about what’s acceptable to ship. A sprint that was supposed to deliver three features delivers one and a remediation nobody planned for.
The signal quality on those tickets is declining too. NIST recently acknowledged it can no longer enrich all CVEs at the volume they’re now being submitted. Meaning the tickets landing on your team will carry less prioritization context than they did 2 years ago. Your engineers are doing triage work that doesn’t show up in velocity metrics, and doesn’t move the roadmap.
Why better AI doesn’t fix this
The reasonable assumption is that AI tools will improve and the problem will self-correct. That assumption misunderstands the structure of the problem.
AI coding assistants are code generation tools. They suggest packages based on patterns in training data: what was widely used, what appeared in similar contexts, what solved comparable problems. A more capable model still cannot tell you whether a package maintainer’s account was compromised last month, or whether a transitive dependency introduced a breaking change last week. Those are governance functions, not generation functions, and they are structurally outside what a code generation layer does.
The governance problem doesn’t get solved as models improve. It gets harder. As agentic AI scales, the volume of unvetted dependencies entering your codebase will increase faster than any human security program can process. Your engineering team sits at the end of that pipeline.
The problem is upstream
Security-related print disruption isn’t really a security problem with an engineering cost. It’s a software supply chain problem. The cost just happens to land on your team.
If we take a step back, the source of the variability isn’t in the vulnerabilities themselves. It’s when and how dependencies enter the environment. Move that decision upstream, before the build, before the scanner, before the sprint, and your roadmap suddenly returns to something you can plan with confidence.
What this looks like in practice is a governed catalog of open source components that sits between your developers and the public registry. 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 been built from a verified source, scored for real-world risk, and cleared before they ever reach the pipeline.
Developer workflows don’t change. The intake point does. What currently surfaces as an urgent ticket gets caught before it creates one. Roadmaps hold, and release commitments don’t get renegotiated mid-sprint.
If ungoverned dependencies are causing engineering problems, you’re not managing a security problem. You’re managing a new type of AI-initiated supply chain with no intake control, and the remediation work landing on your team is a compounding tax.
Learn more about ActiveState →
Frequently Asked Questions:
Why do AI coding assistants increase security risk for engineering teams?
AI coding assistants suggest dependencies based on patterns in training data — what was widely used in similar contexts — without evaluating the current security posture of those packages. Before AI tools, developers searched for packages manually, read documentation, and checked maintenance status. That process wasn’t rigorous security review, but it created friction that filtered out obviously risky choices. AI removes that pause entirely. A suggestion appears inline, looks authoritative, and accepting it takes one keystroke. The result is that the volume of open source dependencies entering codebases is increasing faster than any governance process designed for human-speed decisions can keep pace with.
How does AI-generated code affect sprint planning and engineering roadmaps?
When an AI coding assistant adds a dependency that later surfaces a CVE, the remediation work lands in a future sprint unplanned. What appears as a two-point fix often carries hidden complexity: breaking changes from a required upgrade, transitive dependencies that pull in additional issues, or a library that turns out to be load-bearing in ways nobody had mapped. Multiply this across the volume of AI-suggested dependencies entering a modern codebase, and the cumulative effect is a chronic source of unplanned work that makes roadmaps structurally harder to hold. Engineering leaders often attribute this to the unpredictable nature of security work — but the root cause is a governance gap at the intake layer, not the nature of vulnerabilities themselves.
What is "slopsquatting" and why does it matter for engineering teams using AI tools?
Slopsquatting is an attack pattern in which AI coding assistants hallucinate package names that don’t exist — and attackers register those names on public registries with malicious payloads. When a developer accepts the AI’s suggestion and runs an install command, the registry serves the attacker’s version instead of a legitimate package. Traditional software composition analysis tools scan known packages against vulnerability databases — they do not detect hallucinated package names that attackers have since registered. This is an active attack vector in 2026 and one of several reasons why governing dependencies at the intake layer is more effective than scanning after the fact.
Why won't better AI tools solve the open source governance problem?
AI coding assistants are code generation tools. They suggest packages based on patterns in training data. A more capable model still cannot determine whether a package maintainer’s account was compromised last month, whether a transitive dependency introduced a breaking change last week, or whether a recently published version has been flagged as malicious. Those are governance functions, not generation functions, and they are structurally outside what a code generation layer does. As agentic AI scales, the volume of unverified dependencies entering codebases will increase faster than any human security program can process. The governance problem doesn’t get easier as models improve — it gets larger.
What is a curated open source catalog and how does it address AI coding tool risk?
A curated open source catalog is a governed source of pre-vetted open source components that sits between your developers and public registries like npm or PyPI. Every component is built from verified source code, scanned for CVEs and malware across the full dependency tree — including transitive dependencies — and scored for real-world risk before being admitted. When an AI coding assistant suggests a dependency and a developer accepts it, the package they receive comes from the governed catalog rather than the public registry. Developer workflows don’t change. The intake point does. Dependencies that would have surfaced as unplanned remediation tickets in a future sprint are caught before they generate a finding.
The Curated Catalog addresses all 4. Open source components are built from verified sources in SLSA Level 3 infrastructure, so a package published via a stolen token without matching provenance would not be admitted. Every transitive dependency is scanned before admission, meaning plain-crypto-js with its obfuscated postinstall hook would fail malware analysis. Components are delivered as verified binary artifacts without arbitrary postinstall execution in developer environments. And because the protection is pre-admission rather than post-installation, the self-erasing cleanup is irrelevant. The component never reached the developer.
What does the NIST NVD enrichment gap mean for engineering teams?
On April 15, 2026, NIST formally acknowledged it can no longer enrich all CVEs submitted to the National Vulnerability Database. CVE submissions increased 263% between 2020 and 2025, and NIST does not expect that trend to reverse. CVEs outside NIST’s priority criteria now surface with no severity score, no impact assessment, and no product mapping. For engineering teams, this means remediation tickets arriving from scanner triage will carry less prioritization signal than they did two years ago — engineers absorb more manual triage work that doesn’t show up in velocity metrics and doesn’t move the roadmap. NIST has described this as a permanent structural limitation, not a temporary backlog issue.
