Supply chain attacks expose the trust model behind modern software

At a glance

What this is: This is a blog analysis of supply chain attacks, showing that the central weakness is trust in dependencies, packages, build tooling and third-party services.

Why it matters: It matters because IAM, DevOps and platform teams have to govern trust boundaries across human, NHI and automation layers, not just harden the final production environment.

Context

Supply chain attacks are attacks on trust boundaries, not just on code quality. In modern software delivery, every dependency, package, CI/CD runner, plugin and SaaS integration extends the identity and access surface that defenders have to govern.

The governance gap is that many programmes still treat upstream software as inherently trusted once it is signed, installed or integrated. That assumption breaks when a maintainer account, build process or third-party token is compromised and the resulting access is inherited downstream.

For IAM and DevOps teams, the practical question is no longer whether the application is secured at runtime alone. It is whether the identities, credentials and execution paths used to build, update and distribute software are governed with the same discipline as production access.

Key questions

Q: What breaks when software update trust is compromised in a supply chain attack?

A: When update trust is compromised, normal patching workflows become a delivery mechanism for malicious code. Signed packages, automatic updaters, and routine maintenance channels all lose reliability if attackers can alter the path, the payload, or the validation step. Defenders then have to assume that the software source, not just the endpoint, is part of the incident.

Q: Why do supply chain attacks create such large business continuity impacts?

A: They use trusted channels to spread compromise across multiple systems and organisations at once. A single poisoned dependency, compromised maintainer account, or vendor update can affect software delivery, remote administration, and downstream operations. That makes the blast radius far larger than a normal endpoint or perimeter intrusion.

Q: What are the signs that a CI/CD supply chain compromise is already underway?

A: Common warning signs include new outbound connections from runners, secrets appearing in logs, unexpected use of trusted domains, and workflow behavior that no longer matches the established baseline. A clean pipeline usually shows stable network patterns and predictable execution. When those patterns change suddenly, teams should treat it as an active compromise signal.

Q: Should teams trust signed packages and actions by default?

A: No. Signing proves that something was signed, not that the signer, maintainer or build path remained uncompromised. Teams should pair signatures with provenance checks, maintainer assurance and least-privilege execution so that trust is conditional rather than automatic.

Technical breakdown

How supply chain attacks exploit trusted dependencies and build paths

A supply chain attack works by compromising something organisations already allow into their environment, such as a package repository, build step, update channel or third-party integration. The attacker does not need to break every target directly. Instead, malicious code, scripts or tokens are introduced at the upstream point and then inherited by many downstream consumers. That makes the attack scalable and harder to detect because the compromise often looks like normal software delivery. In identity terms, the real weakness is delegated trust with weak provenance checking. Practical implication: treat dependency acceptance and build execution as governed identity events, not as routine tooling activity.

Practical implication: verify provenance, signatures and maintainer trust before code or packages enter build and release pipelines.

Why CI/CD runners and developer tokens become the highest-value targets

CI/CD runners, developer accounts and automation tokens are attractive because they sit at the intersection of privileged execution and high-volume software movement. If an attacker can harvest secrets from runner memory, logs or post-install scripts, those credentials can be reused to publish malicious packages, access cloud services or move laterally into repositories. This is where supply chain compromise turns into identity abuse: the attacker is not only inserting code, but also taking over the machine and non-human identities that move code forward. Practical implication: separate build identity from human identity and remove long-lived secrets from pipelines wherever possible.

Practical implication: isolate CI/CD identities, reduce token scope and eliminate persistent secrets from build runners.

What zero trust means for software supply chain governance

Zero trust in this context does not mean distrusting all software equally. It means verifying each upstream component, maintainer action and integration step before allowing it to influence your environment. The article’s examples show why static allowlisting is not enough on its own. A package can be legitimate for years, then become the delivery vehicle for malicious scripts or poisoned updates. Governance therefore has to extend beyond the repository itself to the provenance of the artifact, the identity of the maintainer and the runtime permissions of the delivery pipeline. Practical implication: make trust conditional at every stage of ingestion and release.

Practical implication: apply conditional verification at ingestion, build and deployment stages instead of assuming prior trust persists.

Threat narrative

Attacker objective: The attacker aims to turn trusted software distribution into a reusable path for code injection, secret theft and downstream compromise.

