Slopsquatting Prevention: Block Phantom Packages

One in five packages your AI coding assistant recommends might not exist — and attackers are already registering the names.

That’s not a hypothetical. Research presented at USENIX Security 2025 found that roughly 20% of 576,000 AI-generated code samples contained hallucinated package names — packages that don’t exist in any registry. The twist: 58% of those hallucinations are repeatable, showing up consistently across multiple prompt runs with the same input. That predictability turns an AI quirk into an attack vector.

Slopsquatting prevention isn’t something your existing SCA tools handle. Dependabot and Snyk scan for CVEs in known packages. Phantom packages have no CVE record. They’re invisible to traditional security tooling — until something breaks, or until malicious code runs silently in your production environment.

This guide walks you through a concrete, four-step defense workflow you can wire into your CI/CD pipeline today.

What Slopsquatting Is — and Why Your Current Security Tools Won’t Catch It

Typosquatting exploits human error — someone types `reqeusts` instead of `requests` and installs a malicious package. Slopsquatting exploits something different: the tendency of large language models to hallucinate package names that sound plausible but don’t exist in any registry.

When you ask an LLM to scaffold a data pipeline, it might confidently suggest `pandas-streaming-utils` or `fastapi-auth-middleware` — packages that follow real naming conventions but simply aren’t published anywhere. An attacker who monitors which names LLMs commonly hallucinate can pre-register those names with a malicious payload. You install the “missing” package without a second thought.

The reason your current tools miss this is structural. Dependabot, WhiteSource, and Veracode work by matching installed packages against databases of known vulnerabilities. A freshly registered, empty-README package has zero CVE entries. As proof of concept, researchers uploaded a phantom package called `huggingface-cli` — no code, no README — and it was downloaded over 30,000 times in three months.

Traditional SCA tools give you a false sense of security here. They’re looking for known bad actors; slopsquatted packages are unknown newcomers.

The attack surface is larger than most teams realize. More than 97% of developers have used AI coding tools at least once (GitHub Developer Survey, 2025), meaning nearly every development team is generating code from sources that occasionally invent their dependencies.

How Predictable Are AI Hallucinations? (The Repeatability Problem)

The repeatability finding from USENIX Security 2025 is what elevates slopsquatting from theoretical nuisance to credible threat. Researchers found that 43% of hallucinated package names appeared consistently across all ten attempts with the same prompt. If you and a colleague both ask the same AI assistant to build the same feature, there’s a good chance you’ll receive identical phantom package recommendations.

That consistency is exactly what attackers need. They can:

1. Probe popular LLMs with common development prompts
2. Collect the package names that hallucinate repeatedly
3. Register those names on PyPI or npm with a malicious payload
4. Wait for developers to run `pip install` or `npm install` without question

The hallucination rate varies significantly by model. Open-source models — CodeLlama, DeepSeek, WizardCoder, and Mistral — hallucinated at 21.7%. Commercial GPT-4 fared better but still hallucinated roughly 5% of package recommendations. Across all 576,000 samples, researchers catalogued 205,474 unique hallucinated package names: 51% pure fabrications, 38% echoing real naming patterns, and 13% typo variants.

There’s one more wrinkle worth flagging: cross-ecosystem confusion. Roughly 8.7% of hallucinated Python package names were actually valid npm packages. LLMs don’t cleanly separate ecosystems, which means a Python-focused developer might unknowingly attempt to install a JavaScript package — or an attacker might register that JavaScript name on PyPI with a payload ready.

Step 1 — Lock Your Dependencies Before You Install Anything

The cheapest and most effective first line of slopsquatting prevention costs you nothing but a few minutes of configuration: use tools that refuse to install anything not already pinned in a lockfile.

npm ci vs. npm install

Most developers default to `npm install` in CI. Don’t. `npm install` will happily fetch packages not in `package-lock.json` and update the lockfile in place — the worst possible behavior in an automated pipeline.

`npm ci` does the opposite:

• Installs only what’s in `package-lock.json`
• Fails if `package.json` and `package-lock.json` are out of sync
• Deletes `node_modules` before installing, preventing state accumulation

“`yaml

# In your GitHub Actions workflow

• name: Install dependencies

run: npm ci

“`

One command swap eliminates an entire class of drift-based installs.

pip –require-hashes

For Python, the equivalent is pip’s hash-checking mode. Generate a requirements file with hashes:

