Typosquatting is not “user error” - it is a package resolution problem

#security #programming #opensource #npm

Why lookalike package names bypass review, and how to reason about install-time vs require-time risk.

Problem

If your threat model starts at “crypto of the tarball,” you are already late. Most teams lose at name resolution: the wrong package string installs cleanly, exports a familiar API, and executes side effects before any business logic runs.

Add a CI check that fails on unexpected new package names in the lockfile for protected services. Cheap control, high signal.

Solution concept

Ship one control at a time, measure bypasses, then add the next. A single enforced check beats a binder of unenforced best practices.

Practical controls:

Control	Why it helps
Lockfiles + `npm ci`	Stops casual name drift on install
Name allowlists in CI	Fails builds on unexpected package strings
Lifecycle script policy	Limits install-time execution
Boot-time network watch	Catches require-time beacons

Do not equate “tests passed” with “no side effects on require.”

Attacker publishes a lookalike name near a popular package
Developer (or lockfile drift) installs the wrong name
Malicious module runs at install or first require
Payload phones home or in safe labs, posts to localhost only

Field notes

Watch for packages whose README is a thin clone of a popular project, publish times clustered after a viral blog post about that project, and maintainers with no prior history. In CI, prefer failing on unexpected new package names over paging after exfiltration.

Residual risk

Lookalike detection is fuzzy. Attackers iterate names faster than blocklists. Combine identity checks with behavior signals unexpected scripts, unexpected network knowing both have gaps.