What is Dependency confusion?

Dependency confusion is a software supply chain attack where an application accidentally downloads a malicious public package instead of the trusted private package it was meant to use.

The attack works because many build tools and package managers resolve dependencies by name, version, source priority, or registry configuration. If an internal package name also exists in a public registry, an attacker may publish a package with the same name and a higher version number. During installation or build, the system may choose the attacker-controlled package.

How Dependency Confusion Works

A typical dependency confusion attack starts with package name discovery. Attackers may find internal dependency names in leaked configuration files, public repositories, error logs, documentation, package-lock files, or exposed build metadata.

Once they identify a likely private package name, they publish a package with that name to a public registry such as npm, PyPI, or RubyGems. If the victim’s build pipeline is misconfigured, it may trust the public registry when resolving the dependency.

Why Dependency Confusion Is Dangerous

Dependency confusion is dangerous because it targets trusted development workflows. The malicious code may execute in CI/CD systems, developer machines, or build servers where access tokens, signing keys, environment variables, and source code are available.

It also bypasses the intuition many teams have about “not installing unknown software.” The package name can look legitimate because it matches an internal dependency. The failure is usually in registry trust, naming control, or package resolution behavior.

How to Prevent Dependency Confusion

Organizations can reduce dependency confusion risk by making dependency sources explicit and controlled. Private packages should resolve only from approved private registries, and public packages should come from verified public sources.

Useful controls include:

• Reserve internal package names in public registries where possible.
• Use scoped package names and strict namespace controls.
• Pin package versions and verify lock files in builds.
• Disable automatic execution of install scripts where practical.
• Monitor new packages that match internal naming patterns.
• Keep CI/CD secrets tightly scoped and rotate them after suspicious builds.

Endpoint and device management also matters. Tools such as Hexnode can help enforce baseline security controls on developer endpoints, restrict risky configurations, and support compliance across distributed teams.

Dependency Confusion vs Typosquatting

Dependency confusion relies on the package manager choosing the wrong source for a legitimate-looking internal dependency. Typosquatting relies on a developer mistyping or selecting a lookalike public package name. Both are supply chain risks, but dependency confusion is primarily a registry-resolution problem.