Supply chain attacks are now identity risks for NHI teams

At a glance

What this is: This analysis shows how software supply chain compromise becomes an identity problem when build pipelines and downstream package releases expose credentials, tokens, and cloud access.

Why it matters: It matters because IAM, PAM, NHI, and DevSecOps teams must treat CI/CD, package publishing, and dependency trust as identity governance problems, not just software integrity issues.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Widefield Security's analysis of the Trivy and LiteLLM supply chain compromises

Context

Software supply chain attacks become identity attacks when trusted code paths are used to steal credentials, tokens, and cloud permissions. In the primary pattern here, the compromise is not the end state. The build system, package pipeline, or dependency trust chain is the access path, and the real target is the set of non-human identities that can be reused elsewhere.

That matters for NHI governance because CI/CD credentials are often broader than the single job that needs them, and downstream releases can inherit trust from upstream components. When a malicious dependency or poisoned tag can execute inside a privileged workflow, identity controls have already been bypassed before detection begins.

The article’s Trivy and LiteLLM examples are typical of convenience-driven pipeline design, not edge cases. They show how quickly supply chain trust collapses into credential exposure when secrets are long-lived, permissions are reused, and package integrity checks are weak.

Key questions

Q: How should security teams prevent supply chain compromise from becoming NHI exposure?

A: Security teams should isolate build trust from secret access, pin dependencies to immutable references, and treat every pipeline credential as a governed non-human identity. The goal is to stop a malicious dependency from reaching tokens, publishing rights, or cloud permissions even if the build runner executes untrusted code.

Q: Why do unpinned dependencies increase identity risk in CI/CD pipelines?

A: Unpinned dependencies let an attacker change the code a trusted workflow executes without changing the name the pipeline expects. That turns the dependency reference into a mutable identity boundary and can expose repository secrets, registry tokens, or cloud credentials to malicious code.

Q: What do teams get wrong about secrets in build automation?

A: Teams often assume build secrets are safe because the job is temporary, but the credential usually outlives the run. Once a token is stolen, it behaves like any other NHI with its own lifecycle, scope, and blast radius, so inventory, revocation, and rotation matter more than workflow speed.

Q: Who is accountable when a compromised pipeline publishes malicious packages?

A: Accountability usually sits with the organisation that issued the publishing credential, maintained the pipeline trust boundary, and failed to constrain release authority. In practice, this is an IAM, DevSecOps, and platform governance issue together, not a developer-only mistake.

Technical breakdown

How supply chain compromise turns into credential harvesting

A software supply chain attack exploits the fact that build systems routinely execute third-party code inside trusted contexts. If dependencies are unpinned, tags are mutable, or workflows run untrusted input, the attacker does not need to break the perimeter. They only need a code path that inherits repository permissions, secret injection, or registry access. Once execution occurs, the payload can search memory, environment variables, and filesystem locations for tokens, keys, and cloud credentials. This is an identity problem because the attacker is harvesting usable NHI material from a legitimate automation path, not exploiting a traditional vulnerability alone.

Practical implication: separate code checkout from privileged execution and restrict pipeline credentials to the exact task they serve.

Why mutable tags and unpinned dependencies create trust drift

Tags are pointers, not immutable references. When a workflow consumes a dependency by tag instead of by full commit SHA, the producer of that dependency can alter what code the pipeline executes without changing the name the consumer sees. That creates trust drift: the consumer believes it is running approved code while the build runner may be executing a different payload. In the article’s example, poisoned tags allowed malicious code to propagate from one repository to another and then into a downstream package release. The governance weakness is not only supply chain integrity, but the absence of immutable identity for the software object being trusted.

Practical implication: pin build dependencies to immutable hashes and treat mutable tags as an unacceptable trust boundary for privileged workflows.

How stolen build credentials become downstream NHI abuse

Once a malicious payload captures a publishing token or repository PAT, the attacker can bypass the original CI system and use the credential as a reusable non-human identity. That allows direct package upload, tag rewriting, registry changes, and lateral movement into other systems that trust the same identity or secret family. The important shift is that the attack no longer depends on the original compromise being active. The stolen token becomes an independent access path with its own lifecycle, scope, and blast radius. This is why NHI governance has to cover issuance, scope, rotation, and offboarding across build and release tooling.

Practical implication: inventory every pipeline secret as an NHI, then revoke and rotate it as soon as it appears in a compromise path.

Threat narrative

Attacker objective: The attacker’s objective was to turn trusted software delivery paths into a credential-harvesting channel that could be reused to compromise downstream environments.

1. Entry occurred through a poisoned GitHub Actions workflow and a malicious pull request path that executed untrusted code inside a privileged build context.
2. Credential access followed when the payload exfiltrated repository PATs, publishing tokens, and local secrets from memory, filesystem paths, and build artifacts.
3. Impact came when the stolen identities enabled tag poisoning, malicious package publication, and downstream credential theft from users of the compromised software.

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

Software supply chain trust is really NHI trust in disguise. The article shows that the decisive asset is not the code artifact itself but the credentials embedded in the build, release, and dependency path. Once a pipeline can execute external code and inherit broad permissions, the attacker is no longer attacking software integrity alone. The implication is that NHI governance has to extend into the software delivery chain, not sit beside it.

