Why do npm supply chain attacks create such a large blast radius?

Why This Matters for Security Teams

npm supply chain attacks produce a large blast radius because package install and build workflows sit close to high-value OWASP Non-Human Identity Top 10 concerns: tokens, service accounts, CI secrets, and developer credentials often coexist in the same execution path. Once a dependency is compromised, the attacker is not just reaching code. They are reaching the identities that code can act through, which is why supply chain incidents often become identity incidents as well. NHIMG’s Shai Hulud npm malware campaign shows how quickly malware can pivot from a package to exposed secrets, and the Reviewdog GitHub Action supply chain attack demonstrates how build-time trust expands exposure beyond the original repository.

The risk is amplified because many organisations still treat package installs as routine developer activity rather than privileged execution. That assumption breaks down when install scripts, postinstall hooks, and CI runners inherit access to cloud consoles, registry tokens, GitHub org permissions, and secret stores. Even a single compromised dependency can therefore unlock multiple NHI paths in parallel. In practice, many security teams discover this only after secrets have already been exfiltrated, rather than through intentional package governance.

How It Works in Practice

The blast radius grows when a malicious package runs in an environment that already holds multiple non-human identities. A developer laptop may have local cloud sessions, SSO refresh tokens, and access to internal repositories. A CI runner may have deploy credentials, container registry access, and secret manager permissions. If the package executes during install, test, or build, it can enumerate environment variables, read local files, scrape credential stores, and attempt lateral reuse before defenders notice. The 52 NHI Breaches Analysis is a useful reminder that compromised identities tend to cascade when a single secret is reused across systems.

Current guidance suggests reducing the number of standing secrets present during package operations, but there is no universal standard for this yet. Stronger patterns include:

• Use JIT, short-lived credentials for build jobs instead of long-lived static secrets.
• Separate package installation from secret-bearing steps so dependency code cannot reach deploy privileges.
• Bind identity to workload context, not just to a user session, using workload identity patterns and strong token scoping.
• Block postinstall execution where possible, and isolate untrusted builds in ephemeral runners.
• Apply policy-as-code at request time so CI and agentic automation cannot self-expand access.

This aligns with the direction of the Anthropic first AI-orchestrated cyber espionage campaign report, which reinforces how automated systems can chain small permissions into broad compromise. These controls tend to break down when CI systems are shared across teams because credential reuse and ambient privilege make containment unreliable.

Common Variations and Edge Cases

Tighter package controls often increase developer friction and build overhead, so organisations must balance supply chain speed against identity containment. That tradeoff matters most in monorepos, multi-tenant CI, and self-hosted runners, where a single malicious package can inherit broader trust than teams realise. Guidance is evolving, but best practice is to treat every install step as an untrusted execution boundary unless it is explicitly isolated.

Two edge cases deserve attention. First, dependency compromise is not always about stealing one secret; sometimes the payload uses one token to fetch more tokens, which is why layered access review matters. Second, agentic automation can worsen the blast radius because autonomous tools may chain package actions with repository writes, cloud calls, and secret lookups. That is why the Top 10 NHI Issues and DeepSeek breach both matter here: they show how exposed code, exposed secrets, and automated reach can combine into a much larger incident than the initial package compromise suggests. For implementation detail, the CISA cyber threat advisories and OWASP Non-Human Identity Top 10 both support narrowing standing privilege and limiting secret exposure at build time.

In the real world, the largest blast radius appears when package compromise meets flat CI trust, long-lived tokens, and insufficient separation between code execution and identity authority.

Related resources from NHI Mgmt Group

• Why can a single SaaS app create such a large blast radius?
• Why do SaaS supply-chain attacks create a larger blast radius than direct account compromise?
• Why do workflow engines create such a large blast radius for attackers?
• Why do non-human identities increase the blast radius of supply chain attacks?