Dependency Grafting

Dependency grafting is the practice of republishing or modifying a trusted package so that it pulls in a malicious dependency chain. It is effective because consumers trust the parent package, not only the new payload, which lets attackers fan out compromise through existing bundles.

Expanded Definition

Dependency grafting is a software supply chain attack pattern in which a trusted package is republished or modified so that it resolves and pulls in a malicious dependency chain. The parent package still looks familiar, so the compromise hides inside ordinary dependency resolution rather than a visibly new artifact.

In NHI security, the risk is not limited to code integrity. A grafted package can redirect installers, build jobs, and agent tooling toward attacker-controlled libraries that request secrets, tokens, or cloud permissions during execution. That makes the tactic especially relevant where automation runs with elevated access and relies on cached trust in package names or version ranges. Definitions vary across vendors on whether this belongs under dependency confusion, typosquatting, or broader package tampering, but the operational concern is the same: trust is transferred from the original package to an altered chain. Guidance from the NIST Cybersecurity Framework 2.0 reinforces the need to govern software integrity, supplier risk, and change control across the build path. The most common misapplication is assuming a signed or well-known parent package is safe when the downstream dependency graph has changed in a CI environment.

Examples and Use Cases

Implementing dependency controls rigorously often introduces build friction, requiring organisations to weigh developer convenience against stronger verification, pinning, and review steps.

• A republished internal package adds a new transitive dependency that quietly attempts to read cloud environment variables during installation.
• A build pipeline accepts a version range instead of a pinned hash, so a malicious minor release enters production through normal package resolution.
• An agent framework installs plugins dynamically, and one plugin pulls in a compromised helper library that can access secrets stored for the automation runtime.
• The LiteLLM PyPI package breach shows how package trust can be abused to reach credentials and user environments through familiar distribution channels.
• Package governance programs compare dependency trees against allowlists and attestations, using controls from NIST Cybersecurity Framework 2.0 to verify that approved software still matches what was reviewed.

Why It Matters in NHI Security

Dependency grafting matters because NHIs often inherit trust from automation rather than human review. A compromised dependency can turn a routine install into a secret-exfiltration event, a token theft path, or a stepping stone into cloud control planes. That is especially dangerous where service accounts, API keys, and build credentials are exposed to package install hooks or test-time execution. NHI Management Group reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 80% of identity breaches involved compromised non-human identities, which makes supply-chain compromise a direct identity problem rather than only a code problem. The same pattern also undermines supply chain trust when third-party packages are consumed by CI/CD systems, agent runtimes, or infrastructure provisioning tools. As NHI programs mature, this is where package provenance, dependency review, and secret isolation converge with NHI governance guidance and the broader supply-chain discipline described in the NIST Cybersecurity Framework 2.0. Organisations typically encounter the impact only after a build or deployment has already leaked credentials, at which point dependency grafting becomes operationally unavoidable to address.

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?