Supply chain attacks are now identity risks for NHI teams

At a glance

What this is: This analysis explains how supply chain attacks become identity-risk events when compromised build paths expose credentials, tokens, and cloud permissions.

Why it matters: It matters because NHI and IAM teams have to govern third-party software, pipeline credentials, and downstream blast radius together, not as separate problems.

Context

Software supply chain attacks exploit trusted code paths to reach the identities and secrets used during build, test, and release. In this article, the security problem is not just malicious code entering a pipeline. It is the way pipeline trust assumptions expose non-human identities such as PATs, service accounts, publishing tokens, and cloud access keys.

Widefield Security uses the Trivy and LiteLLM compromises to show how a compromised dependency can become an identity exposure event for the organisations that run it. The central governance gap is that many teams still treat software provenance, CI/CD permissions, and secret management as separate controls when attackers move across them as one path.

Key questions

Q: What breaks when supply chain attacks can run with pipeline credentials?

A: The boundary between code execution and identity governance breaks first. Once untrusted build input can access PATs, cloud keys, or publishing tokens, the attacker can move from code compromise to legitimate-seeming access. That is why the issue is not only package integrity. It is whether the pipeline ever had credentials in scope that the attacked code could inherit.

Q: Why do credential-harvesting supply chain attacks create so much downstream risk?

A: Because stolen machine credentials are often more reusable than the code path that exposed them. A valid token can be used to publish packages, write tags, access registries, or reach SaaS and cloud resources without triggering a new authentication event. The business impact is broad because one compromise can propagate into multiple environments and user bases.

Q: What are the signs that a build pipeline is failing its identity controls?

A: Look for mutable dependency references, shared credentials across build stages, secrets present in runners, and repository workflows that execute untrusted code with elevated permissions. Those are the practical indicators that the pipeline can expose non-human identities to compromise. If a stolen token can cross from build to publish to runtime, the control boundary is already failing.

Q: How should teams respond when a trusted dependency is poisoned?

A: Contain the identity layer first: revoke exposed tokens, rotate credentials, inspect active sessions, and trace which pipelines consumed the poisoned reference. Then rebuild trust from immutable artifacts and verified provenance. The response is less about removing bad code from one repository and more about closing the access paths the compromised code could use.

Technical breakdown

Why supply chain trust becomes identity exposure

Software supply chain attacks succeed because build systems usually execute third-party code with access to credentials that were never meant for that code path. Once a runner, dependency, or release artifact is trusted, the attacker does not need a new login flow. They need only a place where secrets are already present. That is why PATs, cloud keys, Kubernetes tokens, and publishing tokens are so attractive in compromised pipelines. The identity problem is not the code itself. It is that the code is executed inside a context that inherits privilege from the pipeline owner.

Practical implication: Treat every third-party build input as a potential identity boundary crossing, not just a software integrity issue.

How tag poisoning and unpinned dependencies widen blast radius

Mutable tags and unpinned dependencies let an attacker change what a pipeline executes without changing the pipeline definition itself. That creates a time-of-use problem: the build references one object, but the runner retrieves another. In the Trivy and LiteLLM cases, that made downstream compromise possible even when the original repository was not the final target. This is where software supply chain risk becomes NHI risk. The attacker inherits whatever secrets, scopes, and active sessions the pipeline exposes at execution time, then reuses them across environments and registries.

Practical implication: Pin build inputs to immutable references and assume any mutable dependency can redirect execution into a secret-rich context.

Why credential harvesting is the real end state

The payload in these attacks was not limited to sabotaging builds. It was designed to harvest credentials from memory, filesystem paths, environment files, and active sessions, then move that access into package publishing and user environments. That is an identity escalation pattern, not just malware delivery. Once valid tokens are stolen, the attacker can bypass factor checks and operate as a legitimate principal. For NHI governance, this means the most important control question is not whether a pipeline ran cleanly. It is whether stolen machine credentials can be issued, reused, and retained long enough to matter.

Practical implication: Build detection and response around credential theft paths, active-session visibility, and token reuse rather than around code execution alone.

Threat narrative

Attacker objective: The attacker aimed to harvest valid credentials and use trusted supply chain paths to reach downstream environments and package registries.

