Dependency Confusion Attacks: How Package Managers Are Weaponized Against Your Build Pipeline

How the Attack Works

Most large organizations use both public package registries (npm, PyPI, RubyGems, Maven Central) and private package registries for internal packages. Build systems are configured to search both registries when resolving dependencies. The critical flaw: when both a public and private package share the same name, many package managers default to using the higher version number, regardless of which registry it came from. By publishing a package to the public npm registry with the same name as a target organization's internal package — but with a higher version number — an attacker can cause the organization's build pipeline to automatically download and execute attacker-controlled code.

Why It Works at Scale

Dependency confusion attacks require knowing the names of a target's private packages. This information is often exposed in leaked package.json files, npm-shrinkwrap.json files committed to public repositories, error messages in publicly accessible CI/CD logs, or published documentation. In Birsan's original research, he found internal package names for hundreds of companies in public sources within days of beginning his research.

Mitigations

The primary mitigations are: use registry scoping for all internal packages (e.g., @your-company/internal-package for npm, com.yourcompany for Maven) so namespace confusion is impossible; configure your dependency manager to prefer private registry packages over public registry packages for your organization's namespace; use artifact pinning with hash verification so only approved package versions can be used in builds; and use an SBOM to maintain a record of all resolved packages — anomalous packages appearing in your SBOM that should not be there are a detection signal.

The SBOM Detection Layer

A continuously maintained SBOM provides an important detection capability for dependency confusion and similar supply chain attacks. When a malicious package is injected into your build, it will appear in your SBOM. If your SBOM is automatically compared to an approved component allowlist on every build, unexpected packages trigger alerts before malicious code reaches production. This is an underappreciated use of SBOM beyond its compliance applications.