Dependency Tampering

Expanded Definition

Dependency tampering is broader than a simple package update gone wrong. It includes replacing a trusted package with a malicious one, modifying a version pin, altering a source repository, or redirecting a build to an unexpected artifact registry. In NHI and agentic AI workflows, the risk becomes acute when an assistant, pipeline, or automation token can fetch, install, or upgrade dependencies without human review. That makes the dependency itself part of the trust boundary, not just a convenience layer in software delivery. Guidance varies across vendors on whether dependency tampering is treated as supply chain compromise, build integrity failure, or runtime poisoning, but the operational concern is the same: untrusted code enters through a path that appears legitimate. Controls in the NIST Cybersecurity Framework 2.0 reinforce the need for protective process around software acquisition and change control. The most common misapplication is assuming a version number is sufficient proof of trust, which occurs when automation accepts packages from unverified sources or mutable tags.

Examples and Use Cases

Implementing dependency control rigorously often introduces release friction, requiring organisations to weigh delivery speed against the cost of verification, pinning, and approval gates.

• An AI coding assistant is allowed to install libraries directly during a task, but a compromised package registry swaps in a backdoored dependency before the build completes.
• A CI/CD job pulls from an internal mirror that was silently altered, so the runtime receives a modified package even though the manifest looks correct.
• An engineer pins a dependency to a broad version range, and a minor update introduces unexpected behaviour or malicious code after the next rebuild.
• A workflow token used by an agent can write to the dependency lockfile, letting the agent “helpfully” refresh packages from an untrusted source.
• A real-world package incident such as the LiteLLM PyPI package breach shows why source integrity and provenance checks must be treated as first-class controls, not optional hygiene.

For implementation patterns, teams often pair package allowlisting with signed artifacts, immutable registries, and dependency review policies. Provenance guidance in ecosystems such as SPIFFE is useful when identity-bound workloads need to prove what is allowed to fetch or publish code, although no single standard governs every dependency workflow yet.

Why It Matters in NHI Security

Dependency tampering can turn a legitimate NHI into a delivery mechanism for malicious code. Once an agent, service account, or automation token has permission to install, update, or execute dependencies, a compromised package source can pivot directly into build systems, CI runners, and runtime environments. That is especially dangerous in environments where secrets are stored outside a manager or where build identities have broader access than developers expect. NHI Mgmt Group reports that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, and dependency compromise often becomes the path that exposes those secrets at scale. Zero Trust thinking applies here: every artifact and source should be continuously verified, not trusted because it sits inside the network. The Ultimate Guide to Non-Human Identities is a useful reference for understanding why excessive NHI privilege magnifies this exposure, and why rotation, visibility, and least privilege matter in adjacent controls. Organisations typically encounter dependency tampering only after a build is poisoned or secrets are exfiltrated, at which point package trust 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?