When AI Imports Vulnerable Dependencies: Securing AI-Generated Code

AI coding agents write a growing share of production code, and every suggestion can pull in an open source dependency without human oversight. Securing AI-generated code means treating both the generated code and the AI-suggested packages as untrusted input.

Why AI-generated code is a software supply chain problem

Most teams scan the code they write. But the adoption of AI coding agentsmoves the risk to the code AI imported. When an agent suggests a few lines, it often suggests the libraries to support them. Those libraries come with their own transitive dependencies that no one selected or reviewed.

The attack surface is large because the modern application is mostly other people's code. Open source makes up the bulk of a typical codebase, and AI amplifies that exposure by reaching for dependencies developers never chose.

One analysis found AI-generated code pulls in close to 40% more dependencies than human-written code. More dependencies mean more attack surface, and most of it sits in the transitive layer where teams have the least visibility.

How AI coding agents pull in risky dependencies

AI introduces dependency risk in ways traditional AppSec misses. Two patterns account for most of this.

Outdated and vulnerable packages

An AI model learns from training data that lags behind current releases. So an assistant recommends the version it saw most during training, which is often months or years old, and sometimes carries known CVEs. In our research, Endor Labs found that 49% of dependency versions imported by AI coding agents had known vulnerabilities.The vulnerable package frequently arrives as a transitive dependency, buried beneath the one the developer asked for, which means it never crosses the developer's screen for review.

Hallucinated and malicious packages

Models also invent package names that do not exist. Attackers register those plausible-sounding names and load them with malware, an attack called slopsquatting. The same blind spot lets an assistant recommend a package that does exist but is malicious, such as a typosquat or a compromised library. In both cases the developer trusts a confident suggestion and installs code an attacker controls.

Reviewing the dependencies AI introduces

There is a behavioral gap behind the technical one. Developers review the AI-generated logic line by line, then accept the dependencies without the same scrutiny, assuming the model chose secure packages. That assumption is the opening. AI optimizes for code that runs, not for packages that are safe, current, and real.

A real review of an AI-introduced dependency confirms the package exists and is the intended one, checks its provenance (age, download counts, maintainer history), scans both direct and transitive dependencies for vulnerabilities and malware, and verifies the license. No developer can do that by hand across hundreds of transitive packages on every suggestion, which is why the check has to run as automation inside the IDE and the pipeline.

Scanning after the fact is the common failure. By the time a CI gate runs, the build and the lockfile already include the dependency. Moving the check left, into the IDE and pre-commit, catches the risky package at the moment the AI suggests it, before it becomes load-bearing.

How reachability changes the picture

Finding vulnerable dependencies is the easy part. The hard part is the flood. A scan of a real codebase returns thousands of findings, and most of them are not exploitable, because the application never calls the vulnerable function. Teams that chase every CVE burn out, and the real risks hide in the noise.

Function-level reachability analysis fixes the signal. It maps the call graph to determine whether your application actually executes the vulnerable code, which cuts the actionable list by up to 95%. This is the difference between probabilistic detection, which pattern-matches every CVE in the tree, and deterministic, evidence-based security, which answers a concrete question: does this code path run?

For AI-generated dependencies, that question is the whole game. AI inflates the dependency count and the alert volume along with it. Function-level reachability analysis works across your direct and transitive dependencies andtells you which of the packages AI dragged in are reachable and exploitable, so engineers fix what matters instead of triaging what does not.

FAQ

How do you secure AI-generated code dependencies? Treat every AI-suggested package as untrusted input. Verify the package exists and is the intended one, check its provenance, and scan direct and transitive dependencies for known vulnerabilities and malware. Run the checks in the IDE and CI rather than after the fact, and use reachability analysis to prioritize the dependencies that are actually reachable in your application.

Does AI-generated code introduce more dependencies than human-written code? Yes.

AI tends to reach for libraries to support the code it writes, which inflates both direct and transitive dependency counts. One analysis put the increase near 40% over human-written code. More dependencies widen the attack surface, and most of the added risk lands in the transitive layer that teams rarely review.

Why do AI assistants recommend vulnerable packages? A model learns from training data that lags behind current releases, so it recommends older versions, some with known CVEs. It can also hallucinate package names that do not exist or suggest packages that are malicious. The model optimizes for plausible, working code, not for packages that are current, safe, and real. Endor Labs found that 49% of the dependency versions added by AI coding agents had known vulnerabilities due to the cutoff in training dates.

What is reachability analysis, and why does it matter for AI code? Reachability analysis maps your application's call graph to determine whether it actually executes a vulnerable function. If the code path never runs, the vulnerability poses no practical risk. There are different types of reachability analysis, so make sure you ask your vendor how theirs works. With function-level reachability, you can cutactionable alerts by up to 95%, which matters most for AI-generated code because AI inflates dependency counts and the alert volume that comes with them.

Is scanning AI-generated code in CI/CD enough? It helps, but on its own it is late. By the time a CI gate runs, the team has already integrated the dependency. Pair CI scanning with IDE and pre-commit checks to catch risky AI suggestions as they appear, and add reachability so the pipeline surfaces findings worth fixing.

AI is writing than your code—it is also importing your open source dependencies. Endor Labs uses function-level reachability analysis to cut dependency noise by 95% and surface the AI-introduced risk that actually reaches production, or book a demo.