GoKawiilBy Jonny Rivera, Head of Product at ActiveState
During our conversations on the show floor at Black Hat last week, one question came up in almost every discussion our team had with AppSec leads, platform engineers, and CISOs: Who is actually vetting AI’s code?
Developer adoption of AI coding tools isn't slowing down. The productivity gains are real, and open source software remains the backbone of modern enterprise applications. But as AI coding assistants auto-complete third-party dependency suggestions in milliseconds, enterprise security teams and open source maintainers face a shared operational challenge: code generation has completely outpaced legacy ingestion review.
When an unvetted or hallucinated dependency enters a codebase at machine speed, post-commit Software Composition Analysis (SCA) scans struggle to keep pace.
Securing this pipeline doesn't mean 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 highlighted in a USENIX Security study analyzing sixteen popular code-generation models across 500,000+ code samples:
A measurable percentage of AI-suggested package names do not exist in public registries.
... continue reading