# Your AI Coding Assistant Is a Dependency Cannon. Nobody's Watching Where It's Aimed.
Every time a developer accepts a code suggestion from Copilot, Cursor, or any of the two dozen AI coding tools now embedded in enterprise workflows, there's a quiet transaction happening in the background: a package name gets typed into a manifest, a dependency gets pulled from a registry, and the software supply chain gets one link heavier. Multiply that by tens of thousands of developers, across thousands of repositories, running eight hours a day.
Traditional software composition analysis was never designed for this.
## The Scale Math Nobody Wants to Do
Here's the problem stated plainly: AI coding tools make individual developers significantly faster. Research estimates range from 25% to over 50% productivity gains for certain tasks. That sounds like an unqualified win — until you apply it to dependency management.
A developer writing code at human pace pulls in maybe a handful of new packages per sprint. A developer assisted by AI might touch triple that, particularly in greenfield projects where the model is confidently scaffolding entire modules. The security review process — dependency audits, SCA scans, license checks, vulnerability triage — didn't scale with that multiplier. Most organizations are still running the same gates they built three years ago, before the AI coding wave hit.
The result is a widening gap between how fast packages enter the pipeline and how rigorously they get scrutinized.
## Hallucinated Packages Are a Real Attack Surface
The problem isn't just speed. There's a genuinely new threat vector that emerged from AI code generation: package hallucination.
Large language models, when asked to write code that uses a specific library or accomplish a niche task, sometimes invent plausible-sounding package names that don't exist. The model has pattern-matched on thousands of package naming conventions and generates something confident and wrong. Researchers and security firms have documented this across npm, PyPI, and other ecosystems.
What makes this dangerous isn't the hallucination itself — a failed pip install is a minor inconvenience. What makes it dangerous is that attackers have figured out that AI models are consistent. The same model, prompted similarly, hallucinates the same fake package names with surprising regularity. So attackers pre-register those names on public registries with malicious payloads and wait.
This is slopsquatting — a portmanteau of "slop" (low-quality AI output) and typosquatting. It's real, it's documented, and most organizations have no specific control against it because it wasn't in the threat model before LLM coding tools existed.
## The Point-of-Selection Argument
ActiveState's framing — govern packages at the point of selection, before they enter the development pipeline — is worth unpacking because it cuts against where most enterprise security investment has landed.
The dominant paradigm is reactive: scan what you have, get alerts when CVEs drop, patch downstream. Tools like Dependabot, Snyk, and OWASP Dependency-Check operate after the fact. A package is already in your tree when they flag it. That worked tolerably when humans were the rate-limiting factor in code production. It works considerably less well when an AI assistant is generating import statements faster than anyone's reviewing them.
The shift-left counterproposal is to move governance upstream. Define what packages are approved for use, maintain a curated internal registry, and block unapproved dependencies from entering the manifest in the first place. It's the supply chain equivalent of pre-authorization in healthcare purchasing — you don't audit every prescription after it's filled, you build a formulary.
The practical challenge is that developer experience degrades sharply if the approved package list is too narrow. Teams have real needs, ecosystems move fast, and a deny-by-default posture that blocks legitimate work breeds shadow IT behavior. Getting the balance right requires actual cross-functional investment between security and engineering — not just deploying another scanner.
## What the XZ Utils Incident Should Have Taught Us
In early 2024, a backdoor was discovered in XZ Utils — a compression library present in most Linux distributions. The attacker had spent two years building trust as a contributor before slipping in the malicious code. The sophistication was remarkable, but the underlying vulnerability was mundane: an open source project maintained by one person, effectively unsupervised, incorporated broadly without scrutiny.
AI-assisted development doesn't change the XZ Utils attack model directly, but it does something worse in aggregate: it normalizes inattention to what you're importing. When your coding assistant confidently writes import some-package and the CI pipeline doesn't immediately catch fire, the muscle memory for questioning that import atrophies.
The dependency hygiene habits that catch XZ-style attacks — reading changelogs, verifying maintainer continuity, scrutinizing new contributors — require cognitive investment that gets squeezed when developers are context-switching rapidly between AI-generated suggestions.
## Concrete Steps for Defenders
For security teams operating in environments with heavy AI coding tool adoption:
---
## HackWire Analysis
The conversation around AI and software supply chain risk has been oddly quiet given the stakes, and that quietness is itself a risk signal.
Part of what's happening is that the AI coding tool vendors have a strong incentive to emphasize productivity gains and downplay the security surface they're creating. The security vendor community has been slower to adapt their product messaging than the threat landscape warrants — SCA tools that haven't updated their models to account for hallucination-sourced packages are selling yesterday's defense against tomorrow's attack pattern.
What's genuinely underreported is the amplification effect on smaller organizations. Large enterprises have the budget for internal registries, dedicated AppSec teams, and tooling integrations. Small and mid-market development shops — exactly the ones AI coding tools have made most productive, because they're stretching thin headcounts furthest — are the ones running unmitigated exposure. One developer using Cursor to build a SaaS product, pulling in 40 new dependencies a week with no package governance, is a supply chain incident waiting to happen.
The deeper pattern here connects to a tension running through the entire AI adoption cycle: AI tools compress the time between decision and consequence. Code that would have taken a week to write now takes a day, which means mistakes that would have accumulated slowly now accumulate fast. Security organizations that haven't updated their throughput assumptions are going to keep finding this gap, across code generation, AI-assisted configuration, AI-written infrastructure-as-code, and everything else in the pipeline.
The package governance conversation is the right one to be having. It just needs to be louder, and it needs to land in board-level risk discussions, not just in developer tooling procurement.
— HackWire Editorial
---
## Related Coverage