Dependency Hijacking

Expanded Definition

Dependency hijacking is a supply chain compromise that sits between package discovery and package execution: an attacker publishes or reclaims a dependency name, then waits for build systems, installers, or automation to resolve that name as trusted input. In NHI and IAM contexts, the risk is not just malicious code, but the way build pipelines often run with service account privileges, access to secrets, and deployment authority. That means a hijacked package can become a path to credential theft, CI/CD compromise, or downstream environment takeover rather than a simple malware event. Controls such as NIST SP 800-53 Rev 5 Security and Privacy Controls help frame the need for provenance, change control, and software integrity checks, but usage in the industry is still evolving across ecosystems and package registries. The most common misapplication is treating dependency hijacking as a pure developer hygiene issue, which occurs when organisations ignore build identities, package provenance, and automated update paths.

Examples and Use Cases

Implementing dependency controls rigorously often introduces release friction, requiring organisations to weigh rapid dependency updates against stricter provenance checks and review gates.

• A build pipeline pulls a package name that was abandoned upstream and later republished with malicious code.
• A compromised internal project depends on a transitive package that silently changes ownership and starts exfiltrating secrets.
• An auto-update process installs a new version after the original maintainer loses control of the repository.
• A CI runner with broad service account access executes compromised install hooks and exposes signing credentials.

A useful case study is the LiteLLM PyPI package breach, which shows how package trust can collapse when registry assumptions outpace verification. For governance depth, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a control vocabulary for integrity monitoring and controlled software acquisition.

Why It Matters in NHI Security

Dependency hijacking matters in NHI security because the attack frequently targets machine identities that are already trusted to fetch, build, sign, or deploy software. Once those identities are abused, the incident can move from code execution to secrets exposure, lateral movement, and release tampering. NHI Management Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which helps explain why package compromise so often becomes an identity incident rather than a standalone application issue. The same risk is amplified when organisations store secrets in code, allow broad token access, or fail to rotate credentials used by CI/CD systems and package managers. Dependency hijacking therefore forces teams to treat software intake as an identity control surface, not just a dependency management task. It also shows why external guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant to build integrity, provenance, and least privilege. Organisations typically encounter the operational impact only after a package update, pipeline failure, or secret leak, at which point dependency hijacking becomes unavoidable to investigate and contain.

Related resources from NHI Mgmt Group

• When does a dependency compromise become an identity incident?
• How can security teams reduce the risk of session hijacking in SaaS environments?
• Why does MFA not stop session hijacking?
• What is the difference between credential theft and session hijacking?