Shai-Hulud showed why attackers target NHI power first

At a glance

What this is: This is an analysis of how Shai-Hulud used compromised non-human identities to move through software delivery environments and infrastructure.

Why it matters: It matters because IAM, PAM, and NHI governance teams have to treat CI/CD tokens, build credentials, and cloud keys as production-grade identities with real blast radius.

👉 Read Hush Security's analysis of Shai-Hulud and NHI exposure

Context

Shai-Hulud is a software supply chain attack that exposed a simple reality: attackers do not need human credentials when machine identities already carry deployment and infrastructure authority. In environments built on CI/CD, package publishing, and cloud automation, the security question is not whether secrets exist, but whether anyone can see, govern, and retire them before they are abused.

The governance gap is bigger than secret sprawl. CI/CD runner tokens, GitHub PATs, cloud keys, and build-time credentials often sit outside the lifecycle controls teams apply to human access, which means they can persist after the job, the repository, or the integration has changed. That makes NHI governance a software supply chain control, not just a vaulting problem.

Key questions

Q: What breaks when automation credentials are not governed like production identities?

A: Attackers can reuse the same tokens and keys that release pipelines trust, which turns a local compromise into publishing, deployment, or cloud access. The failure is not just exposure. It is that machine identities often retain authority after the original task changes, so the attacker inherits real operational power. Governance must treat these credentials as production access, not convenience secrets.

Q: Why do non-human identities increase supply chain risk in CI/CD environments?

A: Because CI/CD identities often connect code, package publication, and cloud infrastructure through one trust chain. If a runner token, PAT, or key is exposed, the attacker can move from one control plane to another without touching a human login. That makes NHI lifecycle, scoping, and revocation central to supply chain defence.

Q: How do security teams know whether machine identity governance is actually working?

A: They should be able to answer three questions quickly: who owns each credential, what system it protects, and when it expires or rotates. If the team cannot trace a token from issuance to retirement, governance is incomplete. Strong programmes also show that logs, caches, and repositories are searched for exposure, not just the vault.

Q: How should organisations respond when exposed secrets are found in build systems?

A: Rotate the affected credentials immediately, remove any duplicated copies from pipelines and caches, and review whether the credential had publish or infrastructure privileges. Then assess whether the identity lived beyond its business purpose. The goal is containment plus lifecycle correction, not just remediation of the single leak.

Technical breakdown

How Shai-Hulud used automation credentials to gain reach

The worm first searched for the identities that make software delivery work: environment variables, local configs, runner tokens, and build logs. Those locations are attractive because they are designed for machine access, not human review. Once a token or key is exposed, the attacker inherits whatever trust the pipeline, repository, or cloud account already granted. That means the abuse path is rarely a single vault break. It is often a chain of ordinary CI/CD permissions that were never scoped tightly enough for republishing, deployment, or API access.

Practical implication: inventory every credential source in build and release systems, not just secrets stores.

Why package publishing tokens create outsized blast radius

A publish token is a high-value NHI because it can turn code access into distribution access. In package ecosystems, one stolen token can alter what downstream developers install, which makes the identity behind the token a supply chain control point. The technical risk is not only exfiltration. It is impersonation of trusted software flow, where the attacker uses a legitimate publishing path to insert malicious or altered packages without needing to compromise the maintainers' human accounts.

Practical implication: bind package publishing to short-lived, tightly scoped credentials and separate publication rights from routine development access.

How cloud keys extend compromise from development to infrastructure

Cloud access keys from AWS, GCP, and Azure turn a build-system incident into infrastructure-level exposure because they often inherit broad API permissions. When those keys are embedded in developer machines, logs, or caches, they become durable machine identities with no clear human owner in the moment of abuse. That is why NHI compromise so often outlives the original infection point. The attacker is no longer inside a single application. They are operating through the same identity plane used to deploy, configure, and scale production resources.

Practical implication: enforce owner mapping, expiry, and scope review for every cloud credential that can reach production.

Threat narrative

Attacker objective: The objective was to convert exposed machine identities into distribution power and infrastructure reach without needing human credentials.

1. Entry occurred when the worm harvested CI/CD runner tokens, GitHub PATs, and cloud keys from environment variables, local configs, build logs, and developer machines.
2. Escalation followed when those credentials were used to access private repositories, enumerate publish rights, and reuse infrastructure permissions already attached to machine identities.
3. Impact came when the attacker republished more than twenty packages in one hop and expanded the compromise into software distribution and cloud access.

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

NHI governance is now a software supply chain control, not a vaulting side issue. Shai-Hulud made the attacker priority obvious: machine identities came first because they carried the authority to publish, deploy, and reach infrastructure. That is a governance problem spanning CI/CD, developer tooling, and cloud access, not just secret storage. Practitioners should treat every publishing and build credential as part of the production trust boundary.

