Dependency poisoning is the abuse of a trusted software package or update channel to deliver malicious code. The attack succeeds because downstream projects accept the package as legitimate, allowing the attacker to reach build and runtime environments through normal development workflows.
Expanded Definition
Dependency poisoning is a supply chain attack that targets the trust model around software packages, package indexes, mirrors, and build pipelines. Rather than exploiting an application directly, the attacker corrupts a dependency path so that normal installation, update, or build processes pull in malicious code. That makes the attack especially dangerous in CI/CD and automated agent workflows where packages are accepted based on name, version, signature, or repository reputation.
In NHI and agentic AI environments, dependency poisoning can affect code libraries, model tooling, and automation components that carry credentials, tokens, or service account access. The practical distinction is that the attacker does not need to own the consuming project first; they only need to influence what the project trusts. Definitions vary across vendors on whether dependency poisoning includes typosquatting, maintainer account takeover, or only compromised upstream releases, but the core issue is the same: trusted dependency channels become the delivery mechanism. The most common misapplication is treating dependency poisoning as a generic malware problem, which occurs when teams focus on endpoint scanning but ignore package provenance, pinning, and update integrity.
For broader identity and software supply chain context, NIST’s NIST Cybersecurity Framework 2.0 is useful for aligning governance, detection, and response expectations across the software lifecycle.
Examples and Use Cases
Implementing dependency controls rigorously often introduces release friction, requiring organisations to weigh developer velocity against provenance checks, review gates, and stricter update approval.
- A public package maintainer account is compromised, and a new release adds code that exfiltrates build secrets from downstream pipelines.
- A typosquatted dependency name is published to a package registry, and an automated build installs it because the version constraint is too broad.
- A trusted internal library is updated with malicious logic, then pulled into multiple applications that use shared service account tokens.
- A CI runner fetches dependencies from an unpinned mirror, letting an attacker swap a legitimate package for a poisoned one during a routine build.
- An AI agent toolchain installs a compromised SDK dependency and then inherits access to APIs, secrets managers, or deployment credentials.
These scenarios are increasingly visible in real-world incidents, including the LiteLLM PyPI package breach, which illustrates how trusted distribution paths can be abused once package integrity breaks down. The package ecosystem guidance in NIST Cybersecurity Framework 2.0 helps map these risks to software acquisition and continuous monitoring.
Why It Matters in NHI Security
Dependency poisoning matters in NHI security because poisoned packages often arrive with the same runtime privileges that legitimate build tools, bots, and service accounts already possess. That means one compromised dependency can become a shortcut to secrets, deployment rights, cloud APIs, and production automation. NHI Management Group notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes dependency-driven compromise far more damaging once malicious code lands in the pipeline.
The risk is not limited to code theft. A poisoned dependency can silently alter runtime behaviour, mint credentials, or weaken logging and validation, turning a software update into an identity event. It also exposes the weakness of treating package trust as a one-time procurement decision instead of a continuously verified control surface. When dependency poisoning is present, NHI governance must cover provenance, checksum verification, signature validation, least privilege for build identities, and rapid revocation of any secrets accessible during installation.
That is why the issue often becomes visible only after an unusual build, data leak, or cloud misuse has already occurred, at which point dependency poisoning becomes operationally unavoidable to investigate and contain.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers NHI supply chain and secret exposure risks from trusted software paths. |
| NIST CSF 2.0 | SR-3 | Addresses software supply chain risk management across acquisition and monitoring. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification even for trusted build and update channels. | |
| NIST AI RMF | AI systems inherit supply chain risks from third-party dependencies and tools. | |
| CSA MAESTRO | Agentic workflows depend on external tools and packages that can be poisoned. |
Verify package provenance and restrict build-time secrets to limit poisoned dependency impact.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
