Third-Party Security: Now One of the Leading Entry Points for Attackers
An organization can encrypt its data, segment its network, patch its servers, and train its teams: it still has a blind spot it does not directly control. Its vendors, its SaaS providers, its third-party integrations. And that is precisely where attackers increasingly get in.
The finding is no longer anecdotal, it is statistical. Verizon's 2025 DBIR, which analyzed more than 22,000 incidents and 12,195 confirmed breaches, establishes that the share of breaches involving a third party doubled in one year, rising from 15% to 30%. In other words, nearly one breach in three now originates, in whole or in part, outside the victim's perimeter. The threat is no longer just an attacker at the door: it is a flaw inherited from a trusted partner.
Anatomy of a cascading breach: Okta to Cloudflare
To understand the mechanism, one textbook case is enough, and it involves a company renowned for its security excellence: Cloudflare.
In October 2023, Okta, an authentication provider used by thousands of companies, disclosed that its support system had been attacked. HAR files uploaded by customers, containing session tokens and cookies, had been accessed by an attacker. Okta revoked the tokens and advised its customers to sanitize those files.
But a few weeks later, on November 14, a likely state-sponsored attacker infiltrated Cloudflare's self-hosted Atlassian server. How? By reusing an access token and three service-account credentials stolen during the Okta breach. Cloudflare had reacted to the initial alert, but some tokens had not been properly rotated. The attackers then reached the Confluence wiki, the Jira database, and part of the source code on Bitbucket, methodically searching for documentation on the architecture and security of Cloudflare's global network.
The key takeaway from this chain: Cloudflare was not breached through a Cloudflare flaw. The compromise of an identity provider, several links upstream, was enough to open the door. And the aggravating factor was not technical but organizational: a compromised secret that was forgotten when it should have been revoked. As Eric Fourrier, CEO of GitGuardian, puts it, secrets serve as pivot points in attack chains: the attacker moves from one stolen credential to the next, from the third party to the final target.
Not an isolated case: the Salesloft Drift wave
If one could believe the Cloudflare episode exceptional, 2025 proved the opposite at scale. Between August 8 and 18, 2025, an actor tracked as UNC6395 exploited OAuth tokens stolen from Salesloft Drift, a chatbot application integrated with Salesforce.
The result is staggering: more than 700 organizations were affected, including Cloudflare (again), Google, Palo Alto Networks, Proofpoint, Zscaler, and Tanium. Here too, the Salesforce platform itself was not breached. The attackers simply inherited the excessive permissions granted to a third-party application, then methodically exported data from Salesforce instances in search of secrets: AWS keys, VPN credentials, Snowflake tokens. Enough to fuel a wave of downstream attacks.
The Cloud Security Alliance's lesson is clear: the Drift integration had been granted access far broader than a chatbot required. When the tokens were stolen, the attackers inherited that excessive privilege. The weak link was not inside the fortress, but in an application to which the fortress had, one day, granted too many rights.
Why third-party risk is exploding
Three dynamics converge to make third-party security a front-line issue.
First, the attack surface has shifted toward SaaS and integrations. Every OAuth connector, every API, every third-party application plugged into a central system creates a "trust tunnel" that traditional security tools struggle to monitor. The attacker no longer needs to break through the target: it is enough to compromise a less well-defended vendor and take the tunnel.
Second, these breaches are the slowest to detect. According to the IBM Cost of a Data Breach Report 2025, supply-chain breaches take on average 267 days to identify and contain, the longest of any category. The reason is structural: malicious activity blends into legitimate partner traffic for months.
Finally, the cost is high. Also according to IBM, a breach involving a third party or the supply chain costs on average $4.91 million, the second most expensive vector in the study. Third-party risk is therefore not only frequent: it is persistent and costly.
| Indicator | Value |
|---|---|
| Share of breaches involving a third party | 30% (15% a year earlier, +100%) |
| Average time to detect and contain | 267 days |
| Average cost of a supply-chain breach | $4.91M |
What our monitoring observes
The signal shows up in our monitoring feed. Over the last 30 days, across some 17,000 consolidated cyber signals, breaches tied to a third party or the supply chain form a constant pattern: we count 307 signals explicitly mentioning a third party, a vendor, or the supply chain, 78 mentioning stolen tokens or credentials, and 55 dealing with OAuth access. The Salesforce saga (Salesloft Drift, then Gainsight) alone recurs in 30 distinct signals over the period.
Above all, the concrete examples we collect illustrate the scale of the phenomenon, beyond the big names. Over these last few weeks alone, our monitoring picked up the compromise of a vendor linked to a $5 billion US food company, the breach of a subcontractor exposing patient data at an oncology institute, a series of malicious npm and NuGet packages designed to steal cloud secrets and CI/CD credentials, and an OAuth vulnerability in a Jenkins-Bitbucket plugin opening the way to phishing. The shift described by the major reports is not an abstraction: it materializes week after week, where a single incident at a vendor cascades onto dozens of downstream customers: a single vendor compromise (August 2025) thus impacted more than 700 organizations in about ten days.
Security is no longer an option to be billed for
A practice that has become unacceptable must be named: too many vendors still treat security as a premium feature, sold separately, rather than as the foundation of their service. The most documented example is single sign-on (SSO). The site sso.tax, nicknamed the "SSO Wall of Shame," lists dozens of vendors that gate SSO behind an "Enterprise" tier, inflating the bill by 50%, 200%, sometimes more than 1,000%. The site's message is unequivocal: security should not be a luxury feature, and SSO is a fundamental security requirement for any company with more than five people. This practice punishes growing organizations and pushes them toward dangerous shortcuts, exactly the opposite of what a serious vendor should encourage.
The reasoning extends well beyond SSO. When a customer entrusts its most valuable data to a provider, certain security elements are no longer negotiable: data encryption with robust, non-obsolete algorithms, network segmentation, three-tier architecture, multi-factor authentication, awareness of the OWASP Top 10 risks, and secrets management and rotation. These are not checkboxes, they are the foundations. A vendor that bills them as extras, or worse does not offer them, transfers its risk onto its customer without saying so.
This is why customers must become markedly more demanding. A contract often provides for financial indemnification in the event of an incident, but no clause repairs the reputational damage with one's own customers, nor the loss of trust that follows. The best protection is not after-the-fact compensation, it is demanding standards upfront. That demand can rest on verifiable guarantees: ISO 27001 certifications, SOC 2 reports, attestations that demonstrate a company maintains genuine cyber hygiene and culture, in its processes, its code reviews, the awareness training of its teams. These frameworks are not an absolute guarantee, but they prove that a structured effort exists.
Because that is the heart of the matter. There will always be someone stronger than you, and no organization is invulnerable. But you cannot claim to be a victim if you did not put the necessary means in place to protect yourself. Security is no longer a luxury you afford yourself when the budget allows, it is a necessity, and the responsibility to ensure it extends across the entire chain, from the customer down to the last of its subcontractors.
What to do: regaining control over what you don't control
You cannot audit the code of all your vendors, but you can mechanically reduce the third-party risk surface.
It all begins with a prerequisite that conditions everything else: question the criticality of the data before even outsourcing it. The first question to ask is not "which vendor should we choose?" but "does this data even need to leave our walls?". Concretely, that means classifying your data by level of criticality, then weighing each contemplated outsourcing against your own impact scales: if the compromise of that data at a third party would cause an impact the organization deems unacceptable (regulatory, financial, vital, strategic), then depending on that third party is not acceptable, whatever the security level it advertises. All the risk described in this article stems from a choice that has become a reflex: entrusting your data and processing to SaaS providers and clouds you do not directly control. Yet for the most critical data, the best protection against the compromise of a third party remains not depending on that third party. Favoring a locally hosted solution, or an infrastructure you keep under direct control, eliminates an entire portion of the attack surface at a stroke: no OAuth token to be stolen, no intermediary vendor whose security escapes your governance. This does not suit every use case, and self-hosting shifts part of the security burden onto your own shoulders, as the Cloudflare incident showed with its self-hosted Atlassian server. But the question deserves to be asked head-on, and first. Sovereignty is not an ideological stance, it is a concrete reduction in the number of actors you are forced to place your trust in.
Trust does not exclude control
Third-party security forces a change of mindset. For years, security was thought of in terms of perimeter: protecting the inside against the outside. But when 30% of breaches transit through a trusted partner, the boundary is no longer the outer wall, it is in every connection granted to a third party.
The trust placed in a vendor is not a security control. As the Cloudflare incident reminds us, cybersecurity is a shared responsibility that must extend across the entire supply chain. Ignoring this reality means leaving open a door whose key has been handed to someone else.
Sources
- Verizon, 2025 Data Breach Investigations Report (third-party share rose from 15% to 30%; 22,000+ incidents, 12,195 breaches): verizon.com
- IBM, Cost of a Data Breach Report 2025 (supply-chain breach: $4.91M, 267 days to detect): ibm.com
- GitGuardian / Solutions Numériques, analysis of the Okta → Cloudflare attack (Eric Fourrier): solutions-numeriques.com
- Cloudflare, BleepingComputer, details of the Atlassian server intrusion (2024)
- Google Threat Intelligence Group (GTIG), Cloud Security Alliance, FINRA, Salesloft Drift / UNC6395 campaign (700+ organizations, August 2025)
- sso.tax, The SSO Wall of Shame (catalogue of vendors billing SSO as a premium option): sso.tax
- Primary data: LuksMentis monitoring (~17,000 cyber signals over 30 days)