Supply chain attacks expose the real blast radius of NHI sprawl

At a glance

What this is: This analysis shows how a supply-chain compromise became a large-scale breach because non-human identity access outlived the initial incident and expanded the blast radius.

Why it matters: IAM, PAM, and NHI teams need to treat leaked secrets as identity problems because incomplete revocation, hidden dependencies, and stale credentials can turn one compromise into many.

By the numbers:

• LiteLLM was present in ~36% of cloud environments during the campaign.
• Within days, the campaign expanded to 47 npm packages.

👉 Read Oasis Security's analysis of supply chain attacks and NHI sprawl

Context

Supply chain attacks become far more damaging when non-human identities are left with residual access after the first compromise. In this case, the initial entry point was a misconfigured GitHub Actions workflow, but the lasting problem was that credentials were not fully revoked and the surviving access paths kept working.

For IAM and NHI programmes, the lesson is simple: rotation without inventory, dependency mapping, and verification does not close the incident. It leaves organisations with unresolved identity exposure that can be reused days or weeks later, which is a common failure pattern in modern software supply chains.

Key questions

Q: What breaks when a leaked NHI credential is rotated but not fully revoked?

A: The original access path can remain usable if any downstream system still trusts the old secret, cached token, or surviving service account. That means the breach is only partially contained, and an attacker can return through the same identity path. In practice, incomplete revocation turns a response action into a delayed re-compromise.

Q: Why do NHI credentials increase blast radius in supply-chain attacks?

A: Because a single token or service account often has reach across pipelines, storage, cloud roles, and developer tooling. Once attackers validate the credential, they can move from the initial compromise into broader enumeration and data access much faster than defenders can inspect each dependency. The problem is the identity graph, not only the entry point.

Q: How do security teams know if credential rotation actually worked?

A: They need proof that every consumer rejected the old credential, every dependent workflow has moved to the replacement, and no residual access path still functions. A rotation is not complete until validation shows the old secret is dead everywhere it mattered. Without that verification, response teams are guessing.

Q: Who is accountable when a supply-chain breach persists because an NHI credential survived rotation?

A: Accountability sits with the teams that own the credential lifecycle, the systems that consume it, and the incident response process that declared containment too early. Frameworks such as NIST CSF and NHI governance programmes expect identity, access, and recovery responsibilities to be defined before an incident, not improvised during one.

Technical breakdown

Residual access after credential rotation

Credential rotation only works when every dependent system stops trusting the old secret. In supply-chain incidents, a single overlooked access token, service account, or API key can keep functioning after the response team believes the breach is contained. That gap is often invisible because the credential may not be actively used until the attacker comes back through the same path. The core failure is not rotation itself, but incomplete invalidation across all consumers and trust relationships. Practical implication: validate that revocation actually breaks access everywhere the credential was used, not just in the original system.

Practical implication: confirm that revocation removes access across every consuming system, not just the source application.

Blast radius mapping for NHI credentials

Blast radius is the full set of systems, data, and pipelines a credential can reach. In NHI-heavy environments, that radius is rarely obvious from a static permission review because service accounts, tokens, and CI/CD secrets often chain into other identities or tools. A leaked credential may touch IAM roles, secrets managers, clusters, storage, and developer tooling before anyone notices. The technical problem is context collapse: the credential is treated as a string, not as an identity with dependencies. Practical implication: maintain a live dependency map for each credential so incident response can predict impact before revocation starts.

Practical implication: maintain a live dependency map for each credential before an incident forces emergency action.

Identity-aware secret scanning

Secret scanning on its own only tells you that a credential exists in a bad place. Identity-aware secret scanning adds the missing layer by linking the exposed secret to its owner, its permissions, its consumers, and its current validity. That context turns a noisy alert into an executable containment workflow. Without it, teams can discover exposure but still fail to revoke the right credential or verify that replacement access is active. Practical implication: tie secret findings to identity records so response teams can decide what to revoke, what to replace, and what to monitor.

Practical implication: connect secret findings to identity records so triage becomes actionable instead of investigative only.

Threat narrative

Attacker objective: The attacker objective was to turn a supply-chain foothold into broad credential harvesting, cloud enumeration, and large-scale data theft across downstream environments.

1. Entry occurred when TeamPCP exploited a misconfigured GitHub Actions workflow in the Aqua Trivy environment and stole a privileged access token.
2. Credential access and reuse followed when residual access remained after rotation, allowing the attackers to validate stolen credentials and harvest additional secrets from CI/CD systems.
3. Escalation and impact expanded as the campaign moved through LiteLLM, Mercor, and thousands of downstream targets, culminating in network access and 4TB of exfiltrated data.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Supply-chain compromise is not the root cause when NHI access survives the response. The real breach condition is residual identity trust after the initial incident, because the attacker no longer needs the first foothold if one credential remains valid. This is where NHI governance becomes more important than the original malware or workflow flaw. The practitioner takeaway is that containment must be judged by identity invalidation, not by the number of systems patched.

