In typosquatting, a person mistypes a name. In dependency confusion, a build tool picks the wrong source for a name. In namespace squatting, an attacker claims a scope or prefix. In slopsquatting, an AI assistant invents a name that an attacker then registers. Each tricks a different party, so each needs a different defense.
The comparison
| Attack | Who is tricked | What the attacker registers | Main defense |
|---|---|---|---|
| Typosquatting | A developer typing or copying a name | A near miss of a popular name | Check names, review additions |
| Dependency confusion | The package manager | A public package named like a private one | One controlled source, scope mapping |
| Namespace squatting | Developers and tools trusting a prefix | A scope or prefix implying an owner | Claim your namespaces |
| Slopsquatting | A developer trusting AI output | A name an AI model made up | Verify every suggested package exists |
Typosquatting
Think of a name one letter off from a well known library. The attacker waits for installs. PyPI's report page lists typo-squatting among valid reasons to report a project as malware. Read more in our typosquatting anatomy post.
Dependency confusion
Here the name is exact but the source is wrong. pip's documentation warns that using an extra index for private packages is unsafe because of dependency confusion, and NuGet's source mapping page describes the non determinism that arises when a package exists on several sources. See dependency confusion explained.
Namespace squatting
The attacker takes a scope, prefix or group name that suggests a trusted owner. Registries answer with scope ownership, reserved prefixes and verified group IDs. See what is namespace squatting.
Slopsquatting
AI models can suggest packages that do not exist. If an attacker registers that name, anyone who trusts the suggestion installs it. See how slopsquatting works.
One checklist that covers all four
- Confirm every new package exists, is the one you meant, and is maintained.
- Send private names to private sources only.
- Claim your own scopes and prefixes.
- Keep an inventory so you can find a bad package fast.
- Add a review step for dependency changes in pull requests.
Click through it at your own pace, or open it full screen. Look at what a gate can check before a dependency change merges.
Quick check
Which attack is hardest to stop with a version pin?
Typosquatting and slopsquatting, because the wrong package is added on purpose by a person. A pin keeps the wrong package at its pinned version.
Can one control stop dependency confusion everywhere?
No. Each ecosystem has its own mechanism: scope mapping in npm, source mapping in NuGet, a single index for pip, a mirror for Maven.
Safeguard policies and gates can review dependency changes in pull requests, and a free scan shows your current tree.
Sources
Last reviewed: 19 October 2026.
