Slopsquatting Lab: Stop AI-Suggested Fake Packages

It is a name for a supply-chain trick built on package hallucination: a code-generating model suggests a package that does not exist, an attacker registers that name, and anyone who installs what the model suggested gets the attacker's package. OWASP LLM09 describes the same pattern: attackers experiment with coding assistants to find commonly hallucinated package names and publish malicious packages under them. "Slopsquatting" is community shorthand, not a term from a standard.

Spracklen and colleagues generated 576,000 code samples in two programming languages with 16 models and two prompt datasets. Their abstract reports hallucination rates of at least 5.2% for commercial models and 21.7% for open-source models, and 205,474 unique hallucinated package names. Those are the authors' figures from the abstract; we did not read the full paper, and results depend on model, prompt and settings.

The Poisoned Dependency Lab starts after a known, previously legitimate package ships a bad update, and asks how to respond. This lab is about the choice to add a package in the first place: a name that never existed until someone registered it, a near-miss of a real name, or a public name that shadows a private one, with an AI assistant as the source of the suggestion. It ends with a response step for a bad install, but the focus is prevention at the pull request.

No. The attack depends on the name existing, because the attacker registered it. Check who published it, when, its history, whether it links a real source repository and whether it matches what was meant. OWASP LLM09 does not say "check the package exists"; its mitigations are secure coding practices, automatic validation of outputs, cross-verification against trusted sources and human oversight.

npm can publish provenance: attestations that link a package to its source and build and record who published it, signed through Sigstore. The npm documentation says provenance does not prove a package is free of malicious code. PyPI trusted publishing lets CI systems publish with short-lived OpenID Connect tokens instead of long-lived API tokens. Both help a consumer judge origin; neither proves a package is benign. npm's naming guidelines ask that unscoped names not be similar to another package, but the page does not mention typosquatting.

It is when a build that should fetch a private package resolves the same name from a public registry, where someone else owns it. Scoped names mapped to a private registry in the install configuration are one defence (npm documents linking a scope to a registry). Python tools handle indexes differently, so check your installer's documentation.

For installs started by an AI assistant or by CI, disabling them by default is a sound starting point: the npm config page says that with ignore-scripts set to true npm does not run scripts in package.json files, though a command that runs a specific script still runs it. It does not make a package safe, because its code can still run when imported.

They help but do not solve it. The SLSA specification overview says the SLSA level of an artifact is independent of the level of its dependencies and that SLSA does not address organisations that intentionally produce malicious software. NIST SP 800-218 (SSDF 1.1) groups practices into Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities, and its PS.3.2 covers collecting and sharing provenance data for software components.

No. The organisation, assistant and packages are invented, and we use obviously fictional names so none can match a real package. The research and standards cited are real and listed below.

Each of the 12 decisions scores 0 to 10 and the result is your share of the maximum, with a short band saying what it means. The debrief shows the source behind each rationale. Lines labelled PlayCISO practice are our reasoning, not a statement by a source.