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

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.

1. Scope + registry map for every internal namespace.
2. Exact pins; no caret/range on private packages.
3. Assert resolved URL host in CI against an allowlist.
4. Treat lockfile resolved fields as security-relevant artifacts.
5. Internal package exists only on a private registry
6. Build config also searches the public registry
7. Attacker publishes the same name with a higher version
8. 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):

• Master supply chain security with real attack scenarios
• Start Here
• Dependency Confusion Supply Chain Attack

---

If you face any issues - Github Issues - RAJANAGORI