Who Vets AI’s Code? Open Source’s Scale Problem

At Black Hat last week, our team spent hours in conversations with AppSec leads, platform engineers, and CISOs. One question surfaced in nearly every discussion: who is actually vetting AI’s code?

Developer adoption of AI coding tools shows no signs of slowing. The productivity gains are tangible, and open source remains the foundation of modern enterprise software. Yet as AI assistants auto-complete third-party dependency suggestions in milliseconds, security teams and open source maintainers face a shared operational reality: code generation has outpaced legacy ingestion review. When an unvetted or hallucinated dependency enters a codebase at machine speed, post-commit Software Composition Analysis (SCA) scans simply cannot keep up.

Securing this pipeline does not require slowing developers down or restricting open source. It requires governing what enters the environment at the point of selection, before an import ever triggers a build.

The Mechanics of “Slopsquatting” and Machine Ingestion

Large language models (LLMs) recommend software libraries based on statistical probability and historical code patterns, not real-time package registry verification. When a model suggests a package name that does not exist in PyPI or npm, it creates a supply-chain vulnerability known as slopsquatting, or AI package hallucination exploitation.

The scale of this vulnerability vector was documented in a USENIX Security study analyzing sixteen popular code-generation models across more than 500,000 code samples. A measurable percentage of AI-suggested package names do not exist in public registries. Of the suggested dependencies that do resolve to real packages, nearly half contain known CVEs or outdated releases.

Attackers routinely monitor public LLM output patterns and developer repositories to identify these hallucinated package names. Once identified, an adversary registers the dummy name on PyPI or npm, uploads a malicious payload, and waits for automated developer environments or CI/CD builders to fetch it.

This vector is actively being observed in the wild. Early in 2026, security researchers tracked a single hallucinated npm package name (react-codeshift) originating from 47 AI-generated agent skills in a single commit. The hallucination spread organically through forks to over 230 repositories before an engineer noticed that no human had ever explicitly selected it. The issue was not malicious intent by the developer. It was a complete absence of ingestion controls.

The Friction Multiplier on Open Source Review

The intake challenge inside the enterprise directly impacts the broader open source ecosystem. The same AI assistants generating unvetted dependency suggestions inside corporate networks are also generating automated pull requests submitted to community-maintained repositories. This volume of automated contributions puts unprecedented strain on human maintainers.

Major projects, including Kubernetes, the Linux kernel, LLVM, and Godot, have published diverging policies on AI-assisted contributions. Some ban AI-generated code outright. Others permit it only if a human contributor takes full accountability for every line added.

The quality concerns are backed by data. A CodeRabbit review of 470 open-source pull requests found that AI-co-authored contributions carried 70% more defects than human-authored code, despite reading clean on the surface. When hallucinated or vulnerable packages pass through corporate ingestion, they inevitably trickle down into upstream open source PRs, forcing volunteer maintainers to spend hours validating dependencies that no human deliberately evaluated.

Velocity vs. Verification: The Governance Gap

Recent telemetry from Kusari’s Application Security in Practice report illustrates how far tooling deployment has outrun ingestion controls. Organizations using AI coding assistants stand at 85%. Organizations using AI to assist PR-stage code review sit at 38%. Organizations with dedicated AI AppSec controls fall to just 9%.

Traditional AppSec workflows rely on scanning code after it is written or after a pull request is opened. When code is generated at machine speed, late-stage alerts simply create backlog noise that engineers ignore.

Securing the Pipeline at the Point of Selection

Waiting for LLM hallucination rates to drop to zero is not an AppSec strategy. The core issue is velocity, not model accuracy. To secure the development pipeline without sacrificing output, security and platform teams are moving defense left of the IDE.

First, restrict direct registry fetching. Block developer workstations and AI agents from querying unvetted public endpoints directly during code completion. Second, isolate AI-suggested dependencies. Route newly introduced dependencies into an isolated sandbox for automated reachability and vulnerability analysis before allowing them into primary branches. Third, govern the ingestion gateway. Shift from reactive CVE counting to proactive source curation, ensuring that every package an AI model recommends is pre-vetted against malicious typosquats and slopsquatting targets.

This ingestion layer is precisely where ActiveState’s Secure Open Source Library and Curated Catalog operates. Designed to function as an enterprise-grade ingestion gateway, ActiveState delivers pre-vetted, continuously remediated open source packages directly to developer workstations, CI/CD pipelines, and AI agent environments. By sitting between public package registries and developer tools, a curated catalog ensures that hallucinated package risks are intercepted at the selection boundary.

Enterprise teams running on a governed ingestion source eliminate slopsquatting vectors at the intake step, reducing overall CVE exposure by roughly 95% without forcing developers to turn off their AI assistants.

Disabling AI coding tools is neither practical nor competitive. However, treating AI integration purely as a developer productivity metric, without updating software supply chain ingestion rules, leaves production builds vulnerable to automated compromise. Securing the modern development pipeline requires ensuring that every package selected by a developer or an agent is governed by default before it ever hits a build.