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

At a glance

What this is: This analysis shows how the Shai-Hulud supply-chain attack used standing credentials on developer and CI/CD systems to widen impact without needing a software vulnerability.

Why it matters: It matters because IAM, NHI, and PAM teams now have to treat credential residence, lifetime, and reuse as supply-chain exposure points, not just access-control hygiene.

👉 Read Akeyless's analysis of Shai-Hulud and standing credential risk

Context

Shai-Hulud is a supply-chain attack in which malicious code spreads through trusted package workflows and then harvests whatever credentials are already present on developer and build systems. The central governance problem is not only package integrity, but the fact that long-lived secrets on endpoints and CI/CD runners are reachable by routine development activity.

For IAM and NHI programmes, the article shifts the focus from software defects to standing credential exposure. When credentials persist in .env files, tokens, vault client material, and AI-assisted development tools, attackers can turn ordinary build and install paths into reusable access without needing a traditional exploit chain.

Key questions

Q: What fails when package installs can read standing credentials?

A: The failure is credential residence, not package execution alone. If secrets are stored on disk, in environment variables, or in runner paths that installation scripts can reach, a malicious dependency can harvest them automatically and turn a routine install into a secrets-exposure event.

Q: Why do long-lived CI/CD or workstation secrets increase supply-chain risk?

A: They extend the useful lifetime of any secret that malware finds. Once a reusable token or key is copied, the attacker can replay it outside the original machine, which expands the blast radius from one infected system to the broader secrets and cloud estate.

Q: What are the signs that credentials are too easy to harvest in development environments?

A: Common signs include secrets in .env files, tokens in pipeline variables, SSH keys on workstations, and AI tool configurations that persist access across sessions. If ordinary install or editor workflows can reach those values, the exposure path is already too broad.

Q: How should teams respond when a package or maintainer account is compromised?

A: Assume any reachable credentials may be exposed, then rotate broadly across vaults, cloud secret managers, and developer tooling. The response should prioritise the credentials that could unlock other secrets, not just the first token named in the incident report.

Technical breakdown

Malicious preinstall scripts turn package installs into credential harvesters

Shai-Hulud uses package installation as the execution point. A malicious preinstall script runs automatically when the dependency is installed, which means the attacker does not need an interactive foothold first. The malware then scans the local filesystem with broad pattern matching to find secrets in .env files, AWS credentials, SSH private keys, Kubernetes kubeconfigs, Terraform state files, GitHub tokens, and other developer artefacts. This is supply-chain abuse through trusted automation, not a vulnerability in the target application stack. The real advantage comes from security teams assuming install-time code is low risk while credential material remains scattered across the workstation and pipeline.

Practical implication: Treat dependency install paths as secret-discovery surfaces and remove credentials from locations that routine build and install activity can read.

Why Vault tokens and cloud secrets become high-value standing credentials

The article shows the malware specifically looking for HashiCorp Vault tokens, AWS Secrets Manager material, and Kubernetes secrets. That matters because a single bearer token can provide access far beyond the original machine, especially when it is stored on disk or exposed through environment variables. This is the standing-privilege problem in NHI terms: one credential can unlock an entire secrets estate if it is reusable and not tied tightly to session, workload, or context. The attack does not break Vault or cloud secret managers themselves. It abuses the fact that long-lived access material often sits close enough to endpoints for commodity malware to collect and replay it.

Practical implication: Move high-value secrets behind identity-bound, short-lived issuance paths instead of leaving bearer tokens on endpoints or in CI/CD variables.

AI coding environments extend the secret exposure window

Shai-Hulud also persists by modifying AI-assisted development tooling such as .claude/settings.json and .vscode/tasks.json. That persistence mechanism is important because it blends developer workflow, assistant configuration, and identity exposure into the same execution environment. When AI coding tools can access repository context or production-linked credentials, they become part of the identity surface rather than a neutral productivity layer. The attack does not require the AI system to be autonomous. It only needs the environment to keep reusable credentials available long enough for the malware to capture and reuse them. That makes AI-assisted development another place where secret residency, not just code quality, defines risk.

Practical implication: Review AI tool configuration, persisted hooks, and workspace-level credential exposure as part of the same control scope as developer workstation hardening.

Threat narrative

Attacker objective: The attacker wants reusable credentials that expand one package compromise into wider access across developer, CI/CD, and cloud environments.

