What is Dependency Confusion?

Dependency confusion is a supply chain attack in which a package manager installs a public package instead of the intended private dependency. If an attacker learns an internal package name and publishes the same name publicly-often with a higher version-their code may execute during build or installation.

Simplified example

{
  "dependencies": {
    "company-auth-utils": "^2.4.0"
  }
}

# Unsafe setup: both private and public registries are sources,
# while the private name is not protected publicly.

If company-auth-utils@99.0.0 appears publicly and the resolver favors the highest version, the external package may win. Registry order, fallback or missing scopes create variants across ecosystems.

What leaks useful names?

• - Public JavaScript, errors, lockfiles and documentation.
• - Accidentally published artifacts and images.
• - Build scripts, job listings and open repositories.

Secure configuration

# npm example: bind the scope to the private registry
@company:registry=https://npm.company.example/repository/npm/
registry=https://registry.npmjs.org/

npm ci

• - Use unique organizational scopes and reserve them publicly.
• - Bind private names to private sources with no silent public fallback.
• - Review lockfiles and retain source/integrity information.
• - Run lifecycle scripts in isolated builders with minimal secrets and network access.
• - Control new sources, unusual version jumps and maintainer changes.

Safe testing and tools

Do not register real internal names publicly without authorization. Use an isolated registry, invented package, secret-free runner and harmless callback. Configuration and lockfile review is often safer than a public proof. Confused flags dependencies that may exist only privately; candidates are not proof. Syft helps inventory actual components and sources.