Why do npm supply chain attacks become broader when secrets are stored in developer workspaces?

Why This Matters for Security Teams

npm supply chain attacks become broader when developer workspaces contain reusable secrets because the compromise stops being a single-package event. A stolen GitHub token, cloud credential, or publish key can let an attacker impersonate maintainers, access private repositories, and push malicious updates across dependencies. That turns a local compromise into a distribution problem, which is exactly why NHI exposure is a supply chain issue, not just a workstation hygiene issue.

The pattern is visible in incidents such as the Shai Hulud npm malware campaign and the Miasma and Hades Supply Chain Worms, where one foothold was enough to uncover more credentials and widen reach. NHIMG research in The State of Secrets in AppSec reports that the average time to remediate a leaked secret is 27 days, which is long enough for attackers to weaponise a compromised workspace.

In practice, many security teams discover breadth only after secrets have already been reused for package publication, CI access, or cloud abuse rather than through intentional containment.

How It Works in Practice

Developer workspaces are high-value because they often combine source code, cached credentials, package manager state, and access to signing or publishing workflows. Once malware lands in that environment, it can search common locations such as shell history, environment variables, credential stores, local config files, and build artifacts. From there, the attacker can move from code theft to authentication theft, then from authentication theft to propagation.

This is why static, role-based IAM is often too blunt for npm ecosystems. A maintainer role may be legitimate, but if its secret is sitting on a laptop or runner for weeks, the attacker inherits the same standing access. Current guidance suggests shifting toward short-lived, task-scoped credentials and workload identity, so the system proves what the process is at runtime rather than trusting a long-lived token stored on disk. Standards such as the OWASP Non-Human Identity Top 10 and NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce least privilege, credential lifecycle management, and revocation discipline.

Operationally, teams should think in terms of containment layers:

• Use just-in-time credentials for publish, deploy, and registry access.
• Keep secrets out of developer workspaces where possible by moving them into managed secret stores.
• Prefer workload identity or ephemeral tokens over long-lived API keys.
• Reduce token scope so a compromised token cannot publish broadly or reach unrelated cloud resources.
• Automate revocation when a secret is detected, not just alerting.

NHIMG’s analysis in The State of Secrets Sprawl 2026 shows that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is a strong indicator that detection without fast revocation leaves the propagation path open. These controls tend to break down when CI/CD runners and developer laptops share the same long-lived publish credentials because one compromise can immediately impersonate the entire release pipeline.

Common Variations and Edge Cases

Tighter secret controls often increase developer friction and pipeline complexity, so organisations have to balance speed against blast-radius reduction. That tradeoff becomes especially visible in monorepos, fork-heavy open source workflows, and polyglot build systems where multiple package registries, cloud accounts, and signing systems are in play.

One common exception is internal tooling that still requires human-managed access for release approvals. Best practice is evolving here, and there is no universal standard for every workflow, but the direction is consistent: separate approval from execution, and keep execution credentials ephemeral. Another edge case is secret discovery inside non-code channels. NHIMG notes that a meaningful share of incidents now originate outside repositories, which means Slack exports, tickets, and documentation can be just as dangerous as source files.

For deeper incident patterns, the 52 NHI Breaches Analysis shows how compromised identities are often reused across systems once they are exposed, while the Reviewdog GitHub Action supply chain attack illustrates how workflow compromise can expose secrets at scale. The practical takeaway is that npm security cannot rely on code scanning alone when the real propagation engine is credential reuse across developer and CI environments.

Related resources from NHI Mgmt Group

• How do attackers turn stolen npm secrets into broader compromise?
• Why do npm supply chain attacks often become NHI governance failures?
• Why do developer workstations increase the blast radius of supply-chain malware?
• How can security teams detect package supply chain attacks that hide their C2 infrastructure?