1. Entry occurs when attackers compromise a maintainer GitHub account and distribute a malicious npm package with a preinstall script.
2. Credential harvesting follows as the malware scans developer machines and CI/CD runners for .env files, cloud keys, Vault tokens, SSH keys, and other reusable secrets.
3. Escalation and lateral movement occur when stolen credentials are replayed against secret stores, cloud environments, and developer tooling.
4. Impact is broader package compromise, persistent access, and exposure of secrets that can be reused across environments.

Breaches seen in the wild

• 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).
• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing credentials have become the supply-chain control point: this attack worked because secrets remained reachable on endpoints and build systems long after they should have been ephemeral. That is not a tooling flaw alone. It is a governance failure in how organisations decide where credentials may live, how long they may persist, and which runtime contexts can read them. Practitioners should treat secret residence as a supply-chain risk variable, not a back-office storage detail.

Shai-Hulud exposes identity blast radius as the real security metric: the malware did not need to compromise the entire software lifecycle to succeed. It needed only one reusable credential with enough scope to unlock more secrets, more tooling, or more infrastructure. Blast radius now matters more than the mere presence of centralised secret storage, because one exposed bearer token can collapse compartmentalisation across systems.

Static secret assumptions are now out of step with modern development workflows: access review, vaulting, and rotation all presuppose that a credential persists long enough to be governed after issuance. Malware that harvests secrets from package installs, workstations, and AI-assisted sessions turns that assumption into a weakness. The implication is that governance has to move toward issuance-time control and away from post-hoc review of credentials that should not have been reusable in the first place.

AI-assisted development is now part of NHI governance, not a separate productivity issue: the article shows that tools like coding assistants become persistence surfaces when they can store or retrieve secrets. That creates a shared problem for IAM, NHI, and developer platform teams. If an assistant can read a token, it is in the same trust boundary as any other credential-bearing workload and must be governed accordingly.

Ephemeral credential trust debt: organisations that still rely on long-lived secrets accumulate hidden exposure each time a new workflow, runner, or assistant is allowed to store a reusable credential. The debt is paid when attackers turn that credential into lateral movement, secret enumeration, or persistence. Practitioners should read the attack as proof that secret lifetime is now a structural risk measure.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Standing credentials now behave like hidden supply-chain debt: every new runner, workstation, or assistant that can store a reusable secret expands the attack surface before any incident occurs.

Ephemeral credential trust debt: the organisation does not see the full cost of static secrets until a package install, AI session, or build hook turns them into a live intrusion path. That is why secret lifetime has to be governed as an operational risk, not a storage preference. Use of short-lived issuance and secretless access changes the economics of compromise, because there is less reusable material for malware to collect.

For practitioners

• Remove standing secrets from developer workstations Move long-lived credentials out of .env files, local config, and other disk locations that routine package installs can scan. Use identity-bound access paths for anything that must still be reachable during development.
• Issue runtime-scoped credentials for CI/CD jobs Replace reusable pipeline tokens with credentials fetched at execution time and limited to the job that needs them. Treat CI runners as high-risk credential consumers, not trusted storage.
• Inventory AI assistant persistence mechanisms Review .claude settings, VS Code task files, and similar workspace hooks for stored tokens, cached access, or automatic execution paths that can outlive a session.
• Rotate exposed secrets across the full estate After a package or workstation compromise, rotate credentials broadly across vaults, cloud secret managers, and developer tooling because the attacker may have copied more than the initially suspected token.
• Reduce standing privilege before the next package compromise Use short-lived credentials, identity-based authentication, and secretless patterns so a stolen secret cannot unlock a wider secrets estate or a persistent workload path.

Key takeaways

• The attack shows that supply-chain compromise can start with ordinary credential exposure, not with a software vulnerability in the target application.
• Its impact depends on how much reusable access remains on developer systems, CI/CD runners, and AI-assisted tooling.
• Reducing standing privilege and secret lifetime is the control that shrinks the blast radius when the next package compromise arrives.

Key terms

• Standing Credential: A standing credential is any secret that remains usable until it is manually rotated or revoked. In NHI governance, it creates durable access that can be stolen, replayed, or propagated from trusted tooling unless runtime boundaries and expiry are built in.
• 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.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.

What's in the full article

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

• Specific examples of the credential locations the malware searched, including workstation files and CI/CD paths
• The article's step-by-step recommendations for reducing standing credentials across developer and pipeline environments
• Details on how the malware persisted through AI assistant and editor configuration changes
• A closer look at the zero-knowledge and distributed-fragment architecture claims in the source article

👉 Akeyless's full article covers the package compromise, secrets-harvesting paths, and mitigation steps 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 IAM programme, it is worth exploring.