Privilege graphs matter more than credential count when a worm can reuse what the pipeline already trusts. The attack did not need sophisticated exploitation when ordinary automation rights already formed a lateral movement path. That is why over-permissioned NHIs are so dangerous: they let compromise travel through legitimate workflows rather than noisy admin channels. Teams should re-evaluate how machine identity permissions map to actual software release authority.

Standing access for automation creates an identity blast radius that defenders rarely measure. NHIs are often created for convenience and then left in place long after the job changes. The result is access that outlives the business need and becomes available to attackers at exactly the wrong moment. Practitioners should make blast-radius reduction the organising principle for machine identity governance.

Token lifecycle failure is the specific control gap this attack exposed. The identities Shai-Hulud abused were designed for automated execution, but the lifecycle around them was not designed for rapid discovery, rotation, and retirement. That gap is visible in the persistence of runner tokens, PATs, and cloud keys across build caches and logs. The implication is that lifecycle governance for NHIs has to become operationally continuous, not periodic.

Software engineering teams and IAM teams are now responsible for the same identity plane. Package publishing, CI/CD, and cloud access are not separate security problems when the same secrets underpin all three. That convergence means governance must join application delivery, secrets management, and identity lifecycle into one control model. Practitioners should stop treating supply chain compromise as an application-only issue.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%).
• If you are building lifecycle governance for machine identities, start with Ultimate Guide to NHIs for the control model and then use 52 NHI Breaches Analysis to pressure-test the failure modes.

What this signals

Ephemeral privilege is the wrong mental model for many CI/CD identities. In practice, build and publish credentials often live long enough to be reused, copied, or cached, which means their risk profile looks much closer to standing access than to true just-in-time access. Teams that assume otherwise will underestimate how fast an exposed token can become a supply chain foothold.

Secret discovery has to expand beyond vaults. The real exposure surface includes git history, build caches, artifact directories, developer laptops, and logging pipelines. If those places are not covered by your discovery and rotation process, your programme will continue to miss the credentials attackers target first.

With 1.5 out of 10 organisations highly confident in securing NHIs, according to The State of Non-Human Identity Security, the gap is not a tooling preference. It is a governance maturity problem that cuts across IAM, DevOps, and cloud operations.

For practitioners

• Map every automation credential to an owner and a purpose Create an inventory of CI/CD runner tokens, GitHub PATs, cloud keys, and package publishing credentials, then tie each one to a named service, repository, or pipeline stage. Remove credentials that cannot be linked to an active business function.
• Separate publishing rights from routine developer access Restrict package publication to a small, monitored set of identities and use short-lived credentials where the platform allows it. Keep publication permissions out of everyday build and test accounts.
• Search build logs, caches, and developer machines for exposed secrets Treat git history, CI caches, artifact directories, and local config files as first-class secret locations. Run targeted discovery against those paths and rotate any credentials found there immediately.
• Enforce expiry and rotation on cloud credentials that can reach production Set hard expiry windows for AWS, GCP, and Azure access keys, then verify that rotation actually removes old credentials from downstream workflows and cached artefacts.

Key takeaways

• Shai-Hulud showed that attackers prioritise non-human identities because those credentials already control deployment, publishing, and cloud reach.
• The scale of the risk is defined by privilege, not by the number of secrets alone, because one exposed machine identity can unlock multiple operational paths.
• The right defence is lifecycle governance for automation credentials, including owner mapping, expiry, rotation, and discovery outside the vault.

Key terms

• Non-Human Identity: A non-human identity is a credentialed machine or software actor such as a service account, API key, token, certificate, or workload identity. In practice, it is an access-bearing identity that can deploy, publish, call APIs, or reach cloud resources without a person signing in each time.
• CI/CD Runner Token: A CI/CD runner token is a machine credential used to register, authenticate, or control a build runner inside an automated delivery pipeline. It often carries enough authority to trigger jobs, access repositories, or move artifacts, which makes exposure in logs, configs, or environment variables highly sensitive.
• Package Publishing Credential: A package publishing credential is the identity used to push software packages into an ecosystem registry. It is operationally powerful because it can change what downstream developers install, so compromise of that credential can turn trusted distribution into an attack vector.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and operational flow that an identity can affect if it is misused or stolen. For machine identities, the blast radius depends on scopes, environment reach, and whether the credential can be reused across pipelines or cloud accounts.

Deepen your knowledge

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

This post draws on content published by Hush Security: Shai-Hulud proved it: attackers hunt NHIs first, because that's where the power is. Read the original.