Shai-Hulud shows why standing credentials now drive supply-chain risk

At a glance

What this is: This is an analysis of the Shai-Hulud supply-chain attack, which shows how malware can turn static secrets on developer systems into broad access across build and deployment environments.

Why it matters: It matters because IAM, PAM, and NHI teams have to treat developer endpoints, CI/CD pipelines, and AI coding tools as credential-rich attack surfaces rather than passive tooling.

By the numbers:

• more than 400 infected packages, representing over two billion monthly installs, had been affected.
• 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.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read Akeyless's analysis of the Shai-Hulud supply-chain attack and secret exposure

Context

Shai-Hulud is a supply-chain attack that does not begin with a software vulnerability. It begins with a governance assumption that many identity programmes still make: long-lived secrets will remain hard to find, hard to reuse, and easy to contain once exposed. In practice, developer workstations, CI/CD runners, and AI-assisted coding tools often hold credentials that are both discoverable and immediately reusable.

That matters because the blast radius of a compromised secret is shaped by privilege scope, token lifetime, and where the credential can be replayed. The article is really about non-human identity exposure across build systems and developer tooling, with AI assistants now part of the same trust chain. That is typical of modern enterprise environments, not an outlier.

The deeper issue is that static credential handling creates a hidden dependency on endpoint hygiene that most IAM programmes never fully govern. Once the secret is on disk, the attacker no longer needs to defeat the application layer. They only need access to the identity artefact already sitting in front of them.

Key questions

Q: What breaks when static secrets are exposed on developer workstations?

A: Static secrets turn endpoint compromise into reusable access because the attacker can replay the same credentials outside the original session. That breaks the assumption that local credential storage is harmless if the application is not directly breached. Once the secret is copied, the real control problem is blast radius, not detection alone.

Q: Why do long-lived NHI credentials increase supply-chain risk?

A: They increase supply-chain risk because build systems, package installs, and developer tools can harvest and reuse them without a separate exploit chain. A long-lived credential stays useful long after the initial exposure, which means one compromise can extend into cloud, CI/CD, and secrets infrastructure.

Q: What do security teams get wrong about secret rotation?

A: They often treat rotation as a substitute for removing the underlying credential model. Rotation lowers exposure time, but it still leaves a secret to steal, bootstrap, and govern. If a workload can avoid holding the secret at all, that is a stronger control than simply changing it more often.

Q: How do organisations reduce blast radius in software delivery pipelines?

A: They reduce blast radius by limiting what each build identity can access, where it can connect, and how much trust it receives by default. The goal is to keep compromise or failure in one job from becoming a pipeline-wide or environment-wide incident.

Technical breakdown

Why static secrets become the easiest supply-chain target

Static secrets are reusable identity artefacts, so malware does not need to break encryption or bypass an application control if the credential is already present on disk. In this attack pattern, preinstall scripts, local file searches, and environment inspection are enough to locate .env files, cloud keys, kubeconfigs, and tokens. The problem is not only exposure. It is replayability. Once a bearer token or long-lived API key is copied, the attacker inherits the same access the legitimate workload had, often with no strong binding to device state, session context, or purpose.

Practical implication: treat every long-lived secret on endpoints and in CI/CD as reusable access, not as a passive configuration value.

How CI/CD and developer tooling extend the credential attack surface

Build runners, developer laptops, and repository hooks often share the same identity material. Shai-Hulud shows how malicious code can pivot from package installation into persistent tooling changes, then reuse whatever secrets are reachable in that workspace. That makes the pipeline an identity environment, not just a software delivery system. If tokens, cloud credentials, and vault access are available to the build context, the attacker can move from code execution to secret harvesting without ever touching the target application’s runtime.

Practical implication: scope CI/CD credentials to the narrowest job context and eliminate reusable secret material from workspace persistence.

Why AI coding assistants belong in secrets governance

AI coding assistants are now embedded in the same developer environments that store source code, tokens, and deployment credentials. The article shows that persistence hooks can be inserted into assistant or editor configuration files, turning a convenience layer into a recurring execution path. That does not make the assistant the root problem. The root problem is that the environment grants the assistant, and anything that compromises it, access to the same identity material as the human developer. Governance has to follow the credential path, not the UI boundary.

Practical implication: include AI-assisted development configurations in workstation persistence and secret-exposure reviews.

Threat narrative

Attacker objective: The attacker wants reusable identity material that unlocks package ecosystems, build systems, and downstream cloud or secrets infrastructure.

1. Entry occurs when the malicious package runs a preinstall script during normal npm installation and lands on developer or CI/CD systems that already contain credentials.
2. Escalation follows when the malware harvests long-lived tokens, cloud keys, kubeconfigs, and vault access, then reuses those secrets across reachable systems and secret stores.
3. Impact is broad secret compromise and persistent access, because stolen credentials can be replayed across development, build, and production-adjacent environments without needing another exploit.

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 credential trust is the real assumption collapse here. Secret handling was designed for environments where credentials remain discoverable but manageable, and where compromise can be limited by rotation after the fact. That assumption fails when the actor is malware operating inside developer workstations and CI/CD systems because the secret is already present, already valid, and already reusable. The implication is not simply to rotate faster. It is to recognise that the old model presumes a recoverable secret lifecycle that the attack path has already bypassed.

