The dependency gate moves upstream: why post-commit SCA misses hallucinated packages

A post published on BleepingComputer by Jonny Rivera, head of product at ActiveState, argues that governing third-party code now has to happen at the point of selection, before an import triggers a build, rather than in post-commit Software Composition Analysis ^[1][2]. The claim is vendor-shaped, but the mechanics behind it hold up, and they describe a failure mode that scanning cannot reach by design.

Start with how the suggestion is produced. According to the piece, large language models recommend libraries from statistical probability and historical code patterns, not real-time verification against a package registry ^[3]. When a model proposes a name that does not exist in PyPI or npm, the result is slopsquatting: an attacker registers the dummy name, uploads a payload, and waits for a developer environment or CI/CD builder to fetch it ^[4][5].

That is the part SCA structurally cannot cover. Post-commit scanning inspects packages that resolve; a hallucinated name resolves for the first time only after somebody has registered it, which means the first successful fetch is already the malicious one ^[6].

The scale evidence is thinner than the argument needs. The post cites a USENIX Security study across sixteen code-generation models and more than 500,000 code samples, reporting that a measurable percentage of suggested package names do not exist in public registries, and that nearly half of the suggestions that do resolve carry known CVEs or outdated releases ^[7]. "A measurable percentage" is not a number, and a piece making a scale argument should supply one.

The incident offered as field evidence is dated but unnamed. The post says that early in 2026, security researchers tracked the hallucinated npm name react-codeshift originating from 47 AI-generated agent skills in a single commit, and that it spread through forks to more than 230 repositories before an engineer noticed no human had ever selected it ^[8]. That is roughly five downstream repositories per skill in the originating commit, propagated with no ingestion control anywhere in the chain ^[9][10]. No researcher or firm is credited for the tracking.

The maintainer side is where the friction lands. Kubernetes, the Linux kernel, LLVM and Godot have published diverging policies on AI-assisted contributions, some banning generated code outright and others permitting it only where a human contributor accepts accountability for every line ^[11]. A CodeRabbit review of 470 open-source pull requests found AI-co-authored contributions carried 70 percent more defects than human-authored code while reading clean on the surface ^[12], which is about 1.7 times the defect load for review queues staffed by volunteers ^[13].

Note the author's position: ActiveState sells a repository of clean, built-from-source components with provenance and build-level attestation, pitched as eliminating slopsquatting at the intake step ^[14]. The diagnosis and the product are the same shape.

What to watch: whether the USENIX hallucination rate gets stated as a figure rather than an adjective, whether the react-codeshift account is corroborated by named researchers, and whether agent-skill distribution channels add existence and provenance checks at resolve time. The post also cites telemetry from Kusari's Application Security in Practice report, but the available excerpt ends before the numbers appear ^[15].