1. Home
  2. Countermeasure
  3. Dependency Confusion

Dependency Confusion

Dependency confusion is a software supply chain attack in which an adversary publishes a malicious package to a public repository using the same name as an organization's internal private package, exploiting build tools that may inadvertently resolve the public version over the intended internal one. Mitigating this attack requires a layered set of controls: internal dependencies must be sourced exclusively from private, controlled repositories rather than public package registries; build and continuous integration and continuous delivery (CI/CD) pipeline configurations must explicitly define trusted repository sources and resolution order to prevent inadvertent public package substitution; and dependency integrity must be validated at the point of consumption by verifying that cryptographic checksums match those of the known-good official packages. A secure build environment is a prerequisite for these controls to be effective, as a compromised build environment can undermine dependency controls regardless of repository configuration. Together, these measures ensure that only verified, intended dependencies are incorporated into flight software, ground system software, and supporting toolchains.

Sources

ID: CM0013
Tier: I
Ground CM 
Created: 2022/10/19
Last Modified: 2026/08/06

Pre-Operations Government

Acquisition requirements should address dependency confusion as a named supply chain attack vector, requiring contractors to document and implement explicit controls governing how software dependencies are resolved across all build environments used to produce spacecraft and ground system software. Contract language should require that internal packages be sourced from private, access-controlled repositories and that CI/CD pipeline configurations enforce repository source restrictions that prevent build tools from silently falling back to public registries. Requirements should mandate cryptographic checksum validation of all dependencies at build time, with validation failures treated as blocking conditions rather than warnings. These controls should be flowed down to all subcontractors and third parties contributing software components to the delivered system. Verification should include review of build pipeline configurations and repository access policies at relevant integration milestones, with evidence of checksum validation processes reviewed prior to system acceptance.

Pre-Operations Developer/Supplier

Build system and dependency management configurations must explicitly bind internal package names or namespaces to approved private repositories and prevent fallback to public registries for those packages. Public repositories may remain available for approved public dependencies, but repository priority alone shall not be relied upon to prevent a public package from shadowing an internal dependency. Private repository infrastructure should be access-controlled, authenticated, and monitored for unauthorized package publication, ensuring that the trusted source itself is not compromised. Dependency manifests and lock files should bind dependencies to an approved package name or namespace, repository source, specific version, and validated artifact hash rather than relying on floating version references or package names that may resolve from multiple repositories. Cryptographic checksum or hash verification should be enforced as an automated build step, with the expected values sourced from a controlled reference distinct from the package registry itself to prevent an adversary who compromises the registry from also substituting expected hash values. The security of the build and CI/CD environment is a prerequisite for these controls to be effective; dependency confusion mitigations applied within a compromised pipeline provide no meaningful protection.