guides · 2026-10-11
Supply-Chain Attacks in the AI-Coding Era
The software supply chain was already under attack. Then AI coding assistants added a new one: they confidently recommend packages that don't exist — and attackers register those exact names, waiting for your pip install. This is the threat landscape for AI-assisted dependency management, and how to survive it.
Typosquatting: the original sin
Typosquatting is simple: register reqeusts instead of requests, fill it with malware, and wait for a typo. It's been around for a decade and still works, because humans mistype and copy-paste from sketchy tutorials. AI assistants made it worse — they reproduce misspelled package names from their training data with total confidence, turning one person's typo into thousands of installs.
Slopsquatting: the AI-native attack
Slopsquatting (also called AI hallucinationsquatting) is typosquatting's smarter cousin. The AI invents a plausible package name — arctic-auth-utils, datavalidator-pro — that was never real. Attackers monitor AI outputs, scrape hallucinated names, and publish malware under them. The victim isn't making a typo; they're following instructions exactly. The package installs cleanly, the import works, and the payload runs.
This attack is uniquely hard to spot because nothing looks wrong. The name is plausible, the README is professional (often AI-written too), and the malicious version is usually the only version. Traditional advice — "check the download counts" — fails when the attacker was first.
Dependency confusion: the enterprise variant
Dependency confusion targets companies with private registries. Your internal package is called acme-billing; an attacker publishes acme-billing version 99.0.0 to the public registry. If your build tool prefers the public registry — or resolves the higher version — your CI pulls the attacker's code into production. AI assistants amplify this by suggesting internal-sounding names they've stitched together from context.
What a compromised dependency costs
Malicious packages typically do one or more of: steal environment variables and secrets (the fastest path to your cloud accounts), open reverse shells, mine crypto on your CI runners, or trojan downstream builds so your customers get the payload. The blast radius of one bad npm install is your entire infrastructure — which is why dependency verification belongs in every AI-assisted workflow.
Defense in depth: a practical checklist
- Verify before you install: every package name from an AI assistant gets checked against the real registry. Does it exist? Who publishes it? When was it created? A package born yesterday with one maintainer is guilty until proven innocent.
- Pin and lock: commit lockfiles (
package-lock.json,requirements.txtwith hashes,poetry.lock). Review lockfile diffs in PRs — a new dependency should be a conscious decision, not a drive-by. - Scope your registries: configure private registries with proper scoping so internal names can never resolve publicly. This single configuration defeats dependency confusion.
- Scan continuously: run dependency audits in CI (
npm audit,pip-audit, or a dedicated scanner) and re-scan on a schedule — a package that's clean today can be compromised tomorrow via a maintainer account takeover. - Least privilege in CI: build jobs shouldn't have production secrets in the environment. If a malicious package exfiltrates env vars, make sure there's nothing worth stealing.
Where tooling helps
Manual verification doesn't scale when the AI suggests ten dependencies per session. Vibe-Code Audit's SlopSquat Shield verifies every dependency in pasted code live against npm and PyPI — flagging hallucinated packages that don't exist, newborn packages with no history, and known typosquats, and suggesting the real package the AI probably meant. It's the check that turns "the AI said to install it" from a vulnerability into a non-event.
The rule to remember
AI assistants are autocomplete for code, not authorities on the software supply chain. Every package name they produce is a suggestion, not a fact. Verify first, install second — and make the verification automatic, because the day you skip it is the day the hallucinated package is real, and malicious.
Informational explainer, not a security guarantee. Scan your code free before every deploy.