Credential blast radius now matters more than credential presence. Shai-Hulud demonstrates that one compromised machine can expose an entire secrets estate if tokens are shared, long-lived, or over-scoped. That is a governance failure in NHI management, not a tooling inconvenience. The relevant question for practitioners is no longer whether a secret exists, but how much damage that secret can cause before it expires or is rendered useless.

Identity blast radius: the useful unit of control is no longer the secret, but the amount of access one exposed credential can unlock across build, deployment, and AI-assisted development contexts. This is the control concept the article makes unavoidable. Static secrets on endpoints create a latent access graph that attackers can traverse with almost no additional effort. Practitioners should treat access scope, lifetime, and replayability as one control surface rather than separate hygiene tasks.

AI-assisted development expands the NHI governance boundary. Once coding assistants can read from or write to files that contain credentials, they inherit the same exposure profile as the developer session itself. That means the secrets programme now has to govern editor hooks, assistant configuration, and runtime access paths as part of the same identity chain. The implication is straightforward: AI tooling is not a side channel, it is a credential-bearing workload.

Runtime-issued access is the only practical answer to replayable secrets. The article reinforces a broader NHI pattern: if an identity can be copied from disk, it can be weaponised outside its original intent. Short-lived, workload-bound credentials reduce the window for reuse and force access to be contextual rather than static. Practitioners should reframe secrets management as access minimisation, not storage hardening.

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.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows why detection without revocation leaves standing access in place.
• For a broader view of the breach pattern, review the 52 NHI Breaches Analysis for repeated examples of stolen credentials becoming downstream access.

What this signals

Identity blast radius is becoming the decisive programme metric. When secrets can be copied from developer workstations, CI/CD runners, or AI-assisted tooling, the question is not whether leakage occurs but how far a single credential can travel before it expires or is revoked. Teams should map every high-value secret to the systems it can reach and remove the ones that can unlock multiple tiers of infrastructure.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, the governance problem is clearly structural rather than isolated. That scale means endpoint hygiene, repository scanning, and manual review cannot carry the full burden, so identity programmes need runtime-issued access, narrow scoping, and revocation workflows that match modern development speed.

The practical shift is to treat developer environments as identity-bearing systems. That means folding CI/CD, local tooling, and AI coding assistants into the same review and offboarding logic used for other non-human identities, while using the OWASP Non-Human Identity Top 10 as a control map for exposed credentials and overprivilege.

For practitioners

• Eliminate reusable secrets from developer endpoints Search workstations, repo hooks, and local config paths for .env files, cloud keys, kubeconfigs, tokens, and vault access material, then remove anything that can be replayed outside the original session.
• Convert CI/CD credentials to job-scoped runtime access Issue credentials only at execution time, bind them to the specific pipeline job, and prevent persistence in environment variables or shared runner state.
• Audit AI coding assistant persistence settings Review .claude, .vscode, and similar configuration files for hooks that can create repeated execution or secret exposure, and treat them as part of your workstation identity perimeter.
• Prioritise secret revocation by blast radius Rotate broadly when a developer or runner is suspected, starting with credentials that can reach multiple vaults, cloud accounts, or production-adjacent systems rather than only the immediately exposed secret.
• Shift from static secrets to workload identity Use identity-based authentication for services and pipelines so access is bound to workload context instead of copied bearer tokens and long-lived key files.

Key takeaways

• Shai-Hulud shows that supply-chain compromise can begin with static secrets already present on developer and CI/CD systems, not with an application exploit.
• The scale of hardcoded secret exposure remains high enough that one compromised machine can turn into broad, reusable access across build, cloud, and secrets infrastructure.
• Teams need shorter-lived credentials, tighter workload identity, and lower blast radius if they want their identity controls to survive modern supply-chain attacks.

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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• Secretless Authentication: Secretless authentication is a pattern that keeps long-lived credentials out of application code and runtime memory wherever possible. Instead of exposing secrets directly to workloads, the access path mediates credential delivery at connection time, reducing the chance that stolen configuration or code reveals reusable access.

What's in the full article

Akeyless's full article covers the operational detail this post intentionally leaves for the source:

• Detailed walkthrough of the package-infection chain and the credential locations targeted on endpoints and runners
• Specific examples of file paths, environment variables, and tooling artefacts used to locate secrets
• Operational guidance for moving from static secrets to runtime-issued access in developer and CI/CD workflows
• Product-specific examples of Multi-Vault Governance and Agentic Runtime Authority in action

👉 Akeyless's full post covers the attack path, exposed credential types, and response actions in more detail.

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 building or maturing an identity security programme, it is worth exploring.