1. Entry occurred through a misconfigured GitHub Actions workflow that checked out untrusted pull request content in a privileged context and exposed a PAT.
2. The attacker used the retained PAT and a compromised service account to poison repository tags and redirect downstream pipelines to a malicious binary.
3. The malicious payload harvested credentials from memory, files, and environment data, then reused stolen tokens to publish packages and exfiltrate further secrets.
4. Impact followed as attackers gained access to additional user and registry environments through trusted release channels and stolen identity material.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Supply chain attacks have become identity attacks because build trust now carries credential trust. When a pipeline executes third-party code with tokens, keys, and registry permissions already in scope, the attacker is not merely inserting malware. They are inheriting the identity surface that the build system exposes. Practitioners need to stop treating software provenance and identity governance as separate disciplines, because the compromise path already combines them.

Mutable release references create identity blast radius, not just integrity risk. The problem with poisoned tags and unpinned dependencies is that the execution target can be changed after approval while the surrounding trust model remains intact. That means the same pipeline can be used to reach different credential stores, registries, and downstream user environments without changing its declared intent. The practical conclusion is that build-time trust decisions now determine identity exposure at runtime.

Secrets sprawl inside pipelines is a governance failure, not an implementation detail. PATs, cloud keys, service account tokens, and publishing credentials were all available for harvesting because they were positioned for convenience rather than containment. That creates a wider identity blast radius than many IAM programmes account for. Teams should read this pattern as a signal that secret placement, scope separation, and runtime identity boundaries need to be governed as one control plane.

Identity threat detection has to extend into CI/CD and package distribution channels. The attacker value in these cases came from operating as a legitimate principal after the theft, not from noisy exploitation alone. That means behavioural baselines, session visibility, and token reuse analysis matter as much as malware detection. The governance lesson is simple: once software supply chain compromise starts producing valid credentials, the response model must switch from code triage to identity containment.

Ephemeral credential trust debt: Short-lived tokens reduce exposure time, but they do not eliminate the assumption that a pipeline context is trustworthy while it runs. The Trivy and LiteLLM path shows that the trust debt is created at issuance and only repaid if scope, provenance, and session visibility are governed together. Practitioners should treat that debt as a measurable programme risk, not an abstract architecture issue.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: Identity Threat Detection and Response (ITDR) Guide

What this signals

Supply chain compromise now has to be read as NHI exposure. When build systems execute third-party code with standing access to secrets, the attacker objective shifts from code tampering to credential collection. That means pipeline ownership, secret scope, and downstream session visibility belong in the same governance conversation, not separate ones.

The control gap is not just dependency trust. It is the assumption that a build context can safely inherit credentials for long enough to complete work without being abused. That assumption no longer holds once malicious code is present in runners, registries, or release automation.

For practitioners

• Pin build inputs to immutable references Replace mutable tags with full commit hashes for dependencies, actions, and release artifacts so a later force-push cannot redirect execution into malicious code.
• Separate pipeline credentials by operation Use different credentials for pulling code, publishing packages, writing tags, and accessing registries so a stolen token does not span multiple trust zones.
• Move secrets out of broad environment variables Fetch credentials at runtime from a dedicated secrets manager and avoid hardcoding them into build artifacts or shared runner environments.
• Harden pull_request_target usage Restrict this trigger to trusted sources only, because it can expose privileged secrets to untrusted code during workflow execution.
• Centralise identity visibility for CI/CD sessions Inventory which identities, tokens, and active sessions are present in runners, registries, and SaaS tools so stolen access can be isolated quickly.

Key takeaways

• Supply chain attacks are becoming identity risks because compromised build paths expose machine credentials, tokens, and cloud permissions.
• The Trivy and LiteLLM incidents show how one poisoned dependency can move from workflow compromise to package publishing and downstream secret theft.
• Teams that pin dependencies, separate credentials by function, and monitor active sessions can reduce the blast radius of poisoned supply chains.

Key terms

• Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
• Pipeline Credential: A pipeline credential is a secret, token, key, or service account used by automation to authenticate and move code through delivery stages. These credentials function like non-human identities and should be governed with the same expectations for ownership, scope, rotation, and revocation.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.