Third parties now appear in nearly half of breaches. Attackers rarely defeat the vendor’s contract controls. They use the access a vendor, app or package already holds. A program built on questionnaires does not see that access.
Key judgments
Observed means a named source reported it. Assessed means it is our reading of that evidence.
| # | Judgment | Confidence |
|---|---|---|
| 1 | Third-party exposure is increasingly about delegated technical access, such as tokens, API keys, connected apps and build pipelines, more than about a supplier’s overall security posture. (Assessed from observed campaigns) | Medium |
| 2 | Attackers favor pivots that scale. One compromised provider or package can open many downstream victims at once. (Observed) | High |
| 3 | Your own employees are part of the third-party surface. A user approving a malicious connected app grants outside access without any vendor failing. (Observed) | Medium |
| 4 | Ranking suppliers by spend or business criticality misses small tools that hold broad access. (Assessed) | Medium |
The context
Verizon’s latest Data Breach Investigations Report puts third-party involvement at 48% of breaches, up from 30% in the previous edition. WaterISAC’s summary notes the pattern behind it: improperly secured cloud accounts, weak passwords and MFA gaps in vendor environments. The figure depends on how the report defines third-party involvement, so it is a direction, not a precise exposure measure.
Observed patterns
| Pattern | What happens | Reporting | What limits the damage |
|---|---|---|---|
| Integration-token theft | Attackers compromise a SaaS provider and use stored OAuth tokens to reach customer tenants. In the Salesloft Drift case, tokens were used to export data from many Salesforce orgs. The actor searched the data for AWS keys and Snowflake credentials. Google advised treating all tokens connected to Drift as potentially compromised, and the actor also used tokens for a small number of Google Workspace mailboxes. | Google Threat Intelligence Group, UNC6395 | Narrow token scopes, IP restrictions, short sessions, activity monitoring, and a revocation process that has been tested. |
| Software dependency compromise | A self-replicating worm compromised more than 500 npm packages. It harvested GitHub tokens and AWS, Google Cloud and Azure keys from infected developer environments and used the developer’s npm identity to publish more tainted packages. | CISA alert on Shai-Hulud | Dependency pinning, phishing-resistant MFA on developer accounts, secret rotation, ability to search for cached packages. |
| User-approved malicious app | Voice phishing persuades an employee to authorize a modified Data Loader as a connected app. Data is exported in bulk. No vendor is breached; the customer grants the access. | Google Threat Intelligence Group, UNC6040 | Control over who can approve apps, IP limits, export-permission limits, monitoring of large downloads. |
| Stolen data used as the next intrusion’s input | Data taken through one supplier route is mined for keys and passwords that open other systems. | Drift activity, as reported by Google | Secret scanning of CRM, ticket and support data; rapid rotation. |
In none of these cases was a supplier questionnaire the control that mattered. The questions that mattered were practical: what can this token do, from where, for how long, and how quickly can we shut it off?
How to rank the exposure
Rank dependencies by the access they hold, then by how well you can contain them. Five questions do most of the work.
| Question | Why it matters |
|---|---|
| What can it read, write or delete? | A read-only token on low-sensitivity data is a different risk from a full-access token on customer records. |
| Is the credential bound? | IP restrictions, short sessions and narrow scopes limit what a stolen token can do. |
| How fast can we revoke and rotate? | Time to revoke is the part of the response you control. Measure it. |
| Can we see its activity in our own logs? | If the only record is in the vendor’s system, you cannot scope an incident yourself. |
| How many customers share this exposure? | Concentration raises the odds that you are one of many targets and slows vendor response. |
Regulatory context
Regimes such as the EU’s NIS2 Directive, which lists supply-chain security among required risk-management measures, and the Digital Operational Resilience Act, which requires financial entities to keep a register of their ICT third-party arrangements, push organizations toward knowing their suppliers. Applicability depends on the entity and sector, so check it for yours. A register of contracts meets the governance requirement. It does not tell you which integrations carry live tokens into your data. That is the gap the patterns above exploit.
What defenders should change
-
Inventory non-human access. List every OAuth app, API key, service account and build integration with its scope, owner and data reach.
-
Tier by access, not spend. Put tools with broad scopes and sensitive data reach in the top tier even when the contract is small.
-
Rehearse revocation. For the ten most connected integrations, time how long it takes to revoke tokens and rotate dependent secrets. Use Google’s Drift response steps as a template.
-
Constrain by default. Apply IP allowlists, least-privilege scopes and short sessions. Limit who can approve new apps.
-
Hunt in the connected-app layer. Look for bulk queries and exports from integration users, and scan your own SaaS data for stored credentials.
-
Harden the developer supply chain. Pin dependencies, require phishing-resistant MFA on developer and registry accounts, rotate secrets after any dependency incident, and keep the ability to search for cached packages.
-
Write expectations into contracts. Ask for prompt notice of credential or token compromise, with a defined time window.
What we do not know
Vendors disclose the scope of token compromises slowly and unevenly, so the first public picture is usually incomplete. The Verizon figure and the incident reports measure different things and cannot be combined. The campaigns above are well-documented rather than typical. We have no dependable data on how many organizations hold high-risk integrations they do not know about.
What to do with this
Pick your five most connected SaaS platforms and list every integration that holds a token into each one. Then ask who owns it and how long revocation would take. The answers rank your exposure better than a questionnaire score.
Sources
-
WaterISAC, Summary of Verizon’s Data Breach Investigations Report
-
Google Cloud Threat Intelligence, Data theft from Salesforce instances via Salesloft Drift (UNC6395)
-
Google Cloud Threat Intelligence, UNC6040 voice phishing and data extortion analysis
-
CISA, Widespread supply chain compromise impacting the npm ecosystem
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionSecure & ComplyTurn regulatory duties into controls that hold up.See how we work →Related service
Third-Party & Supply-Chain Risk
Use this to prioritize supplier and dependency risk.