Shai-Hulud showed why attackers target NHI power first

At a glance

What this is: This is an analysis of the Shai-Hulud worm and its focus on non-human identities, showing that attackers went after automation credentials first because they carried deployment and infrastructure power.

Why it matters: It matters because IAM, PAM and software supply chain teams need to treat CI/CD tokens, GitHub PATs and cloud keys as high-value identities with lifecycle controls, not as incidental secrets.

Context

Shai-Hulud is best understood as an NHI governance problem, not just a supply chain incident. The worm succeeded because automation credentials, publish tokens and cloud keys were already embedded in development and delivery workflows with more privilege than most teams actively track.

The core failure was not that secrets existed. It was that machine identities had accumulated enough authority to publish packages, access private repositories and operate infrastructure, while visibility into where those identities lived remained incomplete. That makes the attack a direct warning for NHI programmes, CI/CD governance and identity lifecycle control.

Key questions

Q: What breaks when CI/CD workflow actions or build credentials are tampered with?

A: A poisoned workflow action can turn trusted automation into a credential-exfiltration path, especially when runners hold deployment tokens, cloud keys, or signing material. The break point is not just the build itself. It is the assumption that a pinned dependency or reusable action is stable. Teams should treat build systems as high-trust NHI environments and verify provenance continuously.

Q: Why do automation tokens and GitHub PATs create such a large compromise window?

A: They create a large compromise window because they often outlive the task that created them and carry privileges broad enough to deploy, publish and access private assets. When those credentials are not tied to narrow lifecycle controls, a single theft can become both lateral movement and replication across the software delivery chain.

Q: What are the signs that machine identity sprawl is becoming a supply chain risk?

A: Look for secrets stored outside a vault, repeated use of the same token across runners and repositories, and identities that can publish, deploy or read from multiple environments. Those signals show that the NHI estate has grown faster than governance, which is exactly the condition attackers exploit in CI/CD compromise campaigns.

Q: How should teams limit the damage if a publish token or cloud key is stolen?

A: Constrain the identity so it cannot both publish artefacts and reach infrastructure, and separate repository access from deployment rights wherever possible. The goal is to keep one compromised secret from becoming a cross-environment foothold, especially in pipelines where trust is inherited through automation.

Technical breakdown

Why automation credentials become the first target

Shai-Hulud moved straight to CI/CD runner tokens, GitHub PATs and cloud access keys because those credentials are the shortest route to durable operational power. In practical terms, they behave like privileged service accounts even when teams store them as environment variables, local configs or build logs. Once harvested, they can authenticate to package registries, source control and cloud control planes without triggering the human authentication flows defenders watch most closely. The worm did not need password theft or interactive compromise. It only needed machine identities with enough scope to publish, enumerate and pivot.

Practical implication: treat automation credentials as production identities and govern them with the same care as privileged accounts.

How secret sprawl turns build systems into attack surfaces

The article shows TruffleHog searching git histories, CI caches and artifact directories, which is a reminder that secret exposure is often a lifecycle problem, not a point-in-time leak. CI/CD systems preserve tokens in places defenders forget to inventory, and those stored artefacts can outlive the intended rotation window by months or years. When credentials are reused across runners, repositories and cloud platforms, a single exposure creates a broad trust boundary. The attack worked because those hidden secrets were still valid and still powerful.

Practical implication: inventory where secrets persist across development and build artefacts, then remove storage locations that extend credential lifetime.

Why NHI privilege graphs determine worm propagation

Propagation in this case followed the permissions attached to the compromised identity. The worm enumerated what the stolen NHI could publish and then used that privilege graph to spread through packages and workflows. That is different from exploiting a software flaw, because the attacker is not breaking a control boundary so much as using the legitimate authorisation graph already present in the environment. In NHI terms, the question is not only whether a credential is valid, but what actions its grants make reachable at scale.

Practical implication: map every high-value NHI to the actions it can reach, then reduce the publish, deploy and read scopes that enable lateral movement.

Threat narrative