“`bash

pip-compile –generate-hashes requirements.in > requirements.txt

“`

Then enforce integrity at install time:

“`bash

pip install –require-hashes -r requirements.txt

“`

If any package’s downloaded content doesn’t match the pinned hash, the install fails. This protects against both phantom packages and compromised legitimate packages.

Lockfile hygiene checklist

• Commit your lockfile (`package-lock.json`, `poetry.lock`, `Pipfile.lock`) — never `.gitignore` it
• Review lockfile diffs in code review — unexplained new entries warrant scrutiny
• Understand that `npm audit` and `pip-audit` catch known CVEs, not phantoms

Step 2 — Registry Verification Scripts: Query PyPI and npm Before Install

Lockfiles prevent drift, but they don’t help when an AI generates code with a brand-new package you’ve never installed. For that, you need to verify package existence before installation. Both PyPI and npm expose lightweight, unauthenticated JSON APIs you can query in seconds.

PyPI verification

“`python

import requests

import sys

def verify_pypi_package(package_name: str) -> bool:

url = f”https://pypi.org/pypi/{package_name}/json”

response = requests.get(url, timeout=5)

return response.status_code == 200

packages = sys.argv[1:]

phantom = [p for p in packages if not verify_pypi_package(p)]

if phantom:

print(f”ERROR: These packages don’t exist on PyPI: {phantom}”)

sys.exit(1)

print(“All packages verified on PyPI.”)

“`

npm registry verification

“`bash

#!/bin/bash

# verify-npm-packages.sh

for pkg in “$@”; do

status=$(curl -s -o /dev/null -w “%{http_code}” \

“https://registry.npmjs.org/$pkg”)

if [ “$status” != “200” ]; then

echo “ERROR: ‘$pkg’ not found in npm registry (HTTP $status)”

exit 1

fi

done

echo “All npm packages verified.”

“`

Run these scripts as a pre-install step or pre-commit hook. They add under two seconds per package and require no paid tooling.

A few things these checks catch that lockfiles don’t:

• Packages in AI-generated `requirements.txt` files that haven’t been installed yet
• Packages mentioned in LLM-written README setup instructions
• Dependencies added by a teammate following AI-generated docs

Step 3 — Purpose-Built Detection Tools (pipask, SlopGuard, Socket, and Snyk Compared)

Several tools now specifically target AI-generated dependency risks. They serve different purposes — choosing the right one matters.

pipask

Best for: Python developers who want a lightweight pre-execution check on developer machines.

pipask wraps `pip install` and queries PyPI before allowing installation, prompting you to confirm unknown packages. It’s a friction layer, not an automated gate — valuable for individual machines but not CI pipelines.

SlopGuard

Best for: Open-source teams that need automated trust-scoring without vendor lock-in.

SlopGuard assigns a trust score to each package based on registry metadata: age, download count, presence of source code, and naming similarity to known libraries. It achieves 92% precision on typosquat detection and flags newly registered packages (under 30 days old) with near-zero download history — the telltale signature of a pre-registered phantom.

“`bash

pip install slopguard

slopguard check requirements.txt

“`

Socket

Best for: Teams that want behavioral analysis, not just metadata scoring.

Socket goes beyond “does this package exist” — it analyzes what a package does: network calls, filesystem access, obfuscated code, and install scripts that execute on `npm install`. It integrates into GitHub as a pull request check, blocking merges that introduce suspicious packages. Socket is particularly valuable for catching malicious packages that have been registered but contain hidden payloads.

Snyk AI Trust Platform

Best for: Enterprise teams already using Snyk for CVE scanning who want a unified workflow.

Snyk’s AI Trust Platform adds an AI-provenance layer on top of its existing dependency graph, flagging packages whose behavior or origin signals hallucination patterns. It’s additive rather than a rip-and-replace.

The right answer for most teams: registry verification scripts (free, fast) as the first gate, plus Socket or SlopGuard as a second-pass behavioral check.

Step 4 — Building the CI Gate: A GitHub Actions Workflow That Blocks Phantom Packages

Here’s a complete GitHub Actions job that combines lockfile enforcement, registry verification, and SlopGuard scanning into a single gate that fails the build on any suspect package.

