FOSSA Logo

Dependency Confusion

A software supply chain attack where malicious packages with the same name as internal dependencies are published to public repositories, tricking build systems into using the malicious version.

What is Dependency Confusion?

Dependency confusion (also known as namespace confusion) is a type of software supply chain attack that exploits how package managers resolve dependencies with the same name across multiple sources. The attack occurs when an organization uses private, internal packages alongside public dependencies, and an attacker publishes malicious packages to public repositories using the same names as the organization's private packages.

When the build system checks for dependencies, it may prioritize packages from the public repository over internal ones, especially if the attacker's package uses a higher version number. This confusion leads to the automatic installation of the malicious code, potentially compromising the entire application or build environment.

How Dependency Confusion Attacks Work

1. Reconnaissance

The attacker identifies target organizations and discovers internal package names through various means:

  • Code leaked in public repositories
  • Package names in error logs
  • References in documentation
  • Information in job listings
  • Accidentally exposed package manifests

2. Package Creation

The attacker creates malicious packages with identical names to the organization's internal packages but assigns them higher version numbers to exploit package manager behavior.

3. Publication

The attacker publishes these malicious packages to public repositories that the target organization uses, such as:

  • npm for JavaScript
  • PyPI for Python
  • RubyGems for Ruby
  • Maven Central for Java
  • NuGet for .NET

4. Automatic Installation

During the build process, the package manager searches for dependencies and finds both the internal package and the public package with the same name. Many package managers prioritize:

  • Packages with higher version numbers
  • Packages from public repositories over private ones

This results in the build system automatically downloading and installing the malicious package.

5. Exploitation

Once installed, the malicious package can:

  • Exfiltrate sensitive data
  • Access build environment secrets
  • Deploy backdoors
  • Compromise developer machines
  • Poison the resulting application

Real-World Dependency Confusion Incidents

The 2021 Disclosure

In 2021, security researcher Alex Birsan demonstrated the widespread impact of dependency confusion by creating non-malicious proof-of-concept packages that mimicked internal dependencies of over 35 major companies. These packages were automatically installed by their build systems, proving the viability of the attack vector. Affected organizations included:

  • Microsoft
  • Apple
  • Netflix
  • Tesla
  • Uber
  • Shopify
  • PayPal

Ongoing Attacks

Since the initial disclosure, numerous malicious actors have attempted similar attacks:

  • Targeting cryptocurrency projects
  • Attacking financial institutions
  • Deploying sophisticated malware through poisoned packages
  • Using typosquatting in combination with dependency confusion

Package Manager Vulnerability to Dependency Confusion

npm (JavaScript)

Highly vulnerable due to its default behavior of checking the public registry first. The npm client prefers the highest version number and doesn't have built-in protections against this attack.

pip (Python)

Vulnerable when configured with multiple package sources. By default, pip will install the package with the highest matching version from any of its configured sources.

Maven (Java)

Less vulnerable due to its explicit repository order configuration, but still at risk if misconfigured. Maven typically checks repositories in a specified order.

NuGet (.NET)

Improved security in recent versions but vulnerable when misconfigured. NuGet uses a first-match-wins approach by default.

Yarn (JavaScript)

Traditional behavior was similar to npm, but newer versions offer improved security features to prevent this attack.

Prevention Strategies

Package Manager Configuration

npm (JavaScript)

Use scoped packages with a registry configuration:

// .npmrc
@company:registry=https://private-registry.company.com

pip (Python)

Implement --index-url and --extra-index-url with dependency pinning:

--index-url https://private-registry.company.com/simple
--extra-index-url https://pypi.org/simple

Maven (Java)

Configure repository order and use the mirror setting:

<repositories>
  <repository>
    <id>company-internal</id>
    <url>https://artifacts.company.com/maven</url>
  </repository>
</repositories>
<mirrors>
  <mirror>
    <id>company-central-mirror</id>
    <url>https://artifacts.company.com/maven-central-mirror</url>
    <mirrorOf>central</mirrorOf>
  </mirror>
</mirrors>

NuGet (.NET)

Configure package sources with clear priorities:

<packageSources>
  <clear />
  <add key="company-feed" value="https://packages.company.com/nuget" />
  <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>

Organizational Defenses

Namespace Protection

  • Register your organization's package prefix in public repositories
  • Use consistent naming conventions with company-specific prefixes
  • Consider claiming public packages even for internal-only libraries

Private Registry Implementation

  • Set up private registries that proxy and cache approved public dependencies
  • Implement security policies that block unauthorized packages
  • Configure tools to only use approved package sources

Build Pipeline Security

  • Validate package integrity with checksums
  • Implement automated checks for unexpected dependency changes
  • Lock dependencies to specific versions and verify before updating

Code Signing

  • Sign internal packages with organizational certificates
  • Verify signatures before allowing installation
  • Implement policies requiring signature verification

Detection Methods

Monitoring for Unexpected Network Traffic

Watch for unusual connections from build systems to package repositories or suspicious external endpoints during builds.

Dependency Auditing

Regularly review all dependencies and their sources to identify unexpected changes or packages from unintended sources.

Package Manifest Verification

Compare the actual installed packages against the expected lock files to identify discrepancies.

Network Traffic Analysis

Analyze outbound connections from build environments to detect data exfiltration attempts by malicious packages.

Incident Response for Dependency Confusion

If you suspect your organization has been affected by a dependency confusion attack:

  1. Immediate Containment

    • Disconnect affected build systems from the internet
    • Freeze all deployments and releases
    • Take snapshots of affected systems for forensic analysis
  2. Investigation

    • Examine build logs to identify suspicious package installations
    • Analyze network traffic logs for unexpected connections
    • Inspect installed packages for malicious code
  3. Remediation

    • Remove compromised packages from systems
    • Rebuild affected applications with verified dependencies
    • Scan for persistent backdoors or compromises
  4. Prevention

    • Implement protective measures described above
    • Train developers on the risks and prevention techniques
    • Establish monitoring for future attempts