Why do malicious dependencies create such a large identity risk for engineering teams?

Because they can reach the secrets already sitting in the runtime context. Developer machines and CI/CD runners often hold cloud credentials, deployment tokens, and cluster access, which means a package compromise can become an identity compromise without breaking authentication. The risk is highest where secrets are long-lived, broadly scoped, or reused across environments.

Why This Matters for Security Teams

Malicious dependencies are dangerous because they turn software delivery into an identity exposure problem. When a compromised package runs inside a developer workstation, build runner, or deployment job, it can read environment variables, local key stores, cloud CLI caches, and mounted credentials without needing to defeat authentication. That is why dependency compromise so often becomes a secrets problem first and a malware problem second. The Ultimate Guide to NHIs notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks.

This risk is especially acute in engineering teams because modern delivery pipelines reuse identities across many tools and environments. A package that executes during install, test, or build does not need broad persistence to be damaging; it only needs a short window to discover reusable tokens, service account keys, or cluster credentials. That is also why the NIST Cybersecurity Framework 2.0 emphasis on asset visibility and access control matters here, not just endpoint protection. In practice, many security teams encounter identity compromise only after a dependency has already harvested secrets and reused them elsewhere.

How It Works in Practice

A malicious dependency usually succeeds by inheriting trust from the place it is installed. During package resolution, post-install hooks, test execution, or CI job startup, the code runs with the same runtime context as the legitimate build. If that context includes cloud credentials, registry tokens, signing keys, or cluster access, the package can exfiltrate them silently. The problem is not limited to obvious secrets files. Teams often leak credentials through shell history, process environment variables, agent caches, mounted volumes, and developer tooling caches. NHIMG research on the 52 NHI Breaches Analysis and JetBrains GitHub plugin token exposure shows how quickly a software supply chain issue can become a credential exposure issue.

Effective defence starts by reducing what a dependency can touch:

• Use short-lived, task-scoped credentials instead of long-lived static keys.
• Separate build, test, and deploy identities so compromise in one stage does not automatically reach the next.
• Keep secrets out of source trees, package metadata, and CI variables where possible.
• Prefer workload identity and federated access over copied tokens and shared service accounts.
• Monitor package installs and pipeline execution for unexpected outbound connections or credential access.

For software teams, the operational model should align with least privilege and ephemeral access, not convenience. Current guidance suggests treating CI/CD runners as high-value identity hosts because they often hold the most reusable credentials in the delivery chain, and the Ultimate Guide to NHIs highlights that 97% of NHIs carry excessive privileges. These controls tend to break down when shared runners, cached secrets, and broad deployment tokens are used across multiple repositories and environments because a single compromise then has cross-system reach.

Common Variations and Edge Cases

Tighter dependency controls often increase build friction, requiring organisations to balance developer speed against secret exposure risk. That tradeoff becomes visible in environments that rely on private package registries, offline builds, or monorepo pipelines where multiple teams share the same execution layer. Best practice is evolving, but there is no universal standard for how much package execution should be restricted versus observed.

One common edge case is sandboxed builds that still inherit a surprising amount of identity context through metadata services, federation brokers, or preloaded helper tools. Another is trusted open-source packages that are later abandoned or updated by a compromised maintainer account. In both cases, the dependency may be legitimate while the identity exposure is not. Teams should therefore review not only package provenance but also where credentials are injected, how long they remain valid, and whether the runtime can reach production-grade secrets at all. The most dangerous setups are those where a transient build token can later be exchanged for a durable cloud or cluster credential, because the dependency does not need to steal the crown jewels directly to create the incident.

Related resources from NHI Mgmt Group

• Why do build pipelines create such a large NHI compromise risk?
• Why do stale accounts and old privilege create such a large persistence risk?
• Why do malicious AI repositories create both human and NHI identity risk?
• Why can a single SaaS app create such a large blast radius?