TL;DR: Supply chain attacks now exploit trusted vendors, upstream dependencies, and build pipelines to bypass perimeter controls, according to Torq’s analysis of software, hardware, and service-provider compromise. The governance gap is no longer awareness but the ability to verify provenance, restrict vendor access, and isolate compromised pathways at machine speed.
At a glance
What this is: Torq’s analysis says supply chain attacks now move through trusted vendors, upstream dependencies, and build pipelines, so verification matters more than assumed trust.
Why it matters: This matters because IAM, PAM, and security operations teams need to control vendor access, revoke compromised pathways quickly, and treat external trust as a continuously verified state.
Context
Supply chain risk is a governance problem as much as a technical one. The issue is not simply that vendors exist, but that business efficiency often creates broad trust paths across software delivery, remote access, and third-party operations that attackers can abuse.
In this article, Torq frames the failure as overreliance on static trust and slow review cycles. That creates a direct identity and access management angle because vendor accounts, service accounts, and build runners become the channels through which compromise spreads.
The pattern is now common enough that it should be treated as an operating condition, not an edge case. Organisations that still govern suppliers as periodic paperwork problems are behind the threat model.
Key questions
Q: How should security teams reduce supply chain risk when third party tools are trusted by default?
A: Security teams should treat upstream suppliers as part of their own attack surface, then reduce blind trust with vendor risk management, contractual security requirements, zero trust validation, and stronger visibility across endpoints and networks. The goal is to make trust earned and continuously verified, not assumed. Teams should also review tool exceptions carefully, because overly permissive allowances often create the gap attackers exploit.
Q: Why do third-party accounts and build pipelines create such a large attack surface?
A: Because they often carry delegated authority into multiple downstream systems. A compromised vendor identity or CI/CD runner can move through signed updates, network access, or service credentials without triggering the same alarms as a direct intrusion. Broad trust paths convert one breach into many possible points of impact.
Q: What breaks when provenance and vendor access are not continuously verified?
A: The organisation starts treating unverified artefacts and external identities as if they were internal and trustworthy. That breaks containment because malicious updates, injected dependencies, or abused service accounts can arrive through approved channels and bypass perimeter controls. Without continuous verification, the control plane lags behind the attack path.
Q: What should teams do when a supplier compromise is suspected?
A: Contain first, then investigate. Revoke vendor credentials, suspend active sessions, isolate affected build or delivery paths, and preserve telemetry before evidence disappears. The response goal is to sever trusted links quickly enough that downstream systems stop accepting compromised artefacts or access before the blast radius expands.
Technical breakdown
How trusted build paths become attack paths
Supply chain attacks work because software delivery already assumes trust at multiple handoff points. A build pipeline, upstream dependency, signed artifact, or vendor-controlled update channel can all become an insertion point if integrity is not continuously verified. Once malicious code is inserted into a trusted path, downstream systems often accept it as legitimate because the artefact looks normal and arrives through an authorised channel. That is why provenance, signing, and pipeline isolation matter more than perimeter inspection in this threat model.
Practical implication: Treat software provenance as a control plane, not a documentation exercise.
Why vendor access becomes an identity problem
When a supplier or MSP is compromised, the attacker rarely needs to break authentication in the traditional sense. They inherit existing trust relationships, often through long-lived credentials, VPN access, or delegated administrative paths. That turns third-party access into a privilege governance issue, not just a contractual one. The real risk is not only that a vendor can enter, but that their access is too broad, too persistent, or too hard to revoke when compromise is detected.
Practical implication: Restrict vendor identities to narrowly scoped, time-bound access with immediate revocation paths.
Why behavioural detection matters after trust fails
Preventive controls cannot catch every compromised dependency or vendor account, so runtime behaviour becomes the next line of defence. An update process that suddenly reaches an unusual external IP, a printer that queries a domain controller, or a payroll application that spawns a shell all indicate that a trusted path has been subverted. This is where machine identity and service account monitoring matter, because the compromise often shows up as misuse of a legitimate non-human identity rather than malware alone.
Practical implication: Baseline normal machine and vendor behaviour so deviations trigger high-severity response.
Threat narrative
Attacker objective: The objective is to turn trusted delivery and third-party access into a stealthy route for code execution, privilege use, and downstream compromise.
- Entry occurs through a trusted vendor account, upstream dependency, or build pipeline rather than direct perimeter intrusion.
- Credential or access abuse follows when the attacker uses inherited trust, signed updates, or delegated access to operate as legitimate infrastructure.
- Escalation and lateral movement happen as the malicious update or vendor channel reaches downstream systems with broader privilege than intended.
- Impact is achieved through malware deployment, data theft, or ransomware spread across environments that treated the supply path as trusted.
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.
- SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
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 governance has moved from due diligence to runtime verification. Static questionnaires and annual audits cannot keep pace with compromise that travels through trusted software, vendors, and build systems. The control question is no longer whether a supplier was reviewed, but whether their access, artefacts, and behaviour can be verified continuously. Practitioners should treat verification as an operating discipline, not a compliance afterthought.
Third-party access is now an identity governance problem, not just a procurement problem. Vendor accounts, MSP channels, CI/CD runners, and service identities all create high-trust pathways that attackers actively target. Once those identities are over-privileged or persistent, the organisation inherits their blast radius. Practitioners should shorten access duration, narrow scope, and make revocation operationally instantaneous.
Software provenance has become a board-level control concern. If production code cannot be tied back to a trusted build path, the organisation is relying on faith rather than evidence. SLSA-style provenance checks, isolated build environments, and controlled dependency intake now function as governance controls for software integrity. Practitioners should make provenance auditable at the point of release, not after an incident.
Supply chain attack response depends on the ability to sever trust links at machine speed. The critical failure mode is not only compromise, but delayed isolation once compromise is suspected. A mature programme needs the ability to revoke certificates, suspend vendor sessions, and quarantine affected paths without waiting for manual coordination. Practitioners should build response around containment of trusted pathways, not only detection of malicious binaries.
Cloud and identity teams need a shared model of trusted automation risk. Build runners, deployment tokens, and third-party service accounts are no longer background infrastructure. They are active non-human identities with business reach, and that makes them governance assets. Practitioners should bring NHI controls, vendor risk controls, and supply-chain assurance into the same 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.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Verified trust links are becoming the decisive control surface. The practical shift for security teams is to stop treating supplier access as a background governance issue and start treating it as a live attack path. That means continuous control over access, artefact provenance, and revocation, not periodic assurance.
Supply chain compromise now intersects directly with non-human identity governance. CI/CD runners, service accounts, and vendor credentials are often the real execution layer for trust abuse, so NHI governance has to extend beyond internal workloads. If those identities are not inventoried and controlled, verification remains partial.
Build and delivery pipelines need machine-speed containment. Manual approval steps are too slow when a malicious update or abused vendor channel is already in motion. The programme implication is clear: response automation must be able to quarantine paths, revoke credentials, and cut off external trust links immediately.
For practitioners
- Harden build and release pathways Isolate CI/CD runners, restrict who can modify pipelines, and require signed provenance checks before code reaches production.
- Reduce third-party access blast radius Scope vendor and MSP accounts to specific services, enforce MFA, and design immediate revocation for certificates, VPN sessions, and IAM roles.
- Continuously inventory external dependencies Track software, hardware, and vendor dependencies in real time so unknown or stale assets cannot remain trusted by default.
- Baseline normal machine behaviour Monitor service accounts, update processes, and vendor sessions for anomalies such as unexpected outbound connections or privilege drift.
- Pre-authorise containment playbooks Prepare automation that can block vendor IP ranges, disable accounts, and revoke access across affected systems as soon as compromise is confirmed.
Key takeaways
- Supply chain attacks succeed by abusing trusted delivery paths, not by defeating perimeter controls alone.
- The strongest evidence in this article is that third-party exposure and CI/CD compromise are central to modern attack propagation.
- Teams should tighten provenance, scope vendor access, and automate revocation so trust can be verified instead of assumed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party vendor accounts and MSP access are a central compromise path in this article. |
| NHI-05 — Overprivileged NHI | The article repeatedly shows that broad vendor and build access expands blast radius. | |
| NHI-07 — Long-Lived Secrets | The response model depends on revoking certificates, tokens, and other persistent credentials quickly. | |
| Recommendation — Audit third-party identities for exposure, scope, and revocation readiness before they become an attack path. Reduce standing privileges for vendor, pipeline, and service identities to the smallest workable scope. Replace long-lived vendor and pipeline secrets with short-lived credentials and fast revocation processes. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack pattern relies on abusing trusted credentials to move through downstream environments. |
| Recommendation — Map supply-chain abuse to credential access and lateral movement to prioritise detections on trusted channels. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article centres on controlling and revoking third-party and service accounts quickly. |
| Recommendation — Apply account management controls to vendor and service identities so access can be scoped and removed fast. | ||
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.
- Provenance: Provenance is the traceable history of where a software artifact came from, who approved it, and what controls were applied along the way. In container security, provenance supports trust decisions because it links delivery steps to accountable identities and review points.
- Third-Party Access: Third-party access is access granted to vendors, contractors, or support partners who are not direct employees of the organisation. It is higher risk than internal access because accountability, device assurance, and access duration are harder to control, so it usually requires tighter time limits and stronger auditability.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need a stronger operating model. It is designed for teams that must govern non-human identities alongside broader security and access controls.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org