Static secrets make npm supply-chain attacks far easier to scale

At a glance

What this is: This is an analysis of the Shai-Hulud npm supply-chain campaign and how install-time malware turns exposed non-human credentials into reusable intrusion paths.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that remove static credentials from developer and CI environments before a single package install becomes account-wide access.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Riptides' analysis of Shai-Hulud and secret-hunting npm packages

Context

npm supply-chain compromise is not just a software distribution problem, it is an identity problem. When package install scripts can read files, environment variables, and CI runtime state, any long-lived token stored there becomes a reusable access path for the attacker.

The relevant security gap is static credential persistence across developer laptops, build runners, and CI pipelines. Once those credentials can be discovered and validated at install time, the attacker can pivot from one infected package to GitHub, AWS, package registries, or other connected services.

This pattern maps directly to Non-Human Identity governance because the credentials under attack are service tokens, API keys, and cloud access material rather than human passwords. The article’s starting position is typical for modern supply-chain abuse, where the initial entry point is a trusted dependency and the real prize is the identity sitting behind it.

Key questions

Q: How should security teams handle reusable secrets in npm build and CI environments?

A: They should remove reusable secrets from build paths entirely and replace them with workload-bound credentials that are issued only when needed. The goal is to make install-time malware unable to find a token worth stealing. That means repository scans, CI hardening, and immediate revocation when a secret is exposed.

Q: Why do static service tokens increase supply-chain compromise risk?

A: Static service tokens increase risk because they remain valid long enough for malware to discover, copy, and reuse them across multiple systems. In a supply-chain attack, that creates a second breach path after the initial package infection. Short-lived credentials reduce the attacker’s window and shrink the blast radius.

Q: What do teams get wrong about secret scanning in CI pipelines?

A: They often assume detection is enough, when the real problem is that a valid token can be used before the alert is triaged. Secret scanning finds exposure, but it does not stop replay. Teams need detection plus automatic revocation, scope review, and host-level controls that stop install-time access to secrets.

Q: How do IAM and NHI teams reduce lateral movement after a leaked token?

A: They should trace every system the token can reach, then cut off any standing privilege that extends beyond the original workload. The token’s effective blast radius matters more than where it was found. If the same credential can reach source control, CI, and cloud APIs, it needs immediate containment across all three.

Technical breakdown

Install-time payload execution in npm supply-chain attacks

In this campaign, the malicious code lives in package lifecycle hooks and executes during npm install, which means the attacker gets code execution as part of a normal developer or CI workflow. That matters because install-time execution runs before many security tools finish baseline checks, and it inherits the permissions of the build environment. The payload can inspect repository files, cache directories, and environment variables without needing a separate exploit chain. In practice, this turns dependency installation into an execution boundary breach rather than a simple malicious package issue.

Practical implication: treat package-install execution as a privileged event and constrain what install scripts can read.

Credential validation, persistence, and reuse

The payload does more than harvest strings. It checks whether discovered tokens actually work by calling provider endpoints and then uses valid credentials for persistence or follow-on actions. That changes the threat from opportunistic secret theft to active identity abuse, because a working token can create workflows, publish packages, or access cloud services without further compromise. This is why secret scanning alone is insufficient if the same credential remains valid after exposure. The attacker does not need to guess at value when validation is built into the malware.

Practical implication: couple secret detection with immediate revocation and scope review for any credential exposed in build paths.

Why static secrets on disk collapse the defense model

Static secrets create a durable attack surface because they survive beyond the session, the job, and often the original operator. In an NHI model, that is the structural weakness: if a token can be copied from disk or environment state, it can be replayed elsewhere until it is revoked. The campaign shows that attackers only need one reusable secret to expand from local execution to account-level access. That is why ephemeral issuance, workload binding, and removal of on-disk credentials are not optional hardening measures but the core of the defense model.

Practical implication: eliminate reusable credentials from repositories, CI configs, and build hosts, and replace them with workload-bound ephemeral identity.

Threat narrative

Attacker objective: The attacker wants reusable identity material that turns a supply-chain foothold into persistent access across source control, CI, and cloud services.

1. Entry occurs when trojanized npm packages execute bundle.js during installation and gain code execution inside developer or CI environments.
2. Escalation follows when the payload scans for GitHub, npm, and AWS credentials, validates working tokens, and reuses them to create persistence through workflows or package publishing.
3. Impact is account-wide access, secret exfiltration, and cloud lateral movement from a single compromised dependency path.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static secret persistence is the failure mode this campaign exploits. The attack works because credentials were still available in files, environment variables, and CI contexts after they should have been removed from reach. That is not a tooling gap alone, it is a governance assumption that the credential remains benign until a human notices exposure. Practitioner conclusion: treat persistence of reusable secrets as the core risk, not the package that first touched them.

