AI Supply Chain Risks: Understanding Slopsquatting

Eighty percent of new GitHub developers fire up Copilot in their first week. That number, from a recent OpsMatters breakdown with Cloudsmith's James Matchett, Ralph McTeggart, and Nigel Douglas, captures the shape of the moment: AI coding assistants have crossed from novelty to default faster than the security review process can catch up. The velocity is real and worth celebrating. The review gap is also real and worth closing.

That gap is exactly what slopsquatting was built for.

What slopsquatting actually is

Slopsquatting is a supply chain attack where an adversary pre-registers package names that AI coding models are statistically likely to hallucinate. Not typos. Hallucinations — names that look correct enough that the model is confident, plausible enough that a human reviewer skims past them, and almost certainly did not exist when the assistant was trained.

// What the assistant suggests
import { normalizeUrl } from "hhtp-until-utils"

// What the developer thinks they got:
// a plausible npm package name, plausibly scoped, plausibly typed

// What actually sits at hhtp-until-utils:
// a package the attacker registered last week

The economics are asymmetric. The defender has to get every dependency right, every time. The attacker has to register one package the model happens to suggest and wait. When an AI assistant ships hundreds of suggested imports per session, the expected number of hallucinations that land in a codebase is non-trivial.

Slopsquatting vs typosquatting: not the same game

These get conflated because both involve "wrong package names." They are different attacks against different surfaces.

The distinction that matters operationally: typosquatting is a human-error problem you fix with IDE muscle memory and a linter. Slopsquatting is a probabilistic-AI problem you fix at the registry, not in your head.

The defenses that actually work

The Cloudsmith team lays out three layered controls. None is novel on its own. The combination is what closes the window.

1. Cooldown policies

A cooldown is a simple rule: a package younger than some threshold cannot be installed into a protected environment. Slopsquatting depends on the attacker registering the hallucinated name after the model was trained but before the developer runs the install. A cooldown forces the attacker to squat the name months in advance, which collapses the economics of the attack.

# Cooldown policy shape (registries vary in syntax)
policy:
  minimum_age_days: 30   # tune to your risk tolerance
  enforcement: block
  scope: production

The primitive is universal: "no package under N days old leaves the boundary." The number is yours to set.

2. Malicious package detection

Static checks catch typosquats. They do not catch a clean, fresh package that does exactly what its name promises and one other thing on top. Malicious-package detection is the layer that looks at behavior — postinstall scripts, network calls, entropy of bundled binaries, package metadata that does not match the source repo. This is one place AI is genuinely useful on the defender's side: flagging the package whose postinstall forks to a C2 endpoint is exactly the kind of pattern a model can learn.

3. Registry-level controls

This is the leg the Cloudsmith argument lands hardest on. As agents take on more autonomous tasks, registry policy becomes the only chokepoint with teeth. The agent does not have judgment. The registry does, if you configure it.

If the policy lives only on the developer's laptop, it does not exist for the agent that runs unattended in CI at 3 a.m. The registry is the one place the rule runs the same for every consumer, human or otherwise.

Agentic systems make this worse, not better

This is the part of the breakdown that should hit hardest for anyone shipping with Cursor, Copilot Workspace, or any tool that executes shell commands on the model's behalf. The whole point of an agentic system is to remove the human review moment. "Review used to happen here" was the old control. The agent does not stop to ask. It runs the install, it imports the package, it moves on.

The fix is not "add a human back into the loop" — that defeats the agent. The fix is explicit guardrails, configured once, that the agent cannot talk its way around:

• A private registry as the only allowed source for the agent's installs.
• A cooldown policy applied at the registry, not on the developer's machine.
• An allowlist of vetted packages, or at minimum a denylist of fresh ones.
• A pre-deploy hook that scans the dependency tree before the build proceeds.

If the agent can reach registry.npmjs.org directly, the registry-level control is a suggestion. If the agent can only reach your private registry, it is a wall.

The part that does not change when the model does

Here is where this gets durable. The model will change. Copilot will be replaced. Cursor will be replaced. The agentic loop will be reinvented three more times before the year is out. None of that changes the underlying fact: a component that looks and behaves the same on web, iOS, and Android — one API, one source of truth — collapses the number of novel dependency decisions the AI ever has to make on your behalf. The same Button ships on every platform. It pulls from a curated, pinned package you already audited. There is no hallucinated import for the model to invent, because the import was never a decision the model had to make.

That is the durable layer. When the model hallucinates an import, you want it to land somewhere you have already audited — a curated component package, a pinned version, a registry that has already applied the cooldown and the malicious-package scan. The AI is not the surface you patch. The supply chain underneath the AI is. Build that once, and every model that comes through inherits the controls.

What to do this week

Three moves, in order of cost:

1. Turn on cooldown policies for any production registry you operate. Even a short window cuts the attacker's slack. Even a longer one kills most opportunistic slopsquatting.
2. Run a malicious-package scan against your current dependency tree. You are not looking for known CVEs here. You are looking for postinstall scripts and outbound network calls that should not exist.
3. Audit every agentic path that can reach a public package registry. If the answer is "yes, the agent can pull whatever it wants from anywhere," the registry policy is still a suggestion — not yet a wall.

The 80% adoption number is a good thing. It means more developers are shipping faster than at any point in the history of the craft. It also means the supply chain attack surface is wider than it has ever been. The answer is not to slow the AI down. The answer is to harden the layer underneath it, so the AI can move as fast as it wants and still land somewhere safe.