By NHI Mgmt Group Editorial TeamPublished 2025-09-17Domain: Workload IdentitySource: Defakto Security

TL;DR: Shai-Hulud spread through the npm ecosystem by harvesting static secrets, republishing poisoned packages, and using stolen credentials to extend the compromise across developer and CI/CD environments, according to Defakto Security. The incident reinforces that rotation alone cannot fix standing privilege when credentials persist across pipelines, logs, and repos.


At a glance

What this is: This is an analysis of the Shai-Hulud npm supply chain worm and its core finding that static secrets enabled rapid propagation across packages, repos, and automation systems.

Why it matters: It matters because IAM and NHI teams cannot treat credential rotation as a complete control when long-lived secrets still create standing privilege in build and deployment paths.

By the numbers:

👉 Read Defakto Security's analysis of the Shai-Hulud npm supply chain attack


Context

Shai-Hulud is a supply chain worm that spread through npm packages by stealing whatever credentials were already present in developer and CI/CD environments. The primary security problem is not malware novelty, but the persistence of non-human identity credentials that can be reused, republished, and leveraged for propagation.

For IAM and NHI practitioners, the lesson is straightforward: long-lived secrets create standing privilege in places where controls are often weakest, including build runners, developer laptops, and package publishing workflows. The article’s starting point is typical of modern software supply chain risk because the same credential patterns appear across many enterprises, not just in one ecosystem.


Key questions

Q: How should security teams reduce the risk of secret theft in CI/CD pipelines?

A: Security teams should remove persistent credentials from pipelines wherever possible, then narrow any remaining tokens to one task, one repository, and one environment. They should also scan logs, build artefacts, and collaboration tools for exposed secrets. The right goal is not faster recovery from theft, but making stolen material materially less useful.

Q: When is key rotation not enough for NHI governance?

A: Key rotation is not enough when the organisation still depends on long-lived tokens, broad permissions, and manual processes to keep systems running. In that case, rotation only shortens exposure time while preserving the same trust model. Practitioners should move toward ephemeral identity and automatic expiry for high-risk automation.

Q: What is the difference between secret rotation and ephemeral identity?

A: Secret rotation replaces one persistent credential with another on a schedule, while ephemeral identity removes the persistent credential from the workflow altogether. Rotation manages exposure after a secret exists. Ephemeral identity reduces the attack surface by issuing short-lived, task-scoped authority only when it is actually needed.

Q: Why do npm supply chain attacks expose broader NHI risk?

A: npm attacks expose broader NHI risk because package publishing, build automation, and dependency installation all depend on non-human identities with authority to act. If those credentials are static or overprivileged, a compromise can spread beyond one package into registries, repos, and cloud environments. That makes NHI governance a supply chain issue, not just an access review issue.


Technical breakdown

How static secrets turn a package compromise into propagation

Shai-Hulud did not need a zero-day to spread. The worm used post-install scripts to search for environment variables, cloud metadata credentials, npm publish tokens, and GitHub tokens, then reused those secrets to publish additional poisoned packages. This is the key failure mode of static secrets: once exposed, they are portable authority. A token in a log, repo, or runner can become a full chain of compromise because it carries standing access outside the original context. In NHI terms, the issue is not just exposure but reusability across systems.

Practical implication: Treat every persistent token as a potential propagation mechanism, not only an authentication artifact.

Why key rotation reduces exposure time but not trust debt

Rotation is a time-bound mitigation, not a structural fix. It shortens the useful life of a compromised secret, but it does not remove the underlying assumption that credentials must exist in storage, be discoverable by workflows, and be maintained by humans. When organisations rotate poorly, they also create outages, drift, and blind spots that attackers can exploit. For NHI governance, this is trust debt: the system keeps borrowing security from process discipline instead of eliminating the credential class that creates the risk.

Practical implication: Use rotation as an interim control, but plan to remove persistent secrets from high-risk automation paths.

Dynamic identity and JIT issuance for CI/CD workloads

The alternative is not a better secret manager alone. Dynamic identity means issuing short-lived, task-scoped credentials at runtime, then letting them expire automatically when the job completes. That model reduces what an attacker can steal and limits what any single workload can do if compromised. In practice, this aligns with just-in-time access, ephemeral workload identity, and tighter policy scoping for pipelines, package publishing, and automation. The architectural shift matters because it removes the durable object that worms like Shai-Hulud depend on.

Practical implication: Move publishing, build, and release systems toward ephemeral identities with narrow scopes and automatic expiry.


Threat narrative

Attacker objective: The attacker’s objective was to turn one compromised package into a self-propagating supply chain worm that harvested more credentials and widened exposure across development ecosystems.

  1. Entry via malicious post-install scripts in infected npm packages that searched local and pipeline environments for secrets.
  2. Escalation through reused GitHub tokens, npm publish tokens, and cloud credentials that granted standing access beyond the initial package compromise.
  3. Impact through republishing poisoned packages and exposing stolen secrets in attacker-controlled repositories and workflow logs.

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 now a propagation risk, not just an exposure risk. The important shift in this incident is that stolen credentials were not only used for access, they were used to spread the worm itself. That makes secret sprawl a supply chain multiplier rather than a local hygiene issue. Security teams should treat any reusable credential in build and publishing workflows as a potential propagation vector.

