Skip to main content
New aislop v0.13.1 patch — calibrates hidden-fallback detection and fixes regex comment-masker false positives. Read the changelog →
← Blog
Guide · 4 min read

Slopsquatting and Hallucinated Dependencies: A Software Supply-Chain Guide

The dangerous step is not the hallucination alone. It is treating a model's plausible package name as authorization to execute third-party code.

A coding agent recommends a package with a convincing name. The package exists in the registry. The installation succeeds. Nothing in that sequence proves the package is legitimate.

Large language models can generate names that look like real ecosystem conventions but were not present in their source material. If those names recur, an attacker can register them and wait for a developer or automated agent to install one. That is slopsquatting.

A package name from a model is an untrusted suggestion, not a dependency decision.

The research behind the risk

The 2024 paper We Have a Package for You! evaluated 16 code-generating models across 576,000 samples in Python and JavaScript. It reported an average hallucinated-package rate of at least 5.2% for the evaluated commercial models and 21.7% for the evaluated open-source models, including 205,474 unique hallucinated names.

Those numbers describe particular models, prompts, languages, and a 2024 experiment. They should not be presented as the rate for a current assistant or your codebase. The durable finding is that package hallucination was systematic enough to create a supply-chain opportunity.

OWASP now includes slopsquatting guidance in its NPM Security and Secure Coding with AI cheat sheets, recommending independent verification of package existence, history, maintainers, age, activity, and necessity.

The attack chain

  1. A model invents a plausible package. The name resembles a real library or follows familiar ecosystem naming.
  2. The name is repeatable or discoverable. Similar prompts may produce it again, or public examples reveal it.
  3. An attacker registers the name. The package can contain credential theft, install-script execution, dependency confusion, or a delayed payload.
  4. A developer or agent checks only existence. The registry now returns a real package, creating false confirmation.
  5. Installation executes or imports attacker-controlled code. CI tokens, developer credentials, source, build artifacts, or production data become reachable.

This is why “run a registry lookup” is necessary but insufficient. After registration, existence is the attacker's strongest piece of social proof.

Before install: the dependency decision

  • Prove necessity. Can the standard library or an approved dependency solve the task?
  • Use the expected registry. Confirm namespace, spelling, publisher, and whether the ecosystem uses scopes or verified organizations.
  • Trace source provenance. Follow the registry's repository link and confirm package releases correspond to source tags and maintainers.
  • Inspect history. Check creation date, release cadence, ownership changes, downloads, dependents, issues, and contributor activity.
  • Review execution surfaces. Inspect install scripts, native binaries, code generation, network access, and post-install behavior.
  • Check license and advisories. Security and legal acceptance are separate decisions.

Record the decision in the pull request. A reviewer should not have to repeat provenance research from scratch.

Safe metadata checks

Query metadata before installation and compare it with the primary source repository. These commands do not establish trust; they gather evidence.

# npm: inspect metadata without installing npm view PACKAGE name version time maintainers repository scripts license # Python: inspect the package page and release history python -m pip index versions PACKAGE # Go: inspect resolved module metadata go list -m -json MODULE@VERSION # Rust: inspect the crate on crates.io and its linked repository cargo search PACKAGE --limit 5

Then verify through the registry UI, source host, advisory database, and the project's own release artifacts. Do not paste credentials into a command suggested by a model, and do not run an install merely to see what a package contains.

Controls for coding agents

  • Agents may use existing locked dependencies without approval.
  • Agents may propose a new dependency but may not install it automatically.
  • Every proposal includes purpose, alternatives, exact registry, provenance, license, age, and maintenance evidence.
  • Install commands require explicit human approval and run with restricted credentials and network access.
  • CI fails when manifests change without an approved dependency record.
  • Internal package names and scopes are reserved in public registries where risk warrants it.

The most effective control is often simple: remove package installation from the agent's default authority.

Controls in CI and production

  • Use locked, immutable installs and fail on unexpected lockfile changes.
  • Scan dependencies, licenses, secrets, provenance, and known advisories.
  • Maintain approved-package and denied-package policy for high-risk environments.
  • Run builds with least-privilege tokens, isolated filesystems, and restricted egress.
  • Generate and retain a software bill of materials where the operating model requires it.
  • Monitor for maintainer changes, new install scripts, compromised releases, and unusual runtime network behavior.

A newly malicious package may not have a vulnerability identifier. Containment reduces the blast radius when detection lags.

Where aislop fits—and where it does not

aislop can surface vulnerable dependency findings as part of a broader deterministic scan and can enforce generated-code quality rules around the change. It should sit beside your ecosystem's software-composition and provenance tooling.

npx aislop@latest scan --changes

It does not prove that a newly published package is legitimate. No honest quality score can replace maintainer, source, and artifact verification. Use the scan to catch known and repeatable risk; use a dependency approval process to prevent slopsquatting.

The one-line policy

AI tools may suggest dependencies; only verified people and policy may authorize them.

Sources

Frequently asked questions

What is slopsquatting?

Slopsquatting is a software supply-chain attack in which an attacker publishes a package under a plausible name that code-generating AI systems hallucinate. A developer or agent then installs the package because the recommendation appears legitimate.

How do I verify an AI-suggested dependency?

Confirm the package in the expected registry, trace it to a credible source repository, inspect age, maintainers, releases, downloads, license, advisories, install scripts, and transitive changes, and prove that the dependency is actually necessary. Use an allowlist for automated agents.

Can dependency scanners detect slopsquatting?

Traditional scanners can detect known vulnerabilities and suspicious metadata, but a newly registered malicious package may have no advisory. Preventive provenance checks, package allowlists, locked installs, restricted credentials, and human approval for new dependencies are essential.

← All posts