Credential validation turns secret theft into identity abuse. The malware does not merely collect strings, it checks whether the token can be used and immediately turns working access into persistence or exfiltration. That behaviour breaks the common assumption that secret discovery is only a detection problem. Practitioner conclusion: exposure handling must include revocation, scope tightening, and downstream access tracing, not just alerting.

Identity blast radius is the right concept for supply-chain compromise. A single npm install can reach multiple trust domains because the same secret often works across GitHub, package registries, and cloud APIs. That is why one exposed token can create disproportionate impact relative to the original package compromise. Practitioner conclusion: govern NHI by the blast radius of the credential, not by the location where it was first stored.

On-disk credentials are now supply-chain multipliers. Once a malicious dependency can read the host filesystem or CI runtime, every reusable secret becomes an asset for the attacker. That is exactly why OWASP Non-Human Identity Top 10 style controls around secret storage and rotation matter here. Practitioner conclusion: shift from secret availability to secret non-persistence as the baseline control objective.

Shai-Hulud is a textbook example of why NHI governance must include build systems. Developer laptops and CI runners are not peripheral environments, they are identity-rich execution planes where service accounts and API keys are most exposed. The attack demonstrates that identity governance fails when build-time access is treated as less sensitive than production access. Practitioner conclusion: include CI and developer tooling in every NHI control review.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For a broader control lens, review Guide to the Secret Sprawl Challenge for the operational patterns that let secrets persist in the first place.

What this signals

Secret persistence is now a supply-chain governance problem, not just a detection problem. The issue is not whether a scanner can find a token, but whether that token is still valid when the attacker finds it. In that sense, lifecycle controls around issue, use, and revocation matter more than one-off hygiene checks. Teams that already rely on OWASP Non-Human Identity Top 10 controls should read this as a reminder that build systems are part of the identity perimeter.

The practical signal for programmes is that developer tooling and CI should be treated as credential-rich environments with the same governance standards as production. Once secrets can be read from install-time processes, the boundary between software delivery and identity compromise disappears. That makes workload identity, ephemeral credentials, and install-path isolation part of the core control set, not an advanced option.

Identity blast radius: one credential can now span source control, package publishing, and cloud access if it is reused across systems. That means NHI teams should measure not only how many secrets they have, but how many independent services each one can reach before revocation or expiry.

For practitioners

• Remove reusable credentials from build paths Audit repositories, package configuration, CI variables, and local dev profiles for long-lived tokens, then replace them with workload-bound or brokered credentials that never land on disk.
• Force immediate revocation on secret exposure When a token is discovered in a build environment, revoke it first and investigate later, because validation-ready malware can use the credential before the next review cycle completes.
• Lock down package-install execution Separate dependency installation from privileged runtime paths, restrict outbound network access during install, and prevent lifecycle hooks from reaching secrets stores or cloud metadata.
• Bind non-human identity to workload context Use short-lived, scoped credentials issued to the workload that needs them, so a copied token cannot be replayed from another process, runner, or repository checkout.

Key takeaways

• This campaign shows that npm supply-chain compromise becomes much more dangerous when install-time code can read reusable credentials from disk or CI.
• The scale of the risk is defined by token validity and blast radius, not by the first infected package.
• The control that changes the outcome is removing static secrets from build paths and replacing them with ephemeral, workload-bound identity.

Key terms

• Static Secret: A static secret is a credential that remains valid until someone manually rotates or revokes it. In NHI governance, static secrets are high-risk because they can be copied from files, environment variables, or CI systems and reused outside the original workload context.
• Install-time Execution: Install-time execution is code that runs as part of dependency installation rather than application runtime. In supply-chain attacks, it is dangerous because it inherits the permissions of the build environment and can search for secrets before normal controls have a chance to respond.
• Identity Blast Radius: Identity blast radius is the set of systems a credential can reach if it is stolen or replayed. It is a useful NHI lens because one token may span source control, CI, and cloud services, turning a single exposure into broad operational compromise.
• Workload-bound Credential: A workload-bound credential is issued for one process or service and is only valid in that execution context. This reduces replay risk because copied credentials are less useful outside the workload that obtained them, especially in CI and supply-chain-heavy environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Riptides: Shai-Hulud and the Secret Hunters, an analysis of npm installs turning into intrusions through compromised non-human identities. Read the original.