Shai-Hulud shows why static secrets still break npm supply chains

At a glance

What this is: This analysis shows how the Shai-Hulud npm worm used exposed static secrets to propagate through packages, developer environments, and CI/CD pipelines.

Why it matters: It matters because NHI, IAM, and PAM teams still relying on long-lived tokens and publish keys need to treat secret sprawl as a supply chain exposure, not just a hygiene issue.

Context

Shai-Hulud is a supply chain worm that spread through the npm ecosystem by harvesting static secrets and reusing them to publish compromised packages. In identity terms, the problem is not just malware delivery; it is the persistence of reusable non-human credentials across development and build environments.

The article argues that rotation alone does not solve the underlying exposure because secrets live too long, appear in too many places, and often carry more privilege than the task requires. For NHI governance, that shifts the question from how often to rotate toward how quickly static credentials can be eliminated entirely.

Key questions

Q: What breaks when CI/CD pipelines rely on static secrets?

A: Static secrets create a reusable attack path into production infrastructure. Once they are copied into workflow files, logs, runner images, or environment variables, a single compromise can expose broad access long after the original job finishes. That is why pipeline secrets should be treated as production identity, not temporary configuration.

Q: Why do reusable credentials increase supply chain risk in build systems?

A: Reusable credentials remain valid long enough to be copied, cached, logged, or exfiltrated. That gives attackers a window to act after the original workflow has finished. In build systems, that window is especially dangerous because the same host frequently holds cloud, registry, and signing credentials together.

Q: How do security teams know whether secret rotation is actually working?

A: Rotation is working only if exposed credentials are found quickly, revoked everywhere they are used and replaced before attackers can reuse them. If a secret remains valid after exposure, or if owners cannot prove where it was deployed, rotation is only reducing exposure on paper. The signal to watch is not the rotation schedule, but the time from leak to invalidation.

Q: What should organisations do first when package signing or publishing secrets are exposed?

A: Contain the exposure by revoking the affected credentials, then remove any workflow that still depends on those long-lived secrets. After that, replace the publishing path with ephemeral identity so the same secret cannot be stolen and replayed in the next build or install cycle.

Technical breakdown

How static secrets become propagation fuel in npm ecosystems

Static secrets create a reusable trust artifact that survives long enough to be stolen and replayed. In this attack pattern, package install scripts, environment variables, developer laptops, and CI/CD jobs all become places where the same credential can be discovered and reused. Once a token grants publish or repository access, the attacker does not need a new exploit path. The credential itself becomes the propagation mechanism, which is why worms can move from one compromised package to the next with very little friction.

Practical implication: treat npm publish tokens and similar secrets as propagation enablers, not mere authentication artifacts.

Why rotation does not remove standing privilege

Rotation reduces how long a credential remains valid, but it does not change the fact that the credential is a durable object with value before and after issuance. The article's core point is that static keys accumulate exposure windows across logs, repositories, caches, and developer tooling. When a credential is already embedded in workflows, rotating it after theft may limit the damage, but it does not prevent the initial abuse path or the next leak. The structural issue is standing privilege, not just weak rotation cadence.

Practical implication: prioritize credential designs that expire with the task, rather than relying on rotation to manage durable secrets.

Why dynamic identity changes the control model for non-human access

Dynamic identity changes the control point from secret storage to runtime issuance. Instead of provisioning long-lived tokens that must later be inventoried and rotated, the identity is minted just in time, scoped to a specific workload or publish event, and removed when the job ends. That removes the reusable artifact the worm depends on. For NHI governance, this is the difference between managing a persistent credential estate and governing ephemeral access outcomes. The control objective moves from rotation hygiene to issuance discipline.

Practical implication: shift NHI control design toward ephemeral, task-scoped identities for build and publish workflows.

Threat narrative

Attacker objective: The objective was to steal reusable credentials and use them to spread poisoned npm packages across the software supply chain.

1. Entry occurred when infected npm packages ran post-install scripts in developer and build environments, creating access to local secrets and pipeline context.
2. Credential harvesting followed as the worm searched for GitHub tokens, npm publish tokens, cloud credentials, and other exposed secrets in environment variables and files.
3. Escalation came when stolen credentials were reused to create attacker-controlled repositories and publish additional poisoned packages, expanding the infection path.
4. Impact was ecosystem-wide propagation across npm, developer systems, and CI/CD environments, with compromised secrets extending the blast radius beyond the initial package.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

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 secrets are a supply chain liability, not a convenience layer. The Shai-Hulud worm succeeded because reusable credentials were already embedded across build and developer environments. That means the security failure is not only compromise, but the decision to let non-human access persist in forms that can be copied and replayed. The practitioner implication is that any programme still depending on static publish tokens is preserving its own attack surface.

Rotation is a mitigation for exposure time, not a cure for credential architecture. This incident shows why rotating a secret after compromise still leaves the underlying trust model intact. A credential that can be stolen, reused, and republished is still a credential that carries standing privilege. Practitioners should read this as a governance problem in lifecycle design, not a tuning problem in rotation cadence.

Dynamic identity is the right control boundary for package publishing workflows. Once access is issued at runtime and scoped to the job, there is no durable secret for a worm to harvest and redeploy. That aligns with NHI governance principles that favor ephemeral access over persistent secrets. The practical conclusion is to move build and publish pipelines away from stored credentials and toward issuance-time controls.

Secrets sprawl creates identity blast radius across pipelines, repos, and logs. The article shows that one secret type rarely stays in one control plane. GitHub, npm, cloud, and observability credentials can all be exposed through the same compromise path, which is why the problem cannot be solved in a single tool or one team. The practitioner implication is to govern secrets as a cross-environment identity estate.

Ephemeral credential trust debt is the right name for this failure mode. The longer a static credential survives, the more systems it touches and the more places it can be replayed. That debt accumulates until a worm or attacker cashes it out at scale. The implication for identity programmes is straightforward: reduce the number of durable secrets before you worry about how often to rotate them.

From our research library:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• Read next: Guide to NHI Rotation Challenges

What this signals

Static secrets are now a governance debt item. The lesson from Shai-Hulud is that secrets do not merely need better handling, they need shorter lifetimes and narrower scope. Once static credentials are allowed to bridge developer machines, registries, and CI/CD, the control problem stops being rotation and becomes architectural.

Identity blast radius is the better programme metric. Security teams should measure how far one credential can travel across repos, pipelines, and cloud services before it is revoked. The smaller that blast radius, the less likely a package compromise becomes an ecosystem event.

For practitioners

• Eliminate long-lived npm publish tokens Replace durable publish credentials with runtime-issued identities that exist only for the publishing task and expire automatically when the job completes.
• Audit secret exposure across build paths Search package scripts, CI logs, environment variables, and developer workstations for reusable credentials that can be copied and replayed.
• Scope non-human access to single tasks Limit each workload credential to the exact repository, registry, and publish action it needs so compromise cannot be reused for lateral propagation.
• Treat rotation as a temporary control Use rotation to shorten exposure windows, but plan removal of the underlying static secret wherever the workflow still depends on standing privilege.
• Separate developer identity from automation identity Prevent human logins, bot credentials, and pipeline access from sharing the same trust path so one leaked secret does not bridge multiple environments.

Key takeaways

• Shai-Hulud showed that static secrets can turn a single package compromise into rapid supply chain propagation across npm and CI/CD environments.
• The worm's spread depended on reusable credentials that persisted in logs, repositories, and automation systems long enough to be stolen and replayed.
• The practical response is to reduce durable secrets, narrow access scope, and move publishing workflows toward ephemeral identity instead of relying on rotation alone.

Key terms

• Static Secret: A secret, such as an API key or password, that does not change automatically over time. Static secrets require manual or scheduled rotation and represent a higher security risk than dynamic secrets or managed identities.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Dynamic Ephemeral Identity: Dynamic Ephemeral Identity is a model in which credentials or authority exist only for a short operational window and are generated at runtime. It reduces the value of exposed secrets, but only if the environment can also limit what the identity is allowed to do while active.

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.