Major supply chain attacks expose the limits of identity governance

At a glance

What this is: This is a Saviynt analysis of how major supply chain attacks exploit third-party trust, exposed secrets, and identity governance blind spots.

Why it matters: It matters because IAM, PAM and NHI programmes that assume trust is static can miss supplier-driven compromise until attackers are already inside identity-controlled systems.

Context

Major supply chain attacks are no longer just procurement or vendor-risk problems. They become identity problems when third parties, CI/CD runners, delegated tokens, or shared service access let an external compromise move into internal trust relationships.

In this topic, the security gap is not only exposed infrastructure. It is the assumption that governance processes can see, review, and revoke access fast enough once a supplier or build system has already been abused. For NHI, IAM and PAM teams, that assumption is often wrong.

Key questions

Q: What breaks when a third-party identity is compromised in a supply chain attack?

A: The main break is trust propagation. A compromised supplier identity can inherit access into systems the customer would never expose directly, especially when integrations are broad and lifecycle controls are weak. Containment fails when the organisation cannot quickly identify what the supplier can reach, who owns the access, and how to revoke it cleanly.

Q: Why do supply chain attacks so often turn into identity incidents?

A: Because attackers are not only changing code, they are harvesting the non-human identities that code runs beside. API keys, cloud credentials, SSH keys, and registry tokens give direct access to infrastructure and publishing systems, so a compromised package becomes an identity compromise with wider blast radius.

Q: What signs show that third-party NHI access is too broad?

A: Watch for shared secrets across multiple integrations, long-lived tokens with no clear owner, CI/CD identities that can reach production broadly, and vendor accounts that remain active after the relationship changes. Those are strong indicators that external access has outgrown its original purpose.

Q: How should teams respond when a supplier compromise exposes automation credentials?

A: Contain the affected trust path, revoke exposed secrets, confirm where the credentials were used, and force re-approval before any partner access resumes. The goal is to break reuse of the compromised identity, not just document the incident after the fact.

Technical breakdown

Why third-party access becomes an identity control problem

Third-party compromise matters because it rarely stops at the supplier boundary. Once a vendor or build partner has access to tokens, connectors, or shared admin paths, the attacker can operate through legitimate trust rather than obvious malware. That shifts the control problem from perimeter defence to entitlement governance, because the access path itself is already authorised. In NHI terms, the risk is not just exposure of credentials, but the permanence of the relationship that gives those credentials value. When supplier access is broadly scoped, attackers inherit the trust graph, not just a single account.

Practical implication: map every external trust path to the owning business relationship and limit supplier access to the minimum identity scope needed.

How exposed secrets and delegated tokens amplify blast radius

Secrets, API keys, OAuth tokens and certificates can turn a single compromised partner into a repeatable access route. Unlike a password reset on a human account, these non-human credentials are often embedded in automation, build pipelines, or integration flows, so one leak can cascade across multiple environments. The attack pattern is especially dangerous when credentials are long-lived or reused across tools, because rotation then becomes partial rather than complete. That is why supply chain incidents often look like identity failures before they look like technical breaches: the attacker is using the organisation’s own delegated trust to keep moving.

Practical implication: treat third-party secrets as high-risk NHIs and enforce ownership, rotation, and revocation controls tied to supplier offboarding.

Why CI/CD runners and build systems are high-value identities

CI/CD runners, automation accounts and build systems are attractive because they sit close to code, artefacts and deployment rights. If an attacker reaches those identities, they can alter software, harvest secrets from build logs, or inject malicious steps into delivery pipelines. These systems are often designed for speed and repeatability, not for human-style review, so compromise can stay invisible until downstream customers or internal teams see the impact. Supply chain attacks therefore expose a structural weakness: the more trusted the automation, the less likely it is to be monitored like a privileged identity.

Practical implication: classify build and runner identities as privileged NHIs and monitor them with the same urgency as admin accounts.

Threat narrative

Attacker objective: The attacker aims to convert supplier trust into durable access to downstream systems, secrets, or deployment channels.

1. Entry occurs through a trusted third party, build partner, or exposed supply chain component rather than a direct attack on the target organisation.
2. Credential access follows when tokens, runner secrets, or delegated permissions are stolen or abused inside the supplier environment.
3. Escalation happens as those credentials are reused against downstream systems, allowing the attacker to move from supplier trust into internal identity-controlled assets.
4. Impact lands when the attacker reaches code, data, or administrative functions through legitimate automation and delegated access paths.

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.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

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 governance failures, not just vendor-risk events. The decisive issue is that third-party access now enters the environment through identities, credentials and automation paths that governance teams are supposed to control. When those paths are over-scoped or weakly monitored, the organisation inherits the supplier’s compromise as if it were its own. Practitioners should treat supplier identity governance as a first-class control plane, not an afterthought.

Ephemeral compromise is breaking the assumption that access review can catch abuse in time. Access review was designed for access that persists long enough to be recertified. Supply chain attacks often move faster than that cycle, so the governance model produces evidence after the fact instead of prevention in the moment. The implication is that identity programmes need issuance-time and trust-boundary controls, not only periodic certification.

CI/CD runners are now privileged identities with attack value equal to admin accounts. Build and deployment systems hold secrets, deployment rights and trusted execution paths, which makes them a primary target in major supply chain incidents. This creates an identity blast radius problem: one compromised automation account can affect many workloads at once. Practitioners should govern runners, pipelines and service credentials as privileged infrastructure, not as disposable engineering tooling.

Third-party access without lifecycle offboarding is the failure mode these incidents keep exposing. The governance gap is not merely that access exists, but that supplier access often outlives the relationship, the purpose, or the context that justified it. That means revocation is not happening at the moment trust changes. The practical conclusion is that offboarding and entitlement ownership must follow the supplier relationship, not the ticket queue.

Major supply chain attacks are forcing a broader rethink of delegated trust. The old model assumed that a trusted supplier would remain trustworthy inside the permitted scope. These incidents show that the scope itself can become the attack surface. For identity teams, the next control question is not who was approved, but what that approval lets an external party do when the supplier is already compromised.

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.
• Read next: NHI Lifecycle Management Guide

What this signals

Ephemeral trust debt: supply chain incidents now create identity exposure windows that are shorter than many review cycles, so governance has to move closer to issuance and revocation time. If access only exists briefly, the control point is not certification but ownership and lifecycle enforcement.

Third-party NHIs should be treated as part of the privileged estate, not as temporary integrations. Once a supplier token can reach production, the question is no longer whether it is a vendor account, but whether it can be used like one. That is where least privilege, offboarding, and monitoring must converge.

For practitioners

• Map every third-party identity path Inventory supplier accounts, tokens, connectors and CI/CD trust paths, then assign a business owner to each external entitlement.
• Reclassify automation as privileged NHI Treat CI/CD runners, deployment accounts and integration tokens as privileged identities with monitoring, rotation and least-privilege scope.
• Bind access to supplier lifecycle Require revocation and re-approval when a vendor relationship, contract scope or integration purpose changes, not only at periodic review.
• Reduce standing third-party privilege Replace broad persistent access with narrow, time-bound permissions so delegated trust cannot be reused across multiple downstream systems.

Key takeaways

• Major supply chain attacks expose a governance gap where external trust paths are more dangerous than the original compromise vector.
• The source article points to a broad third-party exposure problem, with 92% of organisations exposing NHIs to third parties and 59% of compromised machines in one 2025 supply chain attack being CI/CD runners.
• Identity teams need to govern supplier access as a privileged lifecycle issue, with tighter scope, faster revocation and better ownership of automation identities.

Key terms

• Third-Party NHI: Third-Party NHI is a non-human identity owned or operated by an external organization, partner, contractor, or supplier. It includes service accounts, API keys, certificates, tokens, and automated agents that access systems outside the primary enterprise boundary. Governance must cover issuance, scope, monitoring, revocation, and contractual accountability.
• Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.
• 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.
• Vendor Lifecycle Offboarding: Vendor lifecycle offboarding is the controlled removal of access, privileges, and records when a third-party relationship ends or changes. It matters because external access often lingers after business need has expired, creating residual exposure that compliance checklists alone do not reveal.

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.