SaaS Security Posture Management: Why Salesloft and Drift Changed Everything About OAuth

For about ten days in August 2025, a threat actor most people had never heard of walked into the Salesforce instances of more than 700 companies — including Cloudflare, Google, Palo Alto Networks, Proofpoint, Tanium, and Zscaler — and walked out with their support case data, their contacts, and, in hundreds of cases, the authentication secrets their customers had pasted into those cases.

The attacker did not exploit a Salesforce vulnerability. Salesforce itself was not breached. What happened, instead, is the nightmare scenario that every SaaS security vendor has been warning about for five years: an OAuth token belonging to a legitimate, popular, AI-driven sales chatbot called Drift — made by Salesloft — was stolen, and that token was used to authenticate against every Salesforce environment that customer had connected.

This is the post-mortem every SaaS security buyer should read before they sign their next contract. Because the uncomfortable truth is that the entire SSPM category was built, marketed, and sold on the premise of catching exactly this kind of attack. And in August 2025, it largely didn’t.

What actually happened between August 8 and August 20

The best reconstructions of the incident come from Google’s Threat Intelligence Group (GTIG), Mandiant’s post-incident forensics, and the remarkably transparent disclosure Cloudflare published in October 2025. Between them, the timeline is now well established.

The threat actor, tracked as UNC6395, compromised Salesloft’s GitHub repositories at some point between March and June 2025. From there, the actor pivoted into Salesloft’s AWS environment and stole OAuth tokens for Drift’s integrations — not just with Salesforce, but with the entire portfolio of SaaS applications Drift connects to.

On August 8, 2025, the actor began authenticating against customer Salesforce environments using those stolen tokens. For the next ten days, they systematically ran SOQL queries — the Salesforce query language — against Cases, Accounts, Users, and Opportunities objects. In Cloudflare’s case, they extracted the full text of customer support cases in just over three minutes using the Salesforce Bulk API, then attempted to delete the job to cover their tracks. Cloudflare reconstructed the attack from residual logs anyway.

On August 20, Salesloft and Salesforce disabled the Drift integration globally. Salesforce removed Drift from AppExchange. Notifications began going out on August 26. By early September, the scope was clear: more than 700 organisations touched, credential material harvested from support cases, and — crucially — 104 Cloudflare API tokens rotated because they had been pasted into support tickets by customers over the preceding months.

Then, in November 2025, it happened again. Different vendor — Gainsight this time — same pattern. Published Salesforce apps, compromised OAuth chain, more than 200 companies exposed. The industry barely paused.

The question nobody in the SSPM category wants to answer

If SaaS Security Posture Management platforms do what their marketing says they do, why did this happen at organisations — Cloudflare, Palo Alto, Zscaler, Proofpoint — who sell cybersecurity products and can reasonably be assumed to have bought the best SSPM tooling available?

The honest answer, which you will not read on any SSPM vendor’s homepage, is that the SSPM category was designed to catch configuration drift and permission creep inside individual SaaS tenants. It was not designed to catch a third-party integration whose OAuth tokens were stolen from the third party’s own infrastructure. The attacker in the Drift case was, from Salesforce’s perspective, a perfectly legitimate integration doing perfectly normal things — right up until it ran a Bulk API job at 11am and exfiltrated everything.

This is not a failure of any one product. It is a category-level gap. And it is why the August 2025 incidents have forced a re-evaluation of what SSPM should actually cover.

What SSPM was supposed to do — and what it actually does

Before the Drift incident, the standard SSPM pitch covered five things: discover what SaaS apps your employees are using (including shadow IT), find misconfigurations inside those apps, flag excessive permissions and dormant accounts, audit which third-party applications are connected to your core SaaS tenants, and monitor for anomalous user behaviour that might indicate account compromise.

Every platform in the category — AppOmni, Adaptive Shield (now part of CrowdStrike), Obsidian, Valence, Netskope SSPM, Wing, Reco, Grip, and a dozen others — does some version of all five. Where they differ is in which pillar they lead with.

Two things are worth noting about this table. First: Adaptive Shield was acquired by CrowdStrike in late 2024, which means the vendor landscape is already consolidating toward endpoint-plus-SaaS platforms. Second: of the nine or ten platforms that reasonably claim leadership in this space, only Valence was specifically architected around the third-party integration risk that the Drift attack exploited. That is not a coincidence — it is an indicator of where the category as a whole had under-invested before August 2025.

The OAuth problem most SSPM tools understate

OAuth is a ten-year-old authorisation standard that was designed for a simpler world — one where you wanted to let a calendar app read your email without handing over your password. What it has become is the connective tissue of the modern enterprise: every SaaS-to-SaaS integration, every AI assistant that reads your documents, every marketing automation tool that touches your CRM, every revenue intelligence platform that mines your Slack — they all run on OAuth tokens.

The controls an OAuth token offers — scopes (what the token can access), expiry (when it becomes invalid), refresh tokens (how it renews itself), and revocation (how you turn it off) — are adequate in theory. In practice, most enterprise OAuth integrations violate every defensive principle at once.

Integration tokens are typically issued with the widest possible scopes because narrowing them breaks functionality and nobody has time to debug it. Refresh tokens are issued with long or no expiry because rotating them would break the integration. Revocation requires someone to know the token exists, know where it is used, and have the authority to pull it — which in a mid-size company often involves three different teams and two vendors. And the audit trail of what an OAuth token actually did inside a SaaS tenant is, for most apps, a forensic exercise rather than a live monitoring feed.

The Drift attack exploited every one of these gaps. The stolen tokens had broad Salesforce scopes. They had not been rotated. Nobody outside Salesloft knew they had been stolen until ten days of exfiltration had already happened. And the attacker’s queries looked indistinguishable from legitimate Drift behaviour until the Bulk API job fired.

There is a structural issue here that the SSPM category has been slow to name out loud. The OAuth model implicitly trusts the integration provider’s ability to protect their own token store. When you grant Drift access to your Salesforce tenant, you are not just trusting Drift’s software — you are trusting Salesloft’s AWS hygiene, their GitHub practices, their employee access controls, their secrets management, and every layer of their engineering pipeline. An SSPM platform inspecting your Salesforce tenant cannot see any of that. It can see the token exists, it can see what the token did, but it cannot see whether the token still resides only where it should.

This is the core asymmetry the Drift incident exposed. SaaS security is being marketed as a tenant-level problem — configure your tenant correctly, monitor it for drift, alert on anomalies. But the attack surface is not tenant-level. It is the union of every tenant you run, every integration those tenants trust, and every piece of third-party infrastructure those integrations run on. Most organisations have an inventory for the first. Some have an inventory for the second. Almost none have visibility into the third.

Four control gaps that SSPM platforms are now rushing to close

In the six months since the Drift disclosure, every serious SSPM vendor has updated their roadmap to address at least some of these gaps. The ones that matter most are:

Continuous OAuth token inventory, including tokens held externally. Most SSPM tools can tell you which third-party apps are connected to your Salesforce or M365 tenant. Very few can tell you which third-party apps hold tokens to your tenant on infrastructure they operate. That distinction is what the Drift attack turned into a supply chain. Post-incident, buyers should ask: can your SSPM tell me which integrations issued their tokens from infrastructure that is not mine, and flag anomalous use of those tokens from that external infrastructure?

Scope minimisation and enforcement. Simply flagging that a token has broad scopes is inadequate — every SSPM tool already does that. What the incident showed is that the flag is often ignored because nobody will take the operational hit of narrowing the scope. Newer approaches involve automatically downscoping tokens based on observed usage patterns, or proxying OAuth sessions so that scopes are enforced centrally rather than at issuance.

Behavioural baselining for integrations, not just users. Most SSPM platforms built sophisticated anomaly detection for human users — login patterns, geographic movement, privileged action sequences. Very few did the same for integrations. Drift’s normal behaviour was periodic queries on Contacts and Accounts. The attacker’s behaviour was a bulk export of Cases. The gap between those two is detectable, but only if you have behavioural baselines for integrations specifically. Obsidian and Valence are furthest along here; AppOmni is catching up; most of the rest are still retrofitting.

SOAR integration for token revocation. When the Drift breach was disclosed, victim organisations found that revoking the Drift OAuth token required a series of manual steps: identify the token in the Salesforce connected apps list, revoke it, rotate any credentials that had been shared through Drift, audit which other Salesloft integrations were affected. Cloudflare’s incident report describes this as a company-wide security response. The post-Drift expectation is that SSPM platforms will integrate with SOAR tools so that a single “revoke and rotate” action can cascade across every affected integration and every downstream credential within minutes.

The uncomfortable truth about what SSPM can and cannot protect

Here is the position most SSPM vendors are reluctant to take in writing: if your third-party SaaS vendor’s own infrastructure is breached, your SSPM platform will not save you. What it can do is reduce the blast radius, shorten the time to detection, and ensure that the credentials that were stolen are limited in scope and quickly revocable.

That is a meaningful defence. It is not the defence that was sold.

The practical implication for buyers is that SSPM has to be part of a layered strategy, not a turnkey solution. Cloudflare’s post-incident analysis makes this explicit: the reason they detected the attack at all was because they had logging in place that survived the attacker’s delete-the-job cleanup, and because their IR team reconstructed the activity from Salesforce audit logs rather than relying on their SSPM’s alerts. Their SSPM helped them understand the scope. It did not help them detect the breach in real time.

Organisations serious about SaaS security after Drift and Gainsight should be doing at least the following:

• Maintaining a complete inventory of OAuth integrations, including narrow-scope ones that seemed too trivial to track.
• Implementing mandatory scope reviews for any integration with read or write access to sensitive objects (Cases, Contacts, Accounts, anything containing credentials or PII).
• Prohibiting — as policy, not aspiration — the pasting of secrets, tokens, or credentials into SaaS tickets. Cloudflare rotated 104 API tokens because customers had pasted them into support cases over the course of months.
• Treating integration tokens as privileged credentials for the purposes of audit, rotation, and access review — which few organisations currently do.
• Subscribing to vendor threat intelligence feeds that include compromised third-party OAuth advisories. The Drift and Gainsight disclosures were public within days; the organisations that moved fastest were the ones who had processes to consume that intelligence.

How the SSPM market is likely to evolve by the end of 2026

Three trajectories are visible now that were not visible in early 2025.

First, consolidation. CrowdStrike’s acquisition of Adaptive Shield signalled that endpoint vendors will absorb SSPM capability rather than buyers running SSPM as an independent category. Expect similar moves from Palo Alto, Microsoft, and possibly one of the CNAPP-first vendors covered in our comparison of the CNAPP platforms. Within 18 months, standalone SSPM will mostly be a mid-market category, with enterprise SSPM delivered as a module inside a broader platform.

Second, identity convergence. The distinction between SSPM and identity security is collapsing. Tokens, machine identities, AI agent credentials, service accounts, and OAuth scopes are all manifestations of the same underlying problem: who and what can do what inside your SaaS estate. Expect the IAM platforms covered in our Zero Trust IAM comparison to grow into this space at least as aggressively as the SSPM vendors grow into identity.

Third, and most importantly for buyers: the category is being forced — by customer incidents, by boards, and increasingly by cyber insurers — to move from posture management to active enforcement. Telling a security team they have a problem is no longer sufficient. Preventing the problem, or containing it within minutes when it manifests, is the new bar. The vendors that get there first will define the next three years of this market.

The cyber insurance angle in particular is worth watching. Carriers including Coalition, At-Bay, and Cowbell have begun asking specific questions about third-party SaaS integration inventory and revocation capability in their 2026 applications. This is the pattern that forced MFA into near-universal adoption between 2021 and 2023: when premiums depend on a control being in place and demonstrable, the control gets implemented. Expect the same trajectory for SaaS integration hygiene by 2027.

A fourth evolution worth flagging is how AI agents will complicate this picture. Every autonomous AI agent deployed inside an enterprise will need OAuth tokens or equivalent credentials to access SaaS systems. The governance problems that made the Drift attack possible — over-scoped tokens, unrotated credentials, weak behavioural baselines — are about to exist at a scale that dwarfs human-initiated integrations. SSPM platforms that treat AI agent identity as a first-class concern rather than an afterthought will age better than the ones that bolt it on later.

What buyers should do differently now

If you are currently evaluating SSPM, the post-Drift questions to ask every vendor include:

1. When Salesloft/Drift was disclosed, how did your existing customers detect the activity? Did they detect it through your platform, through Salesforce logs, or through GTIG’s notification? Be suspicious of answers that are not specific.
2. What is your approach to integrations whose OAuth tokens are issued from infrastructure outside your customer’s control? What behavioural baselines do you maintain for those integrations?
3. What is your time-to-revoke for a compromised third-party integration, end-to-end, including downstream credential rotation? Ask for a demo.
4. What threat intelligence do you consume specifically for third-party SaaS integrations, and how is it operationalised inside your platform?
5. How do you think about the third-party risk management workflow, and how does your SSPM integrate with TPRM tooling?

The answers will vary more than most buyers expect. AppOmni will generally have the strongest Salesforce-specific story. Obsidian will have the strongest behavioural detection story. Valence will have the strongest integration-specific story. Adaptive Shield, inside CrowdStrike, will increasingly have the strongest platform-consolidation story. None of them, at the time of writing, has the complete answer. Buyers should plan accordingly.

Frequently Asked Questions

Was Salesforce itself breached in the Drift incident?

No. The attack exploited OAuth tokens issued to the Salesloft Drift integration, which the attacker had stolen from Salesloft’s own AWS environment after compromising Salesloft’s GitHub repositories earlier in 2025. From Salesforce’s perspective, the attacker authenticated as a legitimate integration and ran normal-looking queries. The Salesforce platform and its security controls were not the weak link.

Is SSPM dead after the Drift incident?

No — but the category’s boundaries are changing. SSPM remains the right tool for finding misconfigurations and excessive permissions inside SaaS tenants. It was never, in most implementations, the right tool for detecting a compromise of a third party’s infrastructure. Post-Drift, expect SSPM to either absorb third-party integration security or to be absorbed by a broader platform that does.

What is the difference between SSPM and CASB?

CASB (Cloud Access Security Broker) is primarily a network-layer control that inspects traffic between users and SaaS applications, typically for DLP and threat protection. SSPM is primarily an API-based control that inspects the configuration and permission state inside SaaS tenants. They answer different questions and are usually deployed together. Netskope, Zscaler, and Microsoft have converged both into single platforms; standalone SSPM vendors typically integrate with one or more CASB providers rather than replacing them.

How quickly can SSPM detect a compromised OAuth integration?

It depends on whether the compromise manifests as behaviour that the SSPM has a baseline for. Attacks that look like normal integration activity — which the Drift attack largely did, until the Bulk API job fired — may not be detected by posture-focused tools at all. Attacks that involve scope escalation, new destinations, or unusual query patterns are more detectable. The honest range for a well-configured SSPM is “minutes to never,” depending on the attack shape.

What should an enterprise do in the first 24 hours after a third-party SaaS breach disclosure?

First, identify every tenant in your estate where the compromised integration is installed and pull its OAuth tokens. Second, query your SaaS audit logs for any unusual activity from that integration over the disclosure window — do not rely on your SSPM alone. Third, assume any credentials, secrets, or sensitive data that were accessible through the integration are compromised, and begin rotation. Fourth, check whether customers or employees have pasted sensitive material into tickets or objects the attacker could have read — Cloudflare’s 104 rotated API tokens were all exposed through support case text. Fifth, re-evaluate which of your remaining integrations hold comparable scope and consider pre-emptive rotation.

Is OAuth fundamentally insecure, or is the problem how organisations use it?

OAuth is a sound authorisation protocol. The problem is operational: organisations issue tokens with broader scopes than they need, rarely rotate them, and have limited visibility into how they are used. A well-implemented OAuth deployment with narrow scopes, short expiry, behavioural monitoring, and rapid revocation is meaningfully secure. Almost no enterprise runs OAuth that way in practice. That gap between the protocol’s capabilities and its deployment is where attacks like Drift live.