1. Entry occurs when attackers compromise a maintainer account, package, build process or third-party integration that downstream organisations already trust.
2. Credential access follows when malicious scripts, poisoned updates or runner memory dumps expose developer tokens, cloud credentials or API secrets.
3. Escalation and lateral movement happen as those stolen secrets are reused to publish more malicious code, access repositories or reach connected cloud services.
4. Impact is downstream compromise at scale, where many organisations inherit the malicious artefact or exposed credentials without being the original target.

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.
• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.

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 security is now an identity governance problem, not only a code integrity problem. The article is really about who or what is trusted to introduce change into software delivery, and under what controls. Once a package, maintainer, runner or SaaS integration can act with inherited trust, the organisation has an identity issue on its hands. Practitioners should govern upstream access as part of the software supply chain.

Trust without provenance is an unbounded blast radius. The SolarWinds and npm examples show that one compromised upstream identity can affect thousands of downstream environments. That changes the governance unit from the single application to the entire distribution chain. The practitioner conclusion is straightforward: provenance, not convenience, has to become the default gate for software intake.

Long-lived CI/CD credentials are the weakest link in modern delivery pipelines. Build systems often hold secrets that outlive the job, the run or the dependency that triggered them. That persistence lets a supply chain compromise become a reusable credential event instead of a one-time code problem. Teams should measure how much standing access their pipelines still carry.

Third-party software should be treated as a delegated identity with lifecycle risk. Packages, plugins and external services are often trusted as if they were static assets, but the article shows they behave more like accounts that can be compromised, repurposed or poisoned. That is why offboarding, revocation and provenance review matter just as much for software dependencies as for contractors. The practitioner takeaway is to manage dependencies as living identities, not frozen objects.

Identity blast radius is the right concept for supply chain defence. The organisation is not just exposed to the initial compromise, but to how far a stolen token, signed update or malicious dependency can travel once accepted. This is where IAM, DevOps governance and cloud security converge. The control objective is to shrink the distance between trust decision and execution, then to limit what each trusted actor can reach.

From our research library:

• Software supply chain attacks were projected to cost organisations $60 billion in 2025.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Identity blast radius: supply chain defence fails when organisations focus on the malicious artifact but ignore how far its trust can travel through build, deployment and integration paths. The relevant programme question is not whether a dependency is popular, but how much execution authority it inherits once accepted.

Pipeline access should be treated as a privileged identity problem, not a tooling problem. If a runner can read secrets, publish packages or modify release artifacts, then compromise of that runner becomes a governance issue across DevOps and IAM.

Third-party software now behaves like a delegated identity with its own lifecycle risk. That makes revocation, provenance review and ownership assignment part of supply chain security, not separate hygiene tasks.

For practitioners

• Define upstream trust boundaries Inventory which dependencies, repositories, build tools, maintainers and SaaS integrations can introduce code or secrets into production paths. Assign owners to each trust boundary so that reviews, revocation and exception handling are explicit rather than assumed.
• Remove standing secrets from pipelines Replace persistent CI/CD credentials with short-lived, task-scoped access where possible, and treat runner memory, logs and post-install execution as secret exposure points. Limit the permissions of build identities to only the repositories and services they actually need.
• Verify provenance before execution Require signature checks, maintainer validation and artifact provenance review before packages, actions or containers are allowed into build and deployment workflows. Block unsigned or unverified artifacts from auto-executing in trusted pipelines.
• Isolate build and release identities Separate human developer access from automation access, and keep build credentials unable to publish, deploy or modify unrelated systems. When a runner is compromised, the attacker should not inherit the ability to move laterally across the software delivery chain.
• Monitor for unusual release behaviour Alert on unexpected dependency updates, outbound connections from build systems, secret-dumping patterns in logs and new package versions published from atypical accounts. Supply chain abuse often announces itself as a small deviation before it becomes a widespread compromise.

Key takeaways

• Supply chain attacks succeed because defenders still over-trust upstream software, packages and automation paths.
• The article’s examples show that a single compromised maintainer, build process or CI/CD action can expose secrets and spread malicious code broadly.
• The limiting control is not just better scanning, but tighter governance of provenance, pipeline identity and the permissions trusted software inherits.

Key terms

• Supply chain attack path: A supply chain attack path is any route by which a trusted external tool, dependency or partner becomes the mechanism for compromise. It matters because attackers often abuse legitimate integrations instead of exploiting the core system directly, which makes detection and containment harder.
• Build provenance: Build provenance is the evidence chain showing where a software artefact came from, how it was assembled, and which identities and keys were used. It is essential when teams need to prove that an embedded release was produced from trusted source and controlled inputs.
• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.

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.