Dependency Confusion

Programs today are rarely written from scratch. Instead, developers rely on ready-made building blocks that other people have written. Such building blocks are called packages, and they are stored in large public collections on the internet, available for free download. Many companies additionally write their own packages that are kept purely internal and are not public. Dependency Confusion exploits the fact that a program does not always reliably distinguish, when building, which of the two sources is meant. An attacker uploads a foreign building block to the internet under exactly the internal name, hoping that the company will install it instead of its own.

Why one wrong building block can bring down the whole house

The damage does not only occur once the finished program is running. Many package systems allow commands to be executed immediately when a package is installed. This gives the attacker access to the machine on which the software is being built. And that very machine is usually especially valuable: it holds passwords, access keys, and access to the company’s source code.

On top of that comes the reach. A single infected package ends up in every version of the software shipped afterward. Customers thus voluntarily install a program that has already been tampered with. Experts call this a supply chain attack. The trust between manufacturer and customer is turned into a weapon in the process.

The method became known in 2021 through security researcher Alex Birsan. He uploaded packages using the internal names of major corporations, including Apple, Microsoft, and PayPal. His code then reported back from more than 35 companies. Birsan had not destroyed anything, but merely proven that it works. He received more than $130,000 in bug bounty rewards for it.

The naming gap between internal and public

When building a piece of software, a text file specifies which packages are needed. A helper program, the package manager, reads this list and downloads everything. It often searches multiple sources at once: the internal company storage and the large public collection. If the name exists in both sources, it has to make a choice.

This is exactly where the flaw in the default settings of many systems lay. They did not choose the internal source, but simply the highest version number. The attacker therefore uploads their package as version 99.0.0. Their package wins automatically, without anyone having to click anything. The attack requires no stolen passwords and no security vulnerability in the classic sense.

The names of internal packages are not much of a secret, either. They turn up in accidentally published source code, in error messages, or in JavaScript files on websites. Several countermeasures now exist. Companies preemptively reserve their internal names in the public collection. It is also possible to configure certain name ranges so that they may only be looked up internally.

Where the term appears in security advisories

As a user, you never notice Dependency Confusion directly. The term appears in reports about security incidents at software vendors and in warnings from authorities such as Germany’s BSI. Primarily affected are the package collections npm for JavaScript, PyPI for Python, and RubyGems. Systems for Java and for container software also know this problem.

For the economy, the topic is relevant because supply chain attacks are expensive and hard to insure against. Regulators increasingly require companies to provide a bill of materials for their software, a so-called SBOM. It lists which foreign building block is contained in which product. If a package is exposed as malicious, it becomes easier to quickly determine who is affected.

A common mistake is confusing Dependency Confusion with typosquatting. In typosquatting, the attacker relies on typos and names their package, for example, “reqeusts” instead of “requests”. Dependency Confusion requires no typo. The name is spelled exactly right; only the source is the wrong one.