A malicious dependency is a package that appears legitimate but contains code designed to steal secrets, alter builds, or create follow-on access. In modern pipelines, the risk is not only the package content but also when and where it executes, especially during install or import.
Expanded Definition
A malicious dependency is broader than a simple “bad package.” It is any third-party library, module, wheel, container layer, or transitive component that behaves in ways the consuming team did not intend, especially when the behaviour is hidden until install, import, build, or runtime. In software supply chain security, the concern is not limited to obviously counterfeit packages. It also includes trusted packages that have been compromised, typosquatted packages that imitate legitimate names, and dependency chains where a downstream component introduces risk without the top-level maintainer noticing.
Definitions vary across vendors on whether the term should include only intentionally harmful packages or also compromised legitimate packages, but the security outcome is the same: untrusted code executes inside the development or delivery pipeline. NHI Management Group treats the term as a supply chain trust issue with direct implications for secrets exposure, build integrity, and release provenance. The NIST Cybersecurity Framework 2.0 is useful here because it frames supplier and technology risk as an enterprise governance problem, not just a tooling problem. The most common misapplication is assuming a dependency is safe because it came from a known registry, which occurs when teams trust the package source but do not verify package identity, integrity, or install-time behaviour.
Examples and Use Cases
Implementing dependency screening rigorously often introduces friction in build pipelines, requiring organisations to weigh developer speed against the cost of tighter verification and change control.
- A package installed during CI runs a post-install script that reads environment variables and exfiltrates API keys from the build agent.
- A transitive dependency is updated by a maintainer account takeover, introducing code that alters artifacts before signing.
- A typosquatted Python or JavaScript package mimics a legitimate name and is pulled in by mistake during a rushed sprint.
- A container image includes a malicious layer from a public base image, creating hidden persistence in downstream deployments.
- An internal package mirror caches a poisoned version before the security team can revoke it, spreading the issue across multiple services.
Operational controls should reflect where the risk appears, which is often before production. SCA tools, locked dependency manifests, signed packages, and provenance checks are strongest when they are paired with policy enforcement and review. Guidance from SLSA and Sigstore is especially relevant because both focus on build integrity and verifiable supply chain evidence. In practice, the term also applies to modern AI delivery stacks when model-serving code pulls packages that can access prompts, embeddings, or secrets stored alongside agentic workflows.
Why It Matters for Security Teams
Malicious dependencies turn software composition management into a live incident-response issue because the risk can arrive through a routine update rather than an obvious intrusion. Security teams need to understand that the blast radius is often defined by what the package can touch: source code, CI variables, signing keys, artifact repositories, or deployment credentials. Once a malicious dependency executes, attackers can pivot from build systems into identity infrastructure by stealing service credentials, cloud tokens, or NHI secrets that automate releases. That makes the term relevant to PAM, secrets governance, and agentic AI systems that rely on delegated tool access.
For governance, the important question is not only whether a package is malicious, but whether the organisation can prove which version was used, when it ran, and what it accessed. That evidence supports containment, rollback, and supplier escalation. The security signal often becomes visible only after a build compromise, credential theft, or suspicious change in downstream output, at which point malicious dependency 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 SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC | CSF 2.0 addresses supplier and technology risk management relevant to malicious dependencies. |
| NIST SP 800-53 Rev 5 | SR-3 | Supply chain controls cover component authenticity and protection against malicious software. |
| OWASP Non-Human Identity Top 10 | Dependency compromise often exposes non-human credentials and secrets used by automation. | |
| OWASP Agentic AI Top 10 | Agentic workflows can execute dependency code with tool access and delegated authority. | |
| NIST AI RMF | AI RMF applies where malicious dependencies affect AI pipelines, models, or delegated automation. |
Treat dependency trust as supplier risk and require verification, approval, and monitoring across the pipeline.
Related resources from NHI Mgmt Group
- How should teams slow down malicious dependency updates without breaking delivery?
- What breaks when a malicious package runs during dependency installation?
- Who is accountable when a malicious dependency exposes cloud and Kubernetes credentials?
- What breaks when a malicious dependency can read developer credentials and cloud tokens?
