Dependency Confusion

Description

If the build system has no clearly configured package source, no namespace check, no locked versions and no integrity check, it can pull the malicious package by itself. In that case the attacker does not have to break into the repository. It is enough to slip into an unchecked build chain.

This is a good example of how a technical detail in the development process becomes a security problem. The package name, the order of the sources and the tool's default behavior decide what goes into the application. Without discipline there, the supply chain attack begins before production.

Examples

• An internal or public package has a name that is not reserved on the public registry, so the attacker publishes a package of the same name with a higher version.
• A CI pipeline pulls the malicious package instead of the real one during the build and runs its installation script.
• The name of a private dependency leaks through a mistake, through documentation or through a public repository, and becomes a target for registration on a public package registry.

Notes

• Dependency confusion is not the problem of one language or one registry. The pattern is the same everywhere a build system can choose between a private and a public source.
• A private registry, scoped names, a lockfile, pinned versions and integrity checks are not administrative details but control of the supply chain.