Dependency Confusion

CriticalDevOps SecurityA06:2021 – Vulnerable and Outdated Components / A08:2021 – Software and Data Integrity Failures

An attacker publishes a public package with the same name as an internal one, and build tools install the attacker's higher-versioned package instead, running malicious install scripts in CI or developer machines.

Immediate Response

1Stop affected pipelines and quarantine build agents that installed the package.
2Rotate all secrets available to those agents and developer machines.
3Identify every build and artifact produced while the malicious package was present.
4Report the malicious package to the public registry for removal.

All playbooks

1Route all package installs through a private proxy registry that prefers internal packages.
2Use scoped packages such as @org/name on npm and reserve your scope.
3Pin index URLs and use hash-checked installs for Python.
4Commit lockfiles and fail builds when resolved sources change unexpectedly.

Long-term Prevention

1Register placeholder packages for internal names on public registries.
2Disable install scripts in CI where possible and run installs in sandboxed, egress-restricted agents.
3Generate SBOMs and verify provenance of dependencies.
4Continuously monitor public registries for packages matching internal names.

Attack vectors

Internal package names leaked through public repositories, manifests, or error messages
Package managers configured to check public registries alongside private ones
Unscoped internal npm packages or Python packages without index pinning
Install-time scripts that execute immediately on download

Indicators of compromise

Builds pulling internal package names from a public registry
Unexpected outbound DNS or HTTP calls from build agents during install
Lockfile changes resolving internal packages to public registry URLs
Public packages matching internal names with unusually high version numbers

Tooling

JFrog ArtifactorySonatype NexusSocketSyftGrype