“`yaml

name: Dependency Security Gate

on: [push, pull_request]

jobs:

dependency-security:

runs-on: ubuntu-latest

steps:

• uses: actions/checkout@v4

• name: Set up Python

uses: actions/setup-python@v5

with:

python-version: “3.12”

• name: Cache pip dependencies

uses: actions/cache@v4

with:

path: ~/.cache/pip

# Cache key includes lockfile hash — invalidates on any dependency change

key: pip-${{ hashFiles(‘**/requirements.txt’) }}

• name: Verify packages exist on PyPI

run: python scripts/verify_pypi_packages.py $(grep -v ‘^#’ requirements.txt | cut -d= -f1)

• name: Run SlopGuard trust check

run: |

pip install slopguard

slopguard check requirements.txt –fail-on-low-trust

• name: Install with hash verification

run: pip install –require-hashes -r requirements.txt

“`

For Node.js pipelines:

“`yaml

• name: Verify npm packages exist

run: bash scripts/verify-npm-packages.sh $(jq -r ‘.dependencies | keys[]’ package.json)

• name: Install with lockfile enforcement

run: npm ci

• name: Socket security scan

uses: SocketDev/socket-security-action@v2

with:

api-key: ${{ secrets.SOCKET_API_KEY }}

“`

The `hashFiles()` cache key on the lockfile means your cache automatically invalidates whenever dependencies change — preventing stale cached packages from bypassing checks.

Behavioral Red Flags: How to Spot a Slopsquatted Package Even After Registry Checks Pass

Even after registry and metadata checks, a few behavioral signals warrant extra scrutiny. Train your team to pause when they see:

• Package age under 30 days with no prior version history
• Zero or near-zero download counts — legitimate packages accumulate downloads organically
• Missing source repository link in PyPI or npm metadata
• Install scripts that execute on `pip install` or `npm install` — check `setup.py` for `subprocess` calls, or `package.json` for `preinstall`/`postinstall` scripts
• Obfuscated code — base64-decoded strings, `eval()` calls, or minified-looking code in source files that should be readable
• Cross-ecosystem name matches — a Python package whose name is actually a valid npm package (check both registries)
• No README, no tests, no CI badges — legitimate libraries almost always carry at least minimal documentation

The 30-day age threshold is particularly reliable. Malicious packages registered to capture AI hallucinations typically appear, collect installs, and either disappear or push a malicious update within the first few weeks.

The tj-actions/changed-files incident is a useful parallel here. That March 2025 supply chain attack originated in a transitive GitHub Actions dependency and ultimately compromised over 23,000 repositories. GitHub Actions workflows lack native lockfile support, making transitive action dependencies an invisible blind spot — one that maps directly onto the slopsquatting threat model.

Reducing Hallucinations at the Source — Configuring AI Coding Tools to Generate Fewer Phantom Dependencies

Detection is the safety net. Reducing hallucinations in the first place is the prevention layer.

Lower your AI temperature settings. Higher temperature increases creativity — and hallucination frequency. For code generation tasks where accuracy matters more than novelty, drop temperature to 0 or 0.1 in your AI tool settings or API calls. Most AI coding assistants expose this parameter, and it’s the lowest-friction mitigation available.

Use AI self-verification as a pipeline step. USENIX Security 2025 found that GPT-4 Turbo and DeepSeek achieved over 75% accuracy when asked to review their own output and flag hallucinated package names. A simple two-pass prompt — generate code, then ask the same model “which of these packages are you uncertain actually exist?” — catches a meaningful fraction of phantoms before they ever reach your terminal.

Prefer retrieval-augmented generation (RAG) for internal tooling. RAG systems ground LLM responses in verified documentation, reducing hallucinated package names by up to 85% in research settings. Fine-tuning on curated package lists also helps, but the USENIX research found it degrades overall code quality — a trade-off most teams won’t accept.

Slopsquatting Prevention Starts With Your Next Pull Request

The threat is real, the tools exist, and the implementation is within reach of any team in an afternoon. Start with the lowest-friction changes: switch to `npm ci`, add `–require-hashes` to your pip install step, and drop a registry verification script into your CI pipeline.

Layer in SlopGuard or Socket for behavioral analysis, wire up the GitHub Actions gate, and you’ve built a slopsquatting prevention defense that catches phantom packages before they ever touch a production environment. Every section of this workflow stacks on the previous one — you don’t need all of it on day one.

Pick one step from this guide and implement it before your next pull request review. That’s all it takes to start closing the gap between AI-generated code and secure, verified dependencies.