Dependency Confusion Attacks

Dependency confusion is a supply chain attack that exploits the package resolution behaviour of build tools and package managers. When a development environment is configured to resolve packages from both public registries (npm, PyPI, Maven Central) and private or internal registries, many package managers will , by default or by misconfiguration , prefer a public package with a higher version number over a private package with the same name at a lower version. An attacker who identifies the name of an internal package , through job postings, GitHub repositories, error messages, or documentation , can publish a malicious package with that name to the public registry at a higher version number. The build system resolves the public version, executes the attacker's code, and the compromise occurs during a routine dependency installation rather than through any vulnerability in the software itself.

The discovery mechanism is the first attack phase. Attackers identify internal package names through multiple channels: job postings that reference internal tooling frameworks, public GitHub repositories where internal package names appear in configuration files, error messages that include package names when internal packages are not found, documentation that references internal tools, and open-source contributions from employees that reveal internal package naming conventions. The package name is not a secret , it exists in build files, configuration documents, and the institutional memory of the development team. Treating it as confidential is not a viable defence.

The resolution priority mechanism is the technical vulnerability. Package managers like npm, pip, and Maven are designed to resolve the highest version of a package matching the specified version range. When both public and private registries are configured, many implementations check public registries and apply version precedence rules that allow a public package with a higher version number to supersede a private package with the same name. This behaviour is configurable , private registry priority can be enforced , but it is not the default configuration in many common setups.

Why this matters

Dependency confusion matters for TPRM because it is a supply chain attack that your vendors may be vulnerable to , particularly software vendors and development tool providers who use internal package registries alongside public dependencies. A vendor whose build environment is susceptible to dependency confusion can have their build pipeline compromised without any traditional vulnerability exploitation, producing software artifacts that contain attacker code but pass standard code review and security scanning.

• Vendor build environment susceptible to dependency confusion not assessed
• Private registry priority configuration not included in vendor security questions
• Internal package name exposure in public sources not assessed
• Dependency resolution configuration not in TPRM assessment scope
• Build-time attack vectors not assessed alongside runtime security

What good looks like

Mature software supply chain programmes assess vendor build environment configuration for dependency confusion vulnerabilities , specifically whether private registry priority is enforced, whether internal package names are reserved on public registries, and whether build environments are configured to reject packages from unexpected sources.

• Private registry priority enforcement , private packages resolved before public
• Internal package name reservation on public registries as defensive measure
• Build environment isolation , restricted network access during builds
• Package integrity verification , hash verification for all resolved packages
• Dependency resolution audit , review of registry resolution configuration

Tooling

Dependency Confusion Detection , Confused, Protect by Socket.dev for dependency confusion testing

Dependency confusion testing tools can identify internal package names that are not registered on public registries , creating potential targets for dependency confusion attacks. For TPRM practitioners, asking whether vendors have tested their internal package names for public registry availability and have reserved them defensively provides a specific dependency confusion mitigation question.

Governance challenges

The governance challenge with dependency confusion is the configuration complexity. Correctly configuring package manager registry priority across all development environments, CI/CD pipelines, and developer workstations requires deliberate policy and enforcement , the default configuration is often insecure. The governance resolution is explicit registry configuration standards applied consistently across all build environments.

• Enforce private registry priority in all package manager configurations
• Reserve internal package names on public registries defensively
• Audit registry configuration across all build environments
• Test for dependency confusion using automated detection tools
• Include dependency resolution in vendor build security assessment

If you are a small team

For your most critical software vendors, ask one question that their standard security questionnaire doesn't address: do you use private package registries alongside public ones, and if so, how do you ensure your build systems resolve from private registries first to prevent dependency confusion? A vendor who uses both public and private registries without explicit private registry priority enforcement is susceptible to the attack. Ask whether they have verified that their internal package names are not registered by third parties on public registries.

• Ask whether vendor uses private and public registries , and resolution priority configuration
• Ask whether internal package names have been reserved on public registries
• Ask about dependency confusion testing in build environment
• Include registry configuration in build security assessment

What to require

Ask directly:

"Do you use private package registries alongside public ones in your build environment , and how do you ensure private packages are resolved with priority to prevent dependency confusion attacks where a public package at a higher version supersedes your internal packages?"

Expect as evidence

• Registry priority configuration documentation
• Internal package name reservation on public registries
• Dependency confusion testing results
• Build environment isolation for external network access

A vendor who confirms secure build practices should be asked specifically about dependency confusion mitigation. Build environment security includes registry configuration , not only code review and static analysis.

How to evidence it

• Registry priority configuration audit
• Internal package name reservation verification
• Dependency confusion testing records
• Build environment configuration standards

Key Takeaway

Internal package name: in a job posting. Public registry: attacker registered same name, higher version. Build system: resolved public package. 23 applications: attacker's code executed during dependency installation. No vulnerability exploited. No code review bypassed. The resolution mechanism did what it was configured to do. Private registry priority enforcement prevents it: the private package is resolved first regardless of version number. Name reservation on public registries prevents it: the attacker cannot register a package with the name the enterprise already holds. Both are configuration decisions, not architectural overhauls.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security