Software supply chain attacks exploit trust, not just vulnerabilities

At a glance

What this is: ArmorCode argues that software supply chain attacks work by abusing trust relationships in dependencies, build systems, and package registries rather than by attacking the perimeter directly.

Why it matters: IAM and NHI practitioners should care because supply chains increasingly move through trusted credentials, maintainer accounts, and automated update paths that behave like non-human access pathways.

By the numbers:

• The average cost of a single breach has now reached $4.99 million, a 12% increase over last year.
• The September 2025 NPM supply chain attack compromised at least 27 packages within hours.
• Attackers used 440+ packages across 2,200+ versions within an hour in the August 2026 Shai-Hulud resurgence.

Context

Software supply chain risk is a governance problem as much as a technical one. When trust is delegated to third-party components, build systems, registries, and automated update paths, the control question shifts from "is this code vulnerable?" to "who or what was allowed to publish, sign, and distribute it?" That makes the topic relevant to identity, access, and non-human identity governance.

ArmorCode frames the issue through recent attacks, but the pattern is broader than any single incident. Supply chain compromise succeeds when organisations can no longer see which identities, credentials, and update channels are acting on their behalf, which is why fragmented tooling and severity-only triage leave material exposure unresolved.

Key questions

Q: What breaks when supply chain identities are not governed like privileged assets?

A: The delivery path becomes an attacker-controlled trust channel. A single exposed token or publishing credential can let malicious code move through repositories, registries, and build systems without triggering the kind of scrutiny applied to human accounts. That is why software delivery identities need the same separation, review, and revocation discipline as other privileged NHI assets.

Q: Why do supply chain attacks stay effective even with vulnerability scanners?

A: Scanners are useful, but they cannot by themselves determine whether a dependency is reachable, deployed, or being pulled into production through automation. Supply chain attacks succeed because teams often prioritise on severity alone instead of exploitability, exposure, and business context. That leaves the most dangerous components under-addressed.

Q: How do security teams know whether a supply chain alert is actually urgent?

A: Teams know it is urgent when the affected component is reachable in production, sits on a trusted release path, or can influence customer-facing systems. Severity alone is not enough. The practical test is whether the exposure can propagate through your actual software delivery chain, not whether it looks bad in isolation.

Q: Should organisations treat CI/CD runners as privileged identities?

A: Yes. Runners and workflows often hold the authority to deploy, read secrets, and call cloud APIs, so they should be governed like privileged non-human identities. That means least privilege, narrow trust policies, logging, and revocation processes that assume compromise is possible.

Technical breakdown

Trusted update paths as an attack surface

Software supply chain attacks work because modern delivery pipelines are built around implicit trust. Package registries, CI/CD runners, build servers, and signed updates all move code from upstream to downstream under the assumption that the publisher is legitimate. Once an attacker compromises a maintainer account, build environment, or registry credential, the malicious artifact can inherit that trust and travel through normal deployment channels. The security failure is not simply the vulnerability itself but the trust transitivity built into software distribution. In practice, this means the attack path often looks like valid software operations until after the compromise has already propagated.

Practical implication: Map every publishing and update trust relationship so compromised upstream identities can be revoked before malicious artifacts propagate.

Why CVSS-only prioritisation misses supply chain exposure

CVSS scores describe theoretical severity, not whether a component is actually reachable, deployed, or exploited in your environment. That is why supply chain programs that rely on scanner output alone end up with long backlogs of "critical" issues and poor focus. Effective prioritisation has to combine component inventory, reachability, exploit intelligence, business criticality, and whether the affected dependency is present in production or only in a non-exposed path. For supply chain events, the central question is not how bad the vulnerability looks in isolation, but whether it can affect a real workload, release pipeline, or customer-facing system.

Practical implication: Correlate SBOM, reachability, and threat intelligence data before assigning remediation priority.

Container images and CI/CD runners extend the trust boundary

Containers and build infrastructure are often treated as operational layers, but they are also identity-rich control points. CI/CD runners execute with service credentials, package managers pull from registries, and base images inherit libraries that may never be visible in application code reviews. If those layers are not governed as part of the supply chain, hidden dependencies and embedded secrets can become the real compromise path. This is where supply chain security intersects directly with NHI governance: the workload identities, tokens, and automation accounts that move through the pipeline are part of the trust model, not separate from it.

Practical implication: Treat CI/CD runners, build tokens, and base images as governed non-human identities with explicit inventory and access scope.

Threat narrative

Attacker objective: The attacker aims to turn trusted software distribution into a high-scale delivery path for malware, data theft, or persistence.

1. Entry begins when attackers compromise a maintainer account, phishing target, or upstream build process rather than the enterprise perimeter.
2. Credential access or trust abuse lets the attacker use legitimate publishing rights, signed update channels, or registry access to inject malicious code.
3. Impact occurs when downstream users automatically pull the tainted package or update, spreading malware or backdoors across many organisations through normal software delivery.

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

Trust, not vulnerability, is the true unit of compromise in supply chain attacks. The article is right to move the discussion away from perimeter defence and into the mechanics of software distribution. Once a maintainer account, registry credential, or build system is trusted by default, an attacker does not need to break in twice. The practitioner implication is to govern publishing trust as tightly as production access.

Supply chain security now includes non-human identity governance. Build runners, package publishers, automation tokens, and signing workflows behave like non-human identities even when teams do not label them that way. If those identities are not inventoried, scoped, and lifecycle-managed, organisations cannot tell legitimate automation from hostile automation. The implication is that NHI control must extend into CI/CD and release pipelines, not stop at application authentication.

CVSS-first remediation creates a false sense of control. Supply chain exposure is defined by reachability, trust path, and business impact, not by severity labels alone. That means teams can have dozens of urgent findings and still miss the one component that would actually propagate into production. The practitioner implication is to prioritise by exposure path and operational criticality, not scanner urgency.

Trust chain visibility is the named concept this article surfaces. The security problem is not only whether a package is vulnerable, but whether teams can trace every trust hop from maintainer to registry to runner to production. That visibility is now a governance requirement because the attack surface is the chain itself. The implication is to make trust-chain mapping a standing control, not an ad hoc investigation step.

Automated remediation only works when the organisation has already normalised its software trust graph. The article shows that speed matters, but speed without inventory and context just accelerates confusion. If teams do not know which identities and dependencies are in play, remediation becomes reactive triage instead of controlled response. The implication is to connect inventory, prioritisation, and change execution under one operating model.

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.
• Compromised credentials take an average of 246 days to identify and contain, according to IBM's 2025 Cost of a Data Breach Report.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Trust chain visibility is becoming a control requirement, not an investigation luxury. Teams that cannot trace package, build, and release trust paths will keep discovering compromise only after propagation has begun. The operational shift is to map trust edges the same way security teams map attack paths, then tie that mapping to change control and revocation.

CI/CD runners are part of the identity perimeter. They execute code, hold credentials, and interact with registries, which means they can be abused like any other privileged non-human actor. The practical consequence is that pipeline identities need lifecycle governance, not informal ownership.

Supply chain resilience depends on contextual prioritisation. When only 2 to 7 percent of published CVEs are actually exploited in the wild, the answer is not more alerts but better filtering of what can truly reach production. The reader should expect supply chain programmes to converge on exposure graphs, business criticality, and faster revocation workflows.

For practitioners

• Define the software trust graph Inventory package registries, build systems, signing workflows, CI/CD runners, and maintainer identities so you can see every upstream trust relationship that can affect production.
• Govern non-human identities in pipelines Treat automation accounts, publishing tokens, and runner credentials as non-human identities with explicit ownership, least privilege, and revocation paths.
• Prioritise by exposure, not severity alone Combine SBOM data, reachability, exploit intelligence, and business criticality before assigning remediation work to a supply chain finding.
• Correlate container and dependency findings Use a single control plane to connect container base image issues, dependency advisories, and application runtime context so duplicated alerts do not hide the real risk.
• Test your maintainer compromise response Exercise the sequence for revoking registry access, invalidating signing credentials, and halting automated updates when a trusted publisher is suspected of compromise.

Key takeaways

• Supply chain attacks succeed because trusted publishing and update channels can be turned into malware delivery paths without breaking perimeter defences.
• The article’s examples show that phishing, maintainer compromise, and build-system abuse can move threats from a single trust point to thousands of downstream environments.
• The control gap is governance of the trust graph, which means inventory, context, and revocation need to work together before malicious updates propagate.

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.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Trust graph: The map of how identities connect to each other and to the systems they can reach. A trust graph helps teams see inherited access, hidden pivots, and the points where a compromised credential could unlock far more than its original purpose implied.
• 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.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a form that fits practitioners building or reviewing control programmes. It helps security teams connect identity governance to the broader operational controls their environments depend on.