Supply chain attacks expose the trust model behind modern software

At a glance

What this is: This is a blog post about how supply chain attacks exploit trusted software dependencies and build pipelines, with SolarWinds, npm, XZ Utils, and GitHub Actions used as examples.

Why it matters: It matters because identity, secrets, and pipeline governance all fail at once when downstream systems trust upstream actors too broadly across NHI, human, and automation-heavy environments.

👉 Read Orca Security's analysis of supply chain attacks across code and cloud

Context

Supply chain attacks are a governance problem as much as a technical one. They exploit the trust chain that links third-party code, build systems, SaaS services, and deployment automation, which means compromise can enter through identities and artifacts that teams did not create but still allow to execute.

For identity practitioners, the core issue is that downstream systems often treat upstream actors as inherently trustworthy once they are signed, installed, or added to a workflow. That assumption is especially dangerous in environments where service accounts, CI/CD tokens, and developer credentials can be used to move from one trusted dependency to many affected systems.

This makes supply chain security a cross-programme concern rather than a narrow AppSec problem. It touches non-human identity governance, human developer hygiene, and the control of automated build and deployment paths.

Key questions

Q: How should security teams reduce supply chain risk in CI/CD pipelines?

A: Security teams should limit the privilege of build, test, and deployment identities, isolate pipelines by environment, and verify upstream artifacts before they execute. The most important move is to stop assuming that a trusted dependency should also be trusted to run with broad access. Narrow execution authority first, then add provenance checks and secret monitoring.

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

A: They become identity incidents because attackers frequently target the credentials that automation already uses. Once a malicious package or action can read tokens, API keys, or cloud secrets, the issue shifts from code integrity to identity abuse. That is why secrets scope, service account reuse, and runner permissions are central controls, not secondary ones.

Q: What do organisations get wrong about trusting signed packages and tools?

A: They often treat a signature or popular package as proof that runtime execution is safe. In reality, the attack may occur through a compromised maintainer account, poisoned update, or malicious post-install script. Trust should be conditional on the execution context, not just on the source label or repository reputation.

Q: How do teams contain a supply chain compromise before it spreads?

A: Teams should revoke exposed secrets, isolate affected runners, and cut off access from automation identities that could reuse the same credentials elsewhere. The containment goal is to stop the poisoned trust path from reaching other repositories, registries, or cloud environments. The faster the shared identity is disabled, the smaller the blast radius.

Technical breakdown

How supply chain compromise enters trusted build paths

Supply chain attacks usually begin by compromising a dependency, maintainer account, package registry, update channel, or CI/CD integration. The attacker does not need to break perimeter defences directly if the organisation already allows upstream code or tooling to execute during build or install. In practice, the trusted path becomes the delivery mechanism. That is why signed releases, package reputation, and automation trust are all part of the attack surface. Once the malicious artifact is accepted, downstream systems may execute it with the same privileges used for legitimate software delivery.

Practical implication: control which upstream identities, packages, and runners are allowed to execute inside your pipeline.

Why secrets exposure turns a package compromise into identity abuse

Many supply chain incidents become serious because the compromised package or build step can read tokens, API keys, SSH keys, or cloud credentials from the environment. Those secrets are the real prize because they let attackers pivot from code execution to identity misuse. In CI/CD, secrets often exist to automate tests, deployments, or integrations, which means they are both powerful and widely distributed. If those credentials are long-lived or overprivileged, the compromise can spread beyond the original workflow and affect production systems, repositories, or cloud services.

Practical implication: treat every build-time secret as a high-value NHI and scope it tightly to one job and one environment.

Why cloud-native automation expands the blast radius of trust

Modern delivery pipelines reuse the same tokens, runners, and service identities across many repositories and environments. That reuse makes supply chain compromise systemic rather than isolated. A malicious update in one dependency can expose multiple projects if the same automation identity has broad access to logs, artifact stores, registries, or cloud APIs. Zero Trust helps here only when trust is verified continuously and at the point of use, not granted once because a component is familiar. The issue is not just malicious code, but overextended execution authority.

Practical implication: segment build identities and isolate pipelines so one poisoned dependency cannot reach unrelated workloads.

Threat narrative

Attacker objective: The attacker wants to weaponise trusted software distribution so one compromise yields access to many downstream environments and their secrets.

