A USENIX Security study analyzing sixteen popular code-generation models across more than 500,000 code samples found that a measurable percentage of AI-suggested package names do not exist in public registries, and that almost half of suggested dependencies that resolve to real packages contain known CVEs or outdated releases.
USENIX Security study: where suggestion meets supply-chain risk
The study cited on the Black Hat show floor highlights a systemic mismatch: large language models recommend libraries based on statistical likelihood and historical usage, not registry verification. That gap produces two linked failure modes. First, models hallucinate package names that do not exist in PyPI or npm. Second, when suggested names do resolve, many point to packages with known vulnerabilities or outdated releases — a problem the study quantified as “nearly half” of resolving suggestions.
Those failures create a live attack surface. Attackers monitor public LLM output and developer repositories for hallucinated names, register the dummy package on a public registry, upload malicious payloads, and then wait for automated developer environments or CI/CD builders to fetch them. The chain can convert an innocent auto-complete into a compromised build.
Slopsquatting in practice: the react-codeshift episode
The vector is not hypothetical. Early in 2026, researchers tracked a single hallucinated npm package name, react-codeshift, that originated from 47 AI-generated agent skills in a single commit. That hallucination propagated through forks into more than 230 repositories before a human noticed that no one had deliberately chosen the dependency. The driving factor, the reporting notes, was not malicious intent by developers but the absence of ingestion controls to stop machine-speed recommendations from entering builds.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadOpen-source maintainers: overwhelmed by volume and defects
Automated suggestions do not only affect corporate codebases. AI assistants are also generating automated pull requests against community-maintained projects, multiplying the workload for volunteer maintainers. The source material cites diverging policies on AI-assisted contributions from major projects including Kubernetes, the Linux kernel, LLVM, and Godot — some banning AI-generated code outright, others permitting it only with clear human accountability.
A CodeRabbit review of 470 open-source pull requests found AI-co-authored contributions carried 70% more defects than human-authored code, even when the changes looked clean on the surface. When hallucinated or vulnerable packages slip into corporate ingestion, they can trickle upstream into these automated PRs, forcing maintainers to spend hours validating dependencies that were never deliberately chosen.
Defensive prescriptions: govern ingestion at the point of selection
The central argument put forward on the show floor and in the briefing is that late-stage scanning and post-commit SCA are inadequate against machine-speed generation. The recommended defensive posture moves security “left” to the point where a developer or an AI assistant selects a package. Specific measures described include:
- Blocking direct registry fetching from developer workstations and AI agents so recommendations cannot pull from unvetted public endpoints during code completion.
- Routing newly introduced dependencies into an isolated sandbox for automated reachability and vulnerability analysis before they are allowed into primary branches.
- Governing an ingestion gateway to pre-vet packages against typosquats and slopsquatting targets rather than relying on reactive CVE counting.
These are the mechanics ActiveState advertises for its Secure Open Source Library and Curated Catalog, which the company positions as an enterprise-grade ingestion gateway sitting between public registries and developer tools. ActiveState says that enterprise teams running on a governed ingestion source can eliminate slopsquatting vectors at intake and reduce overall CVE exposure by roughly 95% while still allowing developers to use AI assistants.
What this means for technologists, open-source maintainers, and enterprise security teams
- Technologists and platform engineers should consider blocking direct registry queries from AI tools and implementing an isolated sandbox for new dependencies, as a way to preserve developer velocity while intercepting risky packages at selection time.
- Open-source maintainers will continue to face increased volume of AI-generated pull requests and will need to enforce project policies that clarify human accountability and dependency vetting, given the higher defect density reported in CodeRabbit’s review.
- Enterprise security teams and procurement leaders must weigh reactive SCA alerts against proactive ingestion controls; the reporting argues protection is more effective when applied before a dependency ever reaches a build.
Disabling AI coding tools is framed in the source as neither practical nor competitive. The practical alternative offered is governance at intake: ensure every package a developer or an agent selects is pre-vetted before it hits a build. That prescription reframes the problem from model accuracy to pipeline velocity — and points to an engineering control point where slopsquatting can be intercepted rather than chased after.
