Dependency confusion in one table: internal scope vs public higher version

Raja Nagori — Thu, 13 Aug 2026 15:00:00 +0000

Problem

Your CI asks for an internal package. The public registry answers first with 999.999.999. Installers that maximize version will take it. That is dependency confusion no phishing required.

Print the resolved registry host in CI logs and alert on public hosts for private scopes. Make confusion visible.

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.

Scope + registry map for every internal namespace.
Exact pins; no caret/range on private packages.
Assert resolved URL host in CI against an allowlist.
Treat lockfile resolved fields as security-relevant artifacts.
Internal package exists only on a private registry
Build config also searches the public registry
Attacker publishes the same name with a higher version
Installer prefers public artifact; malicious code runs

Field notes

Print resolved URLs during install in CI. If an “internal” package suddenly resolves to a public host, treat it as an incident even when tests pass. Scoped registry maps belong in the repo, not only on individual laptops.

Residual risk

Misconfigured local .npmrc bypasses org policy. Verify resolution in the same environment that ships artifacts and not only on a secure bastion.

Try it, then talk back

Explore the concept in Supply Chain Attack Simulator (SCAS):

If you face any issues - Github Issues - RAJANAGORI

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

Raja Nagori — Tue, 11 Aug 2026 15:00:00 +0000

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.

Try it - then talk back

Explore the concept in Supply Chain Attack Simulator (SCAS):

If you face any issues - Github Issues - RAJANAGORI

DEV Community: Raja Nagori

Dependency confusion in one table: internal scope vs public higher version

Problem

Solution concept

Field notes

Residual risk

Try it, then talk back

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

Problem

Solution concept

Field notes

Residual risk

Try it - then talk back