ANALYSIS

When Someone Else's Security Becomes Your Breach: Third-Party Risk and Supply Chain Attacks Are Not the Same Problem

May 2026  ·  9 min read

Privacy Insight Solutions OSINT & Executive Privacy Analysts

The word "vendor" covers a lot of ground. A law firm using a cloud document platform. A retailer using a third-party logistics provider. A bank running code written by an open-source library maintained by a developer they have never met. All of them are vendors. The risk each of them carries is not the same.

"Third-party risk" and "supply chain risk" appear interchangeably in board presentations, vendor questionnaires, and regulatory frameworks. NIS2 Article 21(2)(d) lists supply-chain security as a required risk-management measure in the same sentence that covers everything from continuity testing to access controls. Most vendor risk programmes treat them as variations of the same checklist item.

They describe opposite problems. Understanding which one you have — after an incident or before one — changes what you check, what you investigate, and what you find.

Why the vocabulary conflation matters

The standard vendor risk questionnaire asks a supplier to self-report their security posture. The implicit model is that risk runs in one direction: from the supplier's failure toward your organisation. That assumption holds for some relationships and fails entirely for others.

The conflation matters most in the moment after something goes wrong. An organisation that cannot distinguish between "our vendor was breached and our data was in their environment" and "our vendor's software was compromised and ran on our infrastructure" will investigate in the wrong place, respond in the wrong order, and miss the artifacts that require immediate action.

The distinction is structural. It follows the direction in which trust flows.

Third-party risk: the OUT model

Third-party risk describes what happens when your data lives in someone else's environment. The trust flows out: you have placed records, credentials, or information with a vendor, and that vendor's security posture determines what happens to those assets.

The vendor holds your data as a function of the relationship. A managed payroll provider holds employee records. A CRM platform holds client contact data. A logistics partner holds order histories and delivery addresses. A law firm holds privileged documents for every client whose matter it has handled. In each case, your organisation is not the one controlling the environment the data sits in.

When that vendor is breached, the exposure is yours — regardless of whether your own systems were touched. Canada Goose's public statement after ShinyHunters published 581,877 customer records in February 2026 was technically accurate: there was no indication of a breach of their own systems. The data had moved into a third-party environment in the normal course of business. The breach happened there. The notification timeline, the scope of what was taken, and the decision about what to disclose were all set by a party Canada Goose did not control. The law firm breach pattern — documented across multiple incidents in the US, UK, and Australia — follows the same model: client data at rest in a privileged professional environment, circulating after that environment is compromised, with the client learning about it through a statutory notification rather than their own detection.

The OUT model has a particular visibility problem. Because the breach happens at the vendor's end, your organisation may not learn about it for months. The data has already begun circulating before the notification arrives — and in some cases, before the vendor has confirmed the scope of what was taken. The gap between breach and notification in third-party incidents has, in documented cases, exceeded twelve months.

What a third-party breach puts in circulation

The artifacts from an OUT breach are primarily data records. Names, email addresses, professional histories, order records, partial financial data, and — critically — any credentials your staff used to authenticate to the vendor's platform.

Credential pairs for vendor portals are durable. A procurement manager who used the same password across a supplier's portal and their corporate email is exposed not just in the vendor breach, but in every system that credential touches downstream. The vendor breach becomes the entry point; the circulating credential pair becomes the access tool used months later when the credential appears in a stealer log index.

Breached professional contact data also feeds targeting. Billing contacts, account managers, and project leads whose details were held in a vendor's CRM become known quantities in the breach market. Their professional relationships — inferred from the vendor's data structure — are visible to anyone who purchases the dataset.

The investigation surface for an OUT breach starts with the relationship: what data was shared, through which accounts, and under what access terms. That map determines what is now in circulation and where it is likely to appear.

Supply chain risk: the IN model

Supply chain risk describes the opposite movement. The trust flows in: you have integrated a vendor's code, tool, or component into your own environment, and that component's integrity determines whether your own infrastructure is clean.

You are not the victim of someone else's breach. You are the execution environment for the attacker's payload.