Attacker objective: The attacker’s objective was to use stolen machine identities to propagate through trusted software delivery paths and gain operational control over packages, repositories and cloud infrastructure.

1. Entry occurred through exposed automation credentials found in environment variables, local configs, CI caches and build logs.
2. Credential access expanded when the worm harvested GitHub PATs, npm publish tokens and cloud keys with deploy and repository privileges.
3. Escalation followed as stolen NHIs were used to republish more than twenty packages and reach private repositories and workflows.
4. Impact was production-adjacent replication across software supply chain assets, with infrastructure-level permissions available through AWS, GCP and Azure keys.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

NHI privilege concentration is now the primary supply chain risk: Shai-Hulud showed that the fastest path into a modern software estate is through the machine identities that already hold publish and deploy authority. That matters because many organisations still model supply chain risk as code integrity first and identity second. In practice, the identity layer is what gives attackers the ability to turn code access into infrastructure reach.

Secret sprawl is a lifecycle failure, not just a leakage event: The worm found credentials in build logs, CI caches, local configs and git history because those artefacts still existed and still authenticated. That is a governance failure over retention, rotation and revocation, not a single exposed token. The implication is that NHI lifecycle control has to extend into developer tooling, not stop at vault policy.

Package publication is an identity authorization problem: Once a stolen identity can publish packages or trigger workflows, the attacker has a legitimate path to distribute malicious artefacts under trusted channels. That is why software supply chain defence must include entitlement design for non-human publishers, not only scanning for vulnerable code. The practitioner conclusion is to constrain who and what can publish at all.

Identity blast radius should replace credential counting as the governing concept: Shai-Hulud did not need the most secrets, only the right secrets with the widest downstream reach. Identity blast radius: the practical scope of damage a single non-human identity can create across repositories, pipelines and cloud accounts. Teams should measure that reach directly, because quantity alone does not describe risk.

CI/CD has become a privileged identity domain: Build and delivery systems now hold the same operational weight as administrative consoles, but they are often governed with far less scrutiny. That asymmetry is what makes them attractive to attackers and fragile for defenders. The field should stop treating pipeline credentials as supporting artefacts and start treating them as first-class identities.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Identity blast radius: the key metric for this kind of attack is not how many secrets exist, but how much downstream power each secret carries. When a single machine identity can publish packages, read private repositories and trigger deployments, the governance problem is scope, not storage.

The practical response is to move NHI controls closer to where build systems operate. That means governing credential lifetime, reducing inherited permissions in CI/CD and mapping non-human identities to the operational paths they can actually reach.

For practitioners

• Inventory high-power automation credentials Map CI/CD tokens, GitHub PATs, cloud keys and publish tokens to the systems and privileges they unlock, then flag any identity that can deploy, publish or reach private repositories.
• Remove secrets from persistent build artefacts Search git history, CI caches, artifact directories and developer endpoints for valid credentials, then eliminate storage paths that let secrets survive beyond intended rotation.
• Reduce publish and workflow scopes Trim package publication rights, repository read access and workflow execution permissions so a single compromised identity cannot both spread and operate across the delivery chain.
• Measure identity blast radius Assess how far each machine identity can move across repositories, runners and cloud accounts, and prioritise the credentials whose authorization graph spans multiple environments.

Key takeaways

• Shai-Hulud demonstrated that attackers will go straight for the machine identities that already control publish, deploy and cloud access paths.
• The attack is consistent with the broader NHI problem: a single automation credential can unlock repository access, package republishing and infrastructure reach.
• Defenders need to shrink NHI blast radius by reducing token scope, removing stale secrets from build artefacts and tightening lifecycle governance around CI/CD identities.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.
• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
• Software supply chain identity: Software supply chain identity is the set of identities used to prove who or what created, changed, signed, built, or delivered software. It includes human and non-human identities across code, build systems, repositories, package registries, and deployment pipelines, enabling traceability, authorization, and trust decisions throughout the software lifecycle.

Deepen your knowledge

NHI governance, machine identity security, and secrets management 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.