Blast radius mapping is the missing control when one secret can reach many environments. A service account or token is rarely isolated in modern delivery pipelines, and the incident proved that hidden dependencies can turn one credential into access across IAM, compute, storage, and developer tooling. That is why incident response in NHI environments is a governance exercise as much as a technical one. Practitioners should treat dependency visibility as part of the control plane, not an afterthought.

Identity-aware secret scanning is the named concept this breach sharpens. A scanner that only detects leaked strings misses the real problem: who owns the credential, what it can reach, and whether revocation is complete. This failure mode aligns directly with OWASP-NHI and NIST-CSF expectations for access control and response integrity. The implication is that teams must reframe secret exposure as an identity lifecycle event, not a file-matching event.

Rotation alone is an incomplete remediation model when the environment cannot prove what still depends on the secret. Aqua rotated, but the access was not fully severed, which allowed the campaign to continue. That means the control assumption behind traditional rotation workflows was already broken. The practitioner conclusion is that verified revocation, not rotation in name only, is the real containment threshold.

Supply-chain attacks now function as NHI cascade events, not single-point intrusions. Once one credential is harvested, the campaign can pivot through additional identities faster than human teams can inspect each path manually. This pattern is why identity governance and supply-chain response are converging operational problems. Security teams should align their response model to the credential graph, because the graph is what the attacker follows.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which helps explain why rotation and revocation often miss surviving access paths.
• That visibility gap is why teams should pair leaked-secret response with 52 NHI Breaches Analysis when they need to understand how identity failures become repeatable breach patterns.

What this signals

Identity-aware response is becoming the practical dividing line between containment and recurrence. Organisations that can map credentials to owners, consumers, and dependencies will respond faster when supply-chain exposure appears. Those that cannot will keep repeating the same pattern: discovery first, containment later, and lingering trust in the middle.

Identity blast radius: the real risk is not just secret exposure, but how far the exposed credential can reach before it is fully dead. That makes lifecycle hygiene, offboarding discipline, and dependency mapping operational priorities for NHI programmes.

With 97% of NHIs carrying excessive privileges, the governance problem is not isolated to one breach or one vendor source. The broader signal is that credential sprawl is already large enough that response teams need prebuilt identity visibility, not ad hoc triage, to stay ahead of cascade events.

For practitioners

• Build identity-linked credential inventories Map every service account, API key, token, certificate, and CI/CD secret to an owner, consumer, and downstream dependency. If you cannot answer what a credential reaches, you cannot safely rotate it during a breach response. Use the inventory to prioritize the identities that can touch production or sensitive data first.
• Verify revocation across all consumers Treat rotation as incomplete until every known system rejects the old credential and replacement access is confirmed active. This requires testing the original workflow, dependent jobs, and any secondary tools that may cache or reuse the secret. If access still works anywhere, containment has failed.
• Baseline normal NHI behaviour Track where each identity usually connects from, what it normally queries, and which systems it ordinarily touches. In the incident pattern described here, validation and cloud enumeration were the key signals, so baselines should make that behaviour stand out immediately. Feed those baselines into detection and response playbooks.
• Shorten the lifetime of unused credentials Decommission credentials that no longer have an active business purpose before attackers can reuse them after a supply-chain compromise. Focus first on stale tokens, service accounts with uncertain ownership, and secrets embedded in CI/CD or code. Shorter exposure windows reduce the number of valid paths an attacker can find.
• Run blast-radius exercises before the next incident Simulate a leaked secret and force the team to answer who owns it, what breaks if it is revoked, and which systems depend on it. Use the exercise to expose missing mappings and broken offboarding assumptions in your NHI programme. That preparation determines whether response is controlled or improvised.

Key takeaways

• The breach shows that supply-chain compromises become severe when non-human identity access survives the first response.
• The scale matters: the campaign expanded to 47 npm packages and ended in a 4TB exfiltration event at Mercor.
• Verified revocation, not one-time rotation, is the control that would have limited the blast radius.

Key terms

• Residual Access: Residual access is any valid path that remains after a security team believes it has revoked a credential or contained a compromise. In NHI incidents, it usually comes from missed tokens, forgotten service accounts, cached secrets, or incomplete dependency mapping that leaves old trust still active.
• Blast Radius: Blast radius is the full set of systems, identities, and data a compromised credential can reach. For NHI governance, it is the practical measure of exposure because it shows how far one secret can propagate across pipelines, cloud roles, storage, and production workloads before containment takes effect.
• Identity-Aware Secret Scanning: Identity-aware secret scanning links an exposed secret to the identity that owns it, the systems that consume it, and whether it is still valid. It turns raw secret detection into a governance workflow that supports triage, revocation, and verification instead of creating another alert that lacks context.
• Verified Rotation: Verified rotation is the process of replacing a credential and proving the old one no longer works everywhere it was trusted. In mature NHI programmes, the goal is not merely to generate a new secret, but to confirm that every consumer has switched and no residual access path remains.

Deepen your knowledge

NHI blast radius mapping and verified rotation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with leaked secrets, residual access, or supply-chain exposure, it is worth exploring.

This post draws on content published by Oasis Security: When Supply Chain Attacks Meet NHI Sprawl. Read the original.