The European Commission's April 2026 incident is the clearest recent example at an institutional scale. A poisoned version of Trivy — a widely trusted open-source vulnerability scanner — was distributed through a dependency channel the Commission's cloud team had no reason to distrust. The tool ran with the access it had legitimately been granted. It used that access to exfiltrate AWS credentials. The attack originated entirely outside the Commission's perimeter and executed entirely inside it. There was no lateral movement from an external attacker working through the network. The attacker's code arrived as a trusted update. The incident is covered in detail in How a Security Scanner Breached the European Commission.

The same structure appeared in the TeamPCP/UNC6780 campaign documented by GTIG in May 2026: a poisoned VS Code extension, distributed through a legitimate marketplace, harvested credentials from developer environments at organisations that had authorised the extension to run. The extension was the trusted component. The authorisation was the mechanism.

The IN model is not limited to sophisticated nation-state operations or open-source dependencies. It applies to any component whose integrity you cannot independently verify but whose execution you have authorised: browser extensions, third-party scripts loaded by your web properties, CI/CD plugins, monitoring agents, and update channels for commercial software. The common thread is that the code ran inside your perimeter with your permission.

If a tool or component your organisation uses has been identified in a supply chain campaign, a Corporate Audit establishes what it had access to and what was taken during the window it ran.

Talk to an Analyst

What a supply chain compromise produces

The artifacts from an IN compromise differ in kind from those produced by an OUT breach. The attacker was inside your environment. What they harvested depends on what the compromised component could reach.

Typically: credentials for the systems the tool was authorised to access, session tokens active during the compromise window, API keys and service account credentials the component interacted with, and — where the tool had broad permissions — the ability to move laterally before the compromise was identified.

DKIM signing keys, as in the Trivy case, represent a specific category of artifact. A DKIM key in attacker hands produces outbound email that is cryptographically indistinguishable from legitimate mail. That is not a data leak that can be addressed by breach notification. It is an active capability that persists until the key is rotated and that enables phishing campaigns under your own domain — against your clients, your suppliers, and your staff.

The response window matters. Mandiant's M-Trends 2026 report documents a median of 22 seconds between initial access and credential handoff in automated campaigns. A supply chain compromise that exfiltrates credentials at 03:00 may result in those credentials being tested against your other systems before your security team begins work the following morning. The compromise and the exploitation are often separated by less time than your detection cycle.

The same vendor can carry both risks simultaneously

This is where the distinction becomes practically important to get right.

A SaaS vendor — a CRM platform, a cloud collaboration tool, a security product — presents both models at once. They hold data you have stored in their environment (OUT risk). They also ship client-side code that runs in your browser, on your endpoints, or in your build pipeline (IN risk).

A breach at their data layer is an OUT event: your stored records circulate. A compromise of their software distribution is an IN event: code running on your systems executes with the permissions you granted it.

Salesforce's 2025 Aura framework exposure — which ShinyHunters exploited across multiple tenant environments — illustrated the dual-model problem. Tenant data was accessed (OUT), but the mechanism involved the platform's own query infrastructure rather than any individual tenant's misconfiguration (IN-adjacent). Affected organisations needed to audit both the data held in their Salesforce environment and the API tokens and integrations they had granted the platform — two different scoping questions, requiring two different investigation approaches.

An organisation that treats these as the same risk will scope one investigation, miss the other, and later discover the gap when a downstream incident surfaces what was left unchecked.

What a Corporate Audit maps for each type

The investigation surfaces for OUT and IN breaches are structurally different, and scoping starts with establishing which applies.

For an OUT breach, the relevant surface is what data was held at the vendor, which credential pairs were in that environment, and where those artifacts are now circulating. This requires mapping the vendor relationship — what categories of data were shared, under what access terms, and through which accounts — and then checking exposure markets and stealer log indexes where that material would appear. The investigation works backward from the breach to the data, and forward from the data to its downstream uses.

For an IN compromise, the relevant surface is what the compromised component had access to, what it could have harvested during the window it ran, and whether any of those credentials or tokens have been used since. This is a different investigation — it starts with access permissions rather than data categories, and it works forward from the compromise point rather than backward from circulating records. Rotation decisions depend on knowing what was in scope, not just what was found in a market.

A Corporate Audit scopes both. The classification — which model applies, or whether both apply — determines what is checked, in what order, and what remediation looks like.

Understanding the direction of trust is where the scoping begins.

Sources

Share this briefing

If this was useful, sharing it helps others protect themselves. It also helps keep the intelligence briefings free.