A poisoned dependency update is a malicious or tampered software package update that looks legitimate but introduces harmful code or behaviour. It exploits trust in automated dependency workflows, making dependency integrity checks, signed packages, and review controls essential for reducing supply chain risk.
Expanded Definition
A poisoned dependency update is not just a bad package release. In NHI security, it is a trust violation inside an automated software supply chain, where build systems, CI/CD runners, package managers, and deployment agents accept an update because it appears legitimate. The package may be signed, versioned correctly, and distributed through a trusted repository, yet still carry malicious code, altered behaviour, or a dependency chain compromise. This makes the term broader than simple malware delivery because the attack succeeds by exploiting normal automation, not by bypassing it.
Usage in the industry is still evolving when teams distinguish between poisoned updates, dependency confusion, and typosquatting, but the practical control objective is the same: verify provenance, integrity, and approval before software is allowed to execute. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that software supply chain integrity must be treated as a governance issue, not only a developer concern. The most common misapplication is assuming a package is safe because it comes from a familiar registry, which occurs when automated update pipelines trust source reputation more than cryptographic verification.
Examples and Use Cases
Implementing poisoned dependency update defenses rigorously often introduces release friction, requiring organisations to weigh deployment speed against inspection depth.
- A CI pipeline pulls a newly published library version that includes malicious post-install logic, similar to incidents discussed in the LiteLLM PyPI package breach, where trust in package distribution becomes an attack path.
- A build agent automatically upgrades a transitive dependency after a maintainer account is compromised, showing why dependency provenance must be validated against NIST Cybersecurity Framework 2.0 supply chain outcomes.
- An internal package mirror republishes an update without preserving signature metadata, creating a tampering window that security teams only detect after unusual outbound connections appear.
- An AI agent with repository write access approves an update based on version metadata alone, which is a common failure mode when autonomous tooling is allowed to act without human review.
- Service credentials embedded in a build environment are exfiltrated through a poisoned package post-install script, turning an update event into a broader NHI compromise.
Why It Matters in NHI Security
Poisoned dependency updates matter because they often target the same non-human workflows that already hold the highest trust: CI/CD systems, release automation, and service accounts. NHI Mgmt Group data shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, including code, config files, and CI/CD tools, which makes an update compromise far more damaging than a simple application defect. When a poisoned package reaches a pipeline, it can harvest tokens, alter deployment artefacts, or create persistent access paths that survive normal credential rotation.
This risk is especially severe in environments with weak visibility into service accounts and broad standing privileges. Controls such as signed package enforcement, dependency lockfiles, least-privilege build identities, and provenance attestation are essential, but they only work when paired with continuous review and alerting. The NHI security lesson is straightforward: supply chain compromise becomes an identity compromise when automation is allowed to execute untrusted code with privileged non-human credentials. Organisational teams typically encounter the real impact only after secrets are stolen or deployments behave unexpectedly, at which point poisoned dependency update handling becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and dependency trust failures that let malicious updates steal credentials. |
| OWASP Agentic AI Top 10 | A-04 | Agentic workflows can approve or execute poisoned updates without adequate verification. |
| NIST CSF 2.0 | PR.DS | Protects data and software integrity across supply chain and update processes. |
| NIST AI RMF | AI risk governance includes supply chain and trusted component integrity. | |
| NIST Zero Trust (SP 800-207) | SC-23 | Zero trust requires verified software sources and continuous validation of execution paths. |
Constrain agent tool access and require human approval for software changes with execution impact.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