Mutable tags create an identity problem, not just a packaging problem. A tag-based reference can change underneath the consumer while preserving the same label, which breaks the assumption that the referenced software object is stable. That matters because access decisions in CI/CD are made on the basis of what the workflow believes it is running. Practitioners should treat mutable references as a trust failure that undermines downstream accountability.

Pipeline credentials are overprivileged NHIs until proven otherwise. The Trivy and LiteLLM path shows how a single stolen PAT or publishing token can bridge repositories, registries, and user environments. That is classic standing-privilege behaviour in a software supply chain context. The implication is that each pipeline secret needs its own lifecycle, scope, and offboarding logic, because reuse multiplies blast radius.

Ephemeral execution does not remove identity risk if the credential outlives the job. Build runners may terminate quickly, but the tokens they access often persist long enough to be reused elsewhere. That creates a disconnect between the speed of automation and the slower control cycles of IAM and review processes. Practitioners need to recognise that the threat is not the job duration, but the credential lifetime attached to it.

Identity blast radius is the right concept for supply chain compromise. The compromise spreads from a single workflow into package publishing, downstream installations, and user environments because the same trusted identity material is reused across boundaries. That makes blast radius the more useful governing metric than the number of affected repositories alone. Security teams should model how far a stolen CI/CD identity can travel before they treat the pipeline as contained.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why build-time leakage remains a repeatable identity failure mode.
• For a broader NHI lens, see 52 NHI Breaches Analysis for recurring patterns in secret exposure, reuse, and blast-radius expansion.

What this signals

Pipeline identity is becoming a primary control surface. Teams that still treat CI/CD secrets as implementation details will keep missing the real failure mode, which is credential reuse across build, release, and package distribution. The practical shift is to govern pipeline identities with the same discipline used for production service accounts and privileged access, with the Ultimate Guide to NHIs as a baseline reference.

With only 44% of developers following security best practices for secrets management according to The State of Secrets in AppSec, the control gap is behavioural as much as technical. Organisations need to assume that code paths will be exposed and design for rapid revocation, short-lived access, and verifiable build provenance.

Identity blast radius will matter more than single-point compromise. A poisoned dependency can move from source control to registries to user environments in one chain, which means the response model must follow the credential, not just the repository. For teams maturing their control set, the OWASP NHI Top 10 provides a useful way to map trust, privilege, and execution risk across the delivery path.

For practitioners

• Pin dependencies to immutable commit SHAs Replace version tags with full commit hashes for build inputs that can influence privileged execution. This removes the attacker’s ability to redirect a trusted reference to malicious code after approval.
• Separate code checkout from privileged steps Run untrusted pull request content in a context that cannot access repository secrets, publishing tokens, or registry permissions. Keep checkout, test, signing, and release stages isolated by identity and by runner trust level.
• Treat every pipeline secret as an NHI Catalogue PATs, package publish tokens, cloud keys, and service account credentials with owners, scopes, and expiry. Revoke any secret exposed in build logs, artifacts, or dependency compromise paths before it can be reused.
• Move release authority to short-lived identity tokens Use short-lived OIDC-based tokens for publishing and deployment so that a captured credential has limited replay value. Long-lived static secrets should not be the default mechanism for trusted build operations.
• Generate an SBOM for every build Record the exact direct and transitive dependencies, plus cryptographic hashes, for each release so compromise scope can be mapped quickly. This speeds containment when a poisoned tag or malicious package is discovered.

Key takeaways

• This article shows that software supply chain attacks become identity incidents when build and release credentials are reusable beyond their intended job.
• The scale of the problem is visible in both the mechanics and the response gap, with poisoned workflows able to steal tokens before traditional controls notice.
• The control that changes the outcome is immutable dependency pinning combined with short-lived, tightly scoped pipeline identities.

Key terms

• Software supply chain attack: A software supply chain attack compromises the path by which code is built, updated, or distributed rather than the final application directly. Attackers abuse trusted dependencies, build workflows, or package registries to inject malicious code or steal credentials from environments that assume the code is legitimate.
• Pipeline identity: Pipeline identity is the set of credentials, permissions, and trust relationships that allow build and release automation to operate. In practice, it includes service accounts, tokens, and secret material that can be overprivileged, reused, or inherited across stages if not tightly governed.
• Immutable dependency reference: An immutable dependency reference points to one specific code version that cannot change after it is published. Using full commit hashes instead of mutable tags reduces trust drift because the build system can verify exactly what code is being executed in a privileged workflow.
• Identity blast radius: Identity blast radius is the extent of systems, data, and workflows that can be reached once a credential or token is stolen. It is a practical way to measure how far a compromised non-human identity can move before revocation, isolation, or containment takes effect.

What's in the full article

Widefield Security's full analysis covers the operational detail this post intentionally leaves for the source:

• Step-by-step reconstruction of the Trivy and LiteLLM attack path through GitHub Actions, tag poisoning, and downstream package release
• Specific malware behaviours used to harvest SSH keys, cloud tokens, Kubernetes credentials, and registry secrets
• Concrete hardening guidance for pull_request_target, dependency pinning, and repository-level secret separation
• Widefield Security's explanation of how ITDR and behavioural baselines help identify legitimate-looking credential abuse

👉 Widefield Security's full article covers the attack sequence, credential harvesting details, and downstream release impact

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 lifecycle governance, it is worth exploring.