Only 1 in 5 dependency versions that AI coding assistants recommend are safe to use. The other 80% either contain known vulnerabilities or reference packages that do not exist in any registry. That figure comes from Endor Labs' 2025 State of Dependency Management report, which analyzed AI dependency recommendations at scale across PyPI, npm, Maven, and NuGet — and it identifies a specific blind spot that most SCA configurations leave unaddressed.
Software composition analysis (SCA) is designed to catch vulnerable dependencies. It cross-references your dependency tree against published CVE databases and flags packages with known exploits. What it was not built to handle is an AI agent that imports a hallucinated package name, or recommends a version carrying an undisclosed vulnerability with no CVE entry yet. Both failure modes are becoming routine as AI-generated code increases its share of merged commits.
The SCA Assumption That AI-Generated Code Breaks
SCA operates on a known-bad model. It scans packages against databases — NVD, OSV, the GitHub Advisory Database — and raises a flag when a match is found. That assumption holds reliably when developers choose dependencies deliberately, because deliberate picks tend to be real packages with enough history to accumulate a vulnerability record.
AI coding agents work differently. According to Endor Labs, 34% of dependency versions recommended by AI assistants do not exist in package registries at all — they are hallucinations. SCA cannot scan a package that has no registry entry. And for the 49% of AI-recommended versions that do contain known vulnerabilities, SCA catches only the subset already indexed in the databases it queries. New packages introduced with undisclosed flaws pass through undetected.
The compound risk is significant. Veracode's 2025 State of Software Security report found that 70% of critical security debt already originates in third-party code and the software supply chain. Layering AI-assisted development on top of that baseline compounds an existing exposure rather than managing it.
Two Failure Modes SCA Was Not Designed For
Hallucinated packages
When an AI agent imports a non-existent package, the build may still succeed if that import is not exercised in tests. The risk arrives later: a threat actor registers the hallucinated name in the public registry, and the agent's next run silently pulls malicious code. The mechanics of AI package hallucinations and how they become supply chain entry points are covered in detail separately. The key SCA implication is this: no scanner flags a non-existent package as dangerous. The package resolves cleanly to nothing — until someone makes it resolve to something.
Vulnerable versions in the pre-disclosure window
AI agents frequently recommend package versions that were current at training time. Between a vulnerability becoming exploitable in a given version and a CVE being published, SCA shows no alert. Veracode's data shows that even after a CVE is disclosed, organizations take an average of 252 days to remediate third-party library flaws — so the pre-disclosure window stacks on top of a remediation backlog already stretching past eight months.
The behavioral dimension makes it worse. Sonar's 2025 State of Code report found that 96% of developers do not fully trust AI-generated code, yet only 48% say they always verify it before committing. Human review is not reliably compensating for what automated scanning misses.
Your SBOM captures the static inventory of what is in your software. What AI coding agents add to that inventory between snapshots — each new dependency pulled into a PR — is the dynamic exposure that post-merge baseline SCA scans don't address in real time.
What re-entry.ai does about this: re-entry.ai tracks every dependency introduced or modified by AI coding agents at the pull request level, flagging new packages for review before they merge — giving SCA and human review a consistent interception point rather than relying on post-merge trunk scans to catch AI-introduced supply chain risk.
What to Do Now
Run SCA on every AI-modified PR, not just scheduled baseline scans against the full dependency tree. New dependencies added in AI commits need an interception point before merge.
Add a registry resolution check to your pipeline: fail the build if a required package cannot be resolved from an approved registry before the install step runs. This catches hallucinated packages at the build layer.
Treat every new dependency introduced in an AI-generated PR as untrusted third-party input. Apply the same scrutiny you would to any external library pull request — including checking for recent CVE activity against that package in the past 90 days.
Maintain a 90-day lookback on AI-introduced dependencies and cross-reference against CVEs disclosed in that same window to catch the pre-disclosure overlap on packages your agents are already using.
Traditional SCA remains a necessary control. Against AI-generated dependency recommendations, it needs reinforcement at the PR layer — where the new packages actually enter. See how re-entry.ai closes that gap at re-entry.ai.