1. Entry occurs through a trusted third-party dependency, maintainer account, update channel, or CI/CD integration that the organisation already allows to run in its pipeline.
2. Escalation happens when the malicious artifact or build step steals secrets, tokens, or credentials from the environment and uses them to move into adjacent systems.
3. Impact follows when those credentials, build artifacts, or poisoned updates reach production, enabling broad downstream compromise across repositories, clouds, or customer environments.

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 security is really trust-chain security. The article shows that the breach path is not limited to code integrity. It includes who is allowed to publish, sign, execute, and inherit trust inside the pipeline. That makes supplier trust, build trust, and execution trust one continuous control problem, not separate ones. Practitioners should treat upstream trust as an identity decision, not a software preference.

Standing pipeline privilege is the failure mode that turns dependency risk into enterprise risk. CI/CD tokens, runner credentials, and deployment bots often retain access long after the task that justified them has ended. Once those identities are reused across repositories or environments, a single poisoned dependency can pivot into unrelated systems. The practical conclusion is that overextended machine access is the real amplification layer in supply chain incidents.

Least privilege only works if upstream execution is already constrained. The article’s examples show that organisations often assume a signed package or trusted action is safe enough to run broadly. That assumption collapses when the package itself is the attacker. In governance terms, the control model is built for known-good artefacts, but supply chain attacks target the integrity of the artefact before the control ever evaluates it.

Secret sprawl makes supply chain compromise multi-domain. A poisoned package does not need direct cloud access if it can harvest tokens from build logs, runner memory, or environment variables. That is why secrets management, developer workflow hygiene, and machine identity governance belong in the same conversation. Practitioners should see package compromise as an identity event with cloud consequences, not just an AppSec incident.

Runtime verification matters more than provenance labels once automation is involved. Signed updates, package popularity, and known maintainer status do not neutralise a compromised execution path. What matters is whether the identity, artifact, and environment are verified at the moment of use. Security programmes that stop at source trust will keep missing the control point where the attack actually executes.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• That gap between exposure and response is why teams should pair secret monitoring with lifecycle controls, as explored in Top 10 NHI Issues.

What this signals

Secret exposure windows are collapsing faster than most response processes can react. Once a credential leaks into a repository, log, or build artifact, the practical question is not whether it can be abused but whether detection and revocation happen before the trust chain is reused. That is why pipeline telemetry, secret scanning, and delegated access review need to be linked in a single operational loop.

Trust-chain governance will become a core identity programme concern. The organisations that treat software delivery as an identity domain, not just an engineering workflow, will be the ones that reduce downstream compromise. Aligning build identities, repository permissions, and cloud secrets management with OWASP Non-Human Identity Top 10 and Ultimate Guide to NHIs , Why NHI Security Matters Now gives teams a defensible model for that shift.

For practitioners

• Tighten build-time secret scope Issue tokens and API keys only to the job that needs them, with the shortest viable lifetime and no reuse across pipelines or repositories.
• Isolate pipeline identities Separate runner, deployment, and registry credentials so compromise in one repository cannot automatically reach unrelated workloads or environments.
• Verify upstream execution before install Check package provenance, maintainer trust, and signing status, but also block unapproved execution paths in CI/CD and developer workstations.
• Scan for secret exposure in automation Monitor logs, runner memory, and artifact stores for leaked credentials, and treat a single leaked token as a shared-identity incident.
• Apply zero-trust segmentation to software delivery Treat every dependency, action, and model as untrusted until verified at runtime, especially where the same service account can reach multiple environments.

Key takeaways

• Supply chain attacks work because organisations extend trust to identities and artifacts they do not fully control.
• The biggest amplification factor is not the initial compromise but the reuse of secrets and automation identities across many pipelines.
• Teams that constrain build-time privilege, verify runtime execution, and isolate delivery paths will shrink the blast radius of the next upstream compromise.

Key terms

• Supply Chain Attack: A supply chain attack compromises a trusted third party, dependency, or delivery channel so attackers reach downstream organisations indirectly. In identity terms, the attacker abuses inherited trust, often through software updates, build systems, or integrations that execute with legitimate-looking authority.
• Build-Time Secret: A build-time secret is a token, key, or certificate made available to automation during software compilation, testing, or deployment. These credentials are often high-value because they unlock cloud services, repositories, or registries, and they are especially dangerous when reused across multiple pipelines.
• Trust Chain: A trust chain is the sequence of people, systems, packages, and identities that are allowed to rely on one another during software delivery. When one link is compromised, the impact can spread far beyond the original point of failure because downstream systems inherit the earlier trust decision.
• Pipeline Identity: Pipeline identity is the non-human identity used by CI/CD, build, and deployment systems to access repositories, registries, clouds, or logs. It must be tightly scoped because these identities can move code and secrets at scale, turning a single compromise into broad operational reach.

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.

This post draws on content published by Orca Security: supply chain attacks and how they exploit trusted dependencies. Read the original.