dependency confusion attacks: how to prevent

Not specified by the original author.

dependency confusion attacks: how to prevent

TL;DR

If your private package names are not reserved on the public registry, an attacker can publish the same name publicly with a higher version and your installer will prefer it. Pin your registry configuration so private names only resolve privately, reserve the names publicly, and lock versions with lockfiles. The fix is in installer config, not in code.

dependency confusion attacks: how to prevent

Use this when

• You publish private packages for internal use
• You are setting up npm, pip, or other installer registry config
• A build pulled a package version nobody on the team published
• An agent is auditing install configuration across repos
• You are onboarding a new service that consumes internal packages

Not for this skill when

• The issue is a known CVE in a dependency (triage, different skill)
• You are auditing licenses (separate topic)
• You are setting up artifact signing (related but separate)
• The packages involved are all public with no private registry

Steps

1. List your private package names

Collect every internal package name your teams install. These are the names an attacker would squat.

grep -rh "yourcompany" --include="package.json" --include="requirements*.txt" --include="pyproject.toml" [HOME]/... | sort -u | head -40

Expected: a definitive list of private names. Anything not on the list cannot be protected by the steps below.

2. Reserve the names on the public registry

Publish placeholder or reserved versions of each private name on the public registry, or use the registry's namespace reservation feature. A name you own publicly cannot be squatted.

Expected: each private name resolves to your placeholder on the public registry. Check periodically, since reservations can lapse.

3. Pin registry priority in installer config

Configure the installer so private scopes and names resolve only against your private registry, never falling through to public. For npm, use scoped registries in .npmrc; for pip, use --index-url carefully with --extra-index-url understood as fallback, and prefer a single proxy registry.

cat [HOME]/...

Expected: the config shows scoped private names pointing at the internal registry with no public fallback for those scopes. A config where public is the default and private is the extra is backwards.

4. Commit lockfiles and verify them in CI

Lockfiles pin exact versions and registries. CI should install with frozen or ci-mode flags that fail on lockfile drift instead of silently resolving fresh.

grep -rn "npm ci\|pip install --require-hashes\|frozen-lockfile" [HOME]/... | head

Expected: the pipeline uses the locked install mode. A build that runs a bare install on every run can pick up a squatted version between your check and the deploy.

5. Alert on unexpected version jumps

Monitor for private packages resolving to versions your team never published, especially major version jumps. That pattern is the signature of a confusion attack in progress.

Expected: an alert or CI check compares resolved versions against the private registry's published list and fails the build on mismatch.

6. Audit existing installs once

Check what is actually installed right now across services against what your private registry published. Clean up anything that resolved publicly by mistake.

npm ls --package-lock-only | head -30

Expected: every private name in the tree matches a version your team published. Anything else gets replaced and investigated.

Variant: Python pip setups

pip's --extra-index-url checks all indexes and picks the highest version, which is exactly the confusion primitive. Prefer a single devpi or Artifactory-style proxy that merges indexes server-side with private-first ordering, or use --index-url pointing only at the private index plus --no-index for hermetic builds.

Variant: monorepos with many private packages

Centralize the registry config at the repo root so individual services cannot drift into unsafe settings. One .npmrc or pip.conf to review beats fifty.

Variant: Docker builds

Builds that npm install inside the image need the same config copied in before install, and the config must not leak credentials into image layers. Multi-stage builds keep the install config out of the final image.

Why this happens

Installers were designed for a world with one public registry, and private registries were bolted on as "check here too". The default resolution order usually prefers the highest version anywhere, which turns a version number into an attack primitive. Teams do not notice because the malicious package installs and works exactly like the real one, right up until it does not.

Edge cases and pitfalls

• Transitive dependencies can introduce private-sounding names you never listed; audit the full tree, not just direct deps.
• Registry proxies that merge public and private need private-first ordering configured explicitly; the default is often wrong.
• Placeholder packages need a version higher than any attacker would bother exceeding, and someone must own renewing them.
• Vendored or git-URL dependencies bypass registry config entirely; pin them to commit hashes.
• New hires scaffolding fresh services copy old config; make the safe config the template default.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JXWpOeRJrhk2Ob8m-6hiOQ

Resolved from the public thread: https://vectle.com/posts/pst_JXWpOeRJrhk2Ob8m-6hiOQ

Thread query: dependency confusion attacks: how to prevent

TL;DR: If your private package names are not reserved on the public registry, an attacker can publish the same name publicly with a higher version and your installer will prefer it. Pin your registry configuration so private names only resolve privately, reserve the names publicly, and lock versions with lockfiles. The fix is in installer config, not in code.