Supply chain attacks and third-party risk are often mentioned in the same breath. That is understandable: suppliers, service providers and software vendors can play a part in both. Yet the two terms describe different levels. Treat them as the same, and you lose exactly the distinction that effective risk management depends on.
“Third party” describes a relationship. “Supply chain attack” describes an attack mechanism.
Two questions
The first view asks: whom do we depend on? Which services do we obtain? What responsibilities do we carry, and what influence do we have? The second asks: how is a supply or trust relationship used for an attack? Which trust artifact, such as a package, an update, a build or a service response, or which party issuing it, was subverted before we accepted it? Which boundary is crossed, and which system is compromised?
These questions complement each other. They are not interchangeable, and the difference cuts both ways: not every third-party risk is a supply chain attack, and not every attack that involves a supplier is one either.
Two cases that pull the terms apart
A SaaS provider can fail because of a hardware defect and interrupt our business. The external dependency matters; there is no supply chain attack. Conversely, tampered software can reach our environment through a transitive open-source dependency, although we have no contract of any kind with the maintainer concerned.
Read with TLCTC, the two cases sit on different rows. The hardware defect has no actor, so the first question of the scope test already ends it: a system failure, operational risk, no cluster.[1] The event happens in the provider’s sphere and reaches us as data we cannot get to and a business process that stops. Its third-party relevance is total, and there is nothing in it for an attack taxonomy to classify.
The tampered package is the opposite. Someone subverted it before we accepted it, and the step that counts is the moment our build or installation treats it as authoritative, the Trust Acceptance Event. When its code then runs, that is a separate step:[1]
#10 ||[dev][@External→@Org]|| → #7
The source sphere is @External, not @Vendor. A responsibility sphere is not a contract, and this maintainer appears in no supplier register. The supplier inventory and the attack path do not cover each other in either direction.[3]
“Software supplier” does not explain the exposure
Calling someone a “software supplier” does not yet explain our exposure either. With installed software, we run supplied code in an environment we operate. With SaaS, we entrust data and processing to a service operated by someone else. With PaaS, we run our own application on a platform operated by someone else. The integration determines where a compromise can take effect, and which controls we can enforce ourselves.
| Integration | What we accept | Where it takes effect | Our own controls |
|---|---|---|---|
| Installed software | Supplied code, run in our environment | In our domain. A subverted release or update is #10 at the moment we install or apply it, usually followed by #7. | Provenance and signature checks, version pinning, staged rollout, the privileges the component runs with |
| SaaS | An externally operated service, entrusted with our data and processing | Mostly in the provider’s sphere. Our data can be hit there without any system of ours being compromised. #10 only where something the service delivers becomes authoritative inside our domain. | Which data we hand over, the scopes of integrations and tokens, our own copies, the exit |
| PaaS | A platform operated by someone else, running our application | Below our application. A compromise of the platform itself sits in the provider’s sphere; #10 where a subverted platform artifact, such as a base image or runtime update, is accepted into our deployment. | What we build, pin and verify ourselves; how our workloads are separated |
The table illustrates the point; it is not a classification rule. Each step is still classified by what made it succeed.
A vendor rating is not a path
A supplier rating therefore does not answer whether a specific attack path is adequately controlled. For that, we have to look at the chain from cause to system event, to data event, to business impact. A system event at the provider can already hit our data and our business without any of our internal systems being compromised.
In TLCTC this chain is the consequence side of the bow-tie: SRE → DRE → BRE, with a Δt on every causal transition, the window in which detection and response can still act.[1] If the provider’s server is exploited and our records are read there, the path might be #2 → #1 + [DRE: C]. Every step runs in the provider’s sphere. The data event is on our data, and the business event is in our business. A rating says how well a supplier is run. It does not say which of these transitions our own controls can still interrupt, or how much time they have to do it.
The distinction cuts both ways
Not every attack that involves a supplier is a supply chain attack either. Since v2.6, a #10 step requires that the trust artifact, or the third party issuing it, was subverted before we accepted it (R-SUPPLY).[1] Three neighbouring cases fail that test:
- A flaw in a legitimately supplied component is classified where it is exploited. Log4Shell is #2: where flawed code came from is location, not generic vulnerability.
- A partner’s stolen credential, presented to sign in to our systems, is #4
||[auth][@External→@Org]||, however it was obtained. The Key Eater campaign ran from MSPs into their customers without a single #10 step.[4] - A supplier’s outage that reaches us across the boundary is third-party failure, not #10.
The falsifier is short: remove the attacker’s subversion of the third party, not the third party itself. If the step still succeeds, it was never #10.[1]
Where TLCTC puts what
This is where separating the two pays off. In a TLCTC-based view, the cluster classifies the attack step by its cause: for #10, the generic vulnerability is that trust in third-party components and update channels can be subverted. The third-party relationship adds the context: who is involved, what depends on whom, and who is responsible for which control. Controls are placed where they are meant to prevent an attack step or to limit its consequences.
The core paper states the relationship in one sentence: “Third party is a modifier over all four rows, not a fifth row: any of them may occur in another responsibility sphere and be honoured across a trust boundary, which the notation already carries as the domain-boundary operator.” Attack, abuse of rights, failure and error in use can all happen at a supplier. #10 is only the attack-row case, at the moment of trust acceptance.[1]
Third-party risk management can organise contracts, evidence, escalation paths and requirements for this. It remains an important management function; the application companion places the TPRM programme among the governance anchors of #10.[2] The term becomes misleading once the involvement of a third party is treated as a sufficient description of the risk.
The provider that holds our data and the provider whose update we install can be the same company. In the register that is two risks: a dependency whose failure or breach reaches our data at their site, and a trust acceptance in our own domain that an attacker can subvert. They have different owners, different controls and different appetite statements.
Two levels, one scenario
My supply chain attack risk is not my “third-party risk”. Both views can concern the same scenario; they describe it at different levels.
Sources
- [1] TLCTC v2.7 core paper: §3.4 (cause–event–consequence model, Δt), §3.5 (cause-side partition, R-SCOPE, third party as a modifier over all four rows), §4 (#10 Supply Chain Attack, subversion test and falsifiability), §6.1 (R-SUPPLY), §7.3 (domain boundary operator). Glossary: #10 Supply Chain Attack, Trust Acceptance Event, R-SUPPLY, third-party trust link, cause-side partition, system failure, domain boundary operator.
- [2] TLCTC v2.7 application companion, §8.2 (GOVERN: the management-system layer).
- [3] Notating Supply-Chain Attack Paths: Where #10 Goes and What the Boundary Operator Carries and Anatomy of a Worm: The 2025 npm Supply Chain Attacks (TLCTC blog).
- [4] Key Eater Is Not a Worm. It Is Axiom X in a Loop. (TLCTC blog, 5 November 2026), and the TLCTC mapping of MITRE ATT&CK Enterprise v20, where T1199 Trusted Relationship is
#4 | #10.
TLCTC Framework · v2.7 · CC BY 4.0