Dependency Redirection

The act of steering a package install or build process away from the intended trusted source to an attacker-controlled one. It is dangerous because the resulting code may still function normally, letting malicious content enter the environment without immediate detection.

Expanded Definition

Dependency redirection describes a supply chain attack pattern in which an installer, package manager, build pipeline, or other automated retrieval process is induced to fetch code from a source that was not intended by the organisation. The redirected dependency can preserve the expected package name, interface, or version shape, which is why the compromise is often subtle at first. In practice, the risk is not limited to public open-source ecosystems. It also affects internal registries, mirrored artifact repositories, CI/CD jobs, and build scripts that trust upstream resolution rules too broadly.

This term is closely related to dependency confusion and typosquatting, but it is not identical to either. Dependency confusion typically involves selecting a more permissive external package when an internal one is expected, while dependency redirection is broader and covers any steering of retrieval away from the trusted source. Definitions vary across vendors and incident reports, so NHI Management Group treats the term as a class of source-substitution failures rather than a single exploit path. For governance context, the NIST Cybersecurity Framework 2.0 is useful because it frames the need to manage software supply chain risk, even though it does not name this attack pattern directly. The most common misapplication is assuming package integrity checks are sufficient, which occurs when teams verify hashes after the wrong source has already been trusted.

Examples and Use Cases

Implementing controls against dependency redirection rigorously often introduces build friction, requiring organisations to weigh automation speed against stronger source validation and approval gates.

• A CI pipeline resolves a library name through a public package registry because the internal mirror is unavailable, allowing an attacker-published package to be pulled in under the expected name.
• A build script uses a permissive download URL pattern and follows redirects without validating the final host, so a dependency is fetched from an untrusted domain.
• An internal artifact repository is misconfigured to proxy multiple upstream sources, and a malicious package is accepted because source precedence is not strictly enforced.
• A developer workstation installs a dependency from a compromised DNS or repository path, and the package behaves normally enough to bypass casual review.
• Security teams map the risk to software supply chain controls and package governance guidance in NIST SP 800-218, especially where build provenance and component trust need explicit enforcement.

Why It Matters for Security Teams

Dependency redirection matters because it breaks the assumption that the software you requested is the software you received. That failure can introduce backdoors, credential theft code, or subtle tampering into applications, infrastructure-as-code, and deployment tooling before any runtime alert is triggered. The security impact is often amplified in environments that treat build systems as trusted and give them broad access to secrets, signing keys, and deployment permissions. Where NHI is involved, the consequence can extend to stolen API keys, service account tokens, and automation credentials that are embedded in pipelines or fetched during builds.

Security teams need to control source precedence, pin package origins, verify repository trust, and constrain build identities so they cannot freely reach arbitrary networks or registries. Guidance from CISA secure software development resources and software supply chain practices should be applied alongside internal allowlists, signed artifacts, and change monitoring. The issue becomes even more important when agents or automation are permitted to create, update, or deploy code on their own, because a redirected dependency can give that software an attacker-controlled instruction set. Organisations typically encounter the operational impact only after a build produces an unexpected artifact or a production secret is exposed, at which point dependency redirection becomes impossible to ignore.

Related resources from NHI Mgmt Group

• When does a dependency compromise become an identity incident?
• How should teams slow down malicious dependency updates without breaking delivery?
• What is the difference between automating dependency updates and granting them blind trust?
• Should organisations allow pull_request_target for automated dependency workflows?