Notifications
Clear all
Topic starter
11/08/2026 3:11 pm
TL;DR: Shai-Hulud spread through npm packages by harvesting long-lived credentials from developer workstations, CI/CD runners, and AI-assisted coding environments, affecting more than 400 infected packages and over two billion monthly installs according to Akeyless. The attack shows that static secrets, not software flaws, are now the easier supply-chain target, and blast-radius reduction has become the real control objective.
NHIMG editorial — based on content published by Akeyless covering the Shai-Hulud supply-chain attack: an analysis of credential harvesting through developer and CI/CD environments
By the numbers:
- more than 400 infected packages, representing over two billion monthly installs, had been affected.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
Questions worth separating out
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.
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.
Q: What do security teams get wrong about secret rotation?
A: They often treat rotation as a substitute for removing the underlying credential model.
Practitioner guidance
- 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.
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
👉 Read Akeyless's analysis of the Shai-Hulud supply-chain attack and secret exposure →
Shai-Hulud and standing credentials: what should IAM teams change?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
11/08/2026 3:26 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Shai-Hulud shows why standing credentials now drive supply-chain risk