Key rotation is an incomplete control when standing privilege remains intact. Rotation shortens attacker dwell time, but it still leaves the enterprise dependent on long-lived credential objects and human process. That is operationally expensive and strategically weak. Practitioners should interpret this as evidence that rotation belongs in a transition plan, not as the endpoint of NHI governance.

Ephemeral identity is becoming the practical control model for modern pipelines. Static publish tokens and hardcoded secrets are misaligned with how software now moves through CI/CD, package registries, and automation. A dynamic identity model that issues scoped credentials at runtime is the cleaner fit for NHI governance because it changes what can be stolen. Teams should prioritise elimination of persistent secrets in the highest blast-radius environments.

Supply chain worms expose the gap between authentication and authorisation. A credential can authenticate a workload while still authorising far too much. In this case, broad token permissions turned a single compromise into multi-environment exposure. The governance lesson is that NHI programmes need task-scoped authority, not just better secret storage.

Static-secret elimination should be treated as a resilience control. This is not only a detection problem or a secrets management problem. It is a resilience problem because every persistent secret creates an avoidable recovery burden after compromise. Organisations that keep relying on permanent credentials are choosing repeated containment work over structural reduction in attack surface.

From our research:

  • 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, 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.
  • That pattern aligns with the broader NHI governance gap described in the Guide to the Secret Sprawl Challenge, where secret proliferation outpaces revocation discipline.

What this signals

Ephemeral credential trust debt: the longer organisations rely on persistent tokens in build and release paths, the more operational debt they accumulate when an incident forces revocation. That debt shows up as outages, manual cleanup, and uncertainty about where secrets were copied. Teams should treat token elimination as a resilience programme, not a tooling preference.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, the scale of secret exposure is no longer an edge case. That figure, from The State of Secrets Sprawl 2026, tells practitioners that the control problem is systemic and that static credential removal has to move into standard engineering practice. The next step is to align this with OWASP Non-Human Identity Top 10 guidance on secret sprawl and overprivilege.


For practitioners

  • Implement ephemeral credentials for build and publish workflows Replace long-lived npm, GitHub, and cloud tokens with runtime-issued identities that expire when the job completes. Prioritise package release pipelines, CI runners, and automation accounts where secret reuse would create the widest blast radius.
  • Audit developer and CI/CD environments for secret leakage paths Scan environment variables, workflow logs, repo history, issue trackers, and chat tools for tokens that can be replayed. The goal is to remove hidden copies before an attacker can harvest them from common collaboration surfaces.
  • Restrict token scope to one task and one system Reduce every remaining credential to the minimum permissions needed for a single publishing or deployment action. Narrow scopes make stolen secrets less useful and help contain compromise when a secret does leak.
  • Build offboarding and revocation into NHI lifecycle controls Automate revocation when a token is no longer needed, including former employee tokens and stale automation accounts. Lifecycle enforcement matters because unused credentials still become attack material in supply chain incidents.

Key takeaways

  • Shai-Hulud demonstrates that static secrets can be weaponised as propagation fuel inside software supply chains.
  • Rotation helps limit exposure, but it does not solve the standing privilege created by durable non-human credentials.
  • Practitioners should prioritise ephemeral identity, scope reduction, and lifecycle revocation in the highest-risk automation paths.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Secret rotation and exposure are central to the Shai-Hulud attack path.
NIST CSF 2.0PR.AC-4Overprivileged tokens violate least-privilege access expectations.
NIST Zero Trust (SP 800-207)Dynamic identity and continuous verification align with zero trust for automation.

Remove persistent secrets from pipelines and automate revocation where rotation still remains.


Key terms

  • Static Secret: A static secret is a long-lived credential such as a token, key, or certificate that remains valid until someone revokes or rotates it. In NHI programmes, static secrets are high-risk because they can be copied, reused, and embedded into automation paths that are difficult to audit.
  • Ephemeral Identity: Ephemeral identity is a short-lived credential model where authority is issued only when a workload runs and expires automatically when the task ends. It reduces standing privilege, limits replay value, and fits modern CI/CD and agentic workflows better than permanent secrets.
  • Standing Privilege: Standing privilege is access that remains continuously available instead of being granted only when needed. For non-human identities, it becomes dangerous when tokens or service accounts stay valid across jobs, systems, or time periods, giving attackers reusable authority after a single compromise.
  • Supply Chain Worm: A supply chain worm is malware that uses one compromise to propagate into adjacent packages, repositories, or automation systems. In identity terms, it becomes far more dangerous when it can harvest and replay secrets that let it publish, move, or persist without further exploitation.

Deepen your knowledge

Static secrets, secret rotation, and ephemeral identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to move from credential cleanup to structural reduction in supply chain risk, it is worth exploring.

This post draws on content published by Defakto Security covering the Shai-Hulud npm supply chain attack: Shai-Hulud: Why the Future of Security Means Leaving Key Rotation Behind. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-09-17.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org