SaaS Security & SSPM

The SaaS security problem

Two numbers frame the entire discipline. The first: the average enterprise runs 200+ SaaS applications - somewhere between 130 and 400 depending on the study and the company size, and the trend is monotonically up. The second: IT inventories typically capture around 40% of them. The remainder is what the industry calls shadow IT - apps bought on a corporate card, signed up for with a work email, or onboarded through a free-tier link in someone's Slack DM.

That gap is not a hygiene problem; it is the structural reality of modern work. SaaS is too easy to adopt. Any employee with a credit card and 60 seconds can stand up a workspace, invite teammates, and pipe sensitive data through it before anyone in security knows it exists. The vendor's incentive is frictionless onboarding; the customer's discovery problem is the externality.

The data inside those apps is not a side concern. The customer list lives in Salesforce; the source code lives in GitHub; the payroll and PII live in Workday; the strategy decks live in Google Drive and SharePoint; the production secrets live in 1Password or Vault; the customer support tickets live in Zendesk; the deal flow lives in HubSpot. The corporate file server moved into SaaS years ago. Most enterprises have more sensitive data in SaaS than in their cloud IaaS estate, and yet the cloud security program is often heavily IaaS-weighted because that is where the discipline grew up.

The other complication: SaaS apps each have their own admin console, their own permission model, their own audit log shape, their own concept of "external user," and their own definition of "public link." A security engineer who is fluent in S3 bucket policies is still in week-one territory when they sit down in Salesforce's sharing model or Slack's Enterprise Grid org-vs-workspace controls. SaaS security is breadth work - many systems, shallow at first, deepening on the Tier 0 ones - where IaaS security is depth work in three near-identical cloud APIs.

The SaaS security model - what shifts vs IaaS

The shared responsibility model tilts dramatically as you move from IaaS to PaaS to SaaS. In IaaS you are responsible for the operating system, the network, the runtime, the application, the identities, the data, and the configuration. In SaaS, the vendor owns the operating system, the runtime, the application, the network, and the physical infrastructure. What is left to you is narrower but no less important:

Two consequences follow. First, every column where the answer is "you" needs a process, an owner, and a control - and there is no IaaS-style API-uniformity to ride on. Second, the columns where the answer is "vendor" are not free. Your vendor's incident is now your incident. A breach at Okta, Snowflake, GitHub, Twilio, MOVEit, Cloudflare, Microsoft, or any major SaaS becomes a same-day investigation for every customer. The third-party risk management discipline that used to be a once-a-year questionnaire is now a continuous monitoring problem.

The other shift worth naming: log access is licensed. Microsoft 365 audit logs at the Purview Advanced tier vs the entry-level tier differ by months of retention and depth of fields. Salesforce Event Monitoring requires Shield. Slack Audit Logs require Enterprise Grid. The security team often finds out about these license gates during an incident, which is the worst time to discover them. Inventory the per-app log entitlements during program design, not during an investigation.

What SSPM is (and isn't)

SSPM - SaaS Security Posture Management - is the discipline of continuously assessing the security configuration of SaaS applications through their administrative APIs and emitting findings against a baseline. The model is direct lift-and-shift from CSPM: connect to the SaaS admin API, enumerate the tenant, evaluate against rules, surface drift.

What an SSPM tool reads and evaluates per connected app:

• Users & admin roles - who has access, who has elevated privileges, who has not logged in for 90 days, who has MFA enabled.
• Authentication settings - SSO enforcement, MFA policy, session timeouts, password policy where local auth exists.
• Sharing & collaboration - public links, external collaborators, default link permissions, guest access scope.
• Third-party app integrations - every OAuth app installed in the tenant, its scopes, the users who granted it, when it was last used.
• Data exposure surface - public files, anonymous-link documents, externally shared channels / boards / repos.
• Audit log configuration - whether logs are enabled at the right tier, whether they are exported to your SIEM, whether retention is sufficient.
• Tenant-specific risky defaults - anonymous SharePoint link sharing, Salesforce guest-user object permissions, Slack workspace-app install permissions, GitHub default repo visibility, etc.

What SSPM is not:

• Not a CASB. SSPM does not sit in the data path; it does not inspect uploads / downloads for DLP; it does not block a user from typing customer PII into ChatGPT.
• Not an IdP. It reads the IdP's settings and consumes its logs, but it does not authenticate users.
• Not an ITDR. SSPM is preventive - config drift, weak settings, dormant accounts. The detection layer (impossible travel, MFA fatigue, session-token theft) is ITDR's job.
• Not a DLP product. Some SSPMs surface public files; they don't classify content beyond what the SaaS already labels.
• Not a vendor risk management (VRM) tool. SSPM tells you about apps you run; VRM is about whether the vendor can be trusted.

The category overlaps with CSPM/CNAPP at the conceptual level (configuration posture, rule libraries, drift detection, framework mappings) but the underlying APIs are entirely different and the rules cannot be transferred. A CSPM that "also does SaaS" is, in practice, almost always thinner on the SaaS side than a dedicated SSPM - particularly for Salesforce permission-set rationalization, Slack workspace fragmentation, and the per-app deep checks that drive most of the value.

The four pillars of SaaS security

Every SaaS security program reduces to four interlocking pillars. They are not optional, and weakness in any one of them undermines the others.

The pillars compound. Strong identity makes posture drift less catastrophic. Strong posture reduces the blast radius of identity compromise. Strong data controls reduce the consequence of either failing. Strong detection catches everything that the first three missed. Programs that skip one pillar pay for it in the others.

The OAuth app problem

Of all the structural risks unique to SaaS, OAuth app authorization is the one most under-managed by security teams in 2026. The mechanism: a user clicks a "Sign in with Google / Microsoft" button on a third-party app, the SaaS shows a consent screen requesting scopes ("read your email", "manage your repositories", "send email as you"), the user clicks "Allow", and the third-party app gets a refresh token that - depending on the platform - may never expire and may bypass conditional-access policies on subsequent uses.

The properties of that token:

• No MFA prompt on subsequent use. The user already authenticated when they granted consent.
• Often no expiry. Refresh tokens can persist indefinitely until revoked.
• Survives password changes. Resetting a compromised user's password does not invalidate their OAuth grants.
• Often invisible to the user. Most users cannot list the apps they have authorized; many admins cannot either, without an SSPM or the native admin console.
• Tenant-spanning when the app has admin consent. Some grants apply to the entire org, not just the granting user.

The result is that OAuth consent has functionally replaced credential phishing as the higher-value attack path in many recent campaigns. The attacker does not need the user's password or MFA token - they need the user to click "Allow" on a convincing-looking consent screen. The 2022-2024 wave of OAuth-grant phishing campaigns (Storm-0558 keys, GitHub OAuth-token incidents from CircleCI and Heroku integrations, the Okta cross-tenant attacks, repeated abuse of compromised Mailchimp and HubSpot integrations) is the canonical example. Each demonstrates that a single compromised vendor with broad OAuth scopes can pivot into hundreds of customer tenants simultaneously.

The defensive posture every SaaS security program needs:

• App allowlist / admin consent. M365, Google Workspace, and most modern SaaS allow restricting user-grant of OAuth apps; net-new apps require admin approval. The default everywhere should be "no user-driven OAuth grants for non-trivial scopes."
• Continuous OAuth app inventory. SSPM tools pull the list of authorized apps, their scopes, the users who granted them, and last-used timestamps. Without this, you have no idea what is connected.
• Scope-based risk tiering. Read-email and write-email scopes are higher risk than calendar-read; tier the inventory by impact, review the high-impact apps quarterly.
• Revocation playbook. When a vendor breach is disclosed (and they will be - frequently), you need to be able to revoke tokens at scale in M365, Workspace, GitHub, Slack, and Salesforce within an hour. Practice it.
• Detection for new grants. Alert on new OAuth app grants in the IdP audit log, particularly grants with mail / drive / admin scopes.

The vendors most active in this space - Push Security, Valence Security, Reco, Obsidian, AppOmni, Adaptive Shield, Spin.AI - all centre OAuth-app inventory and risk-scoring as a primary feature, not an afterthought. If you are evaluating SSPM and OAuth is a third-class feature, evaluate something else.

Shadow IT discovery

You cannot secure what you cannot enumerate. Shadow IT discovery in 2026 is a multi-source reconciliation problem; no single signal catches everything, and the best programs fuse four:

• DNS / network egress telemetry. SSE / SASE products - Zscaler, Netskope, Cisco Umbrella, Palo Alto Prisma Access, Cloudflare One - see every SaaS domain a managed user reaches. Categorization databases tag the SaaS, and the volume of traffic gives a usage signal.
• SSO + finance reconciliation. The IdP catalog (Okta, Entra ID, Google Workspace) lists the SaaS the org has officially integrated. Finance data - corporate-card transactions, expense reports, AP records - lists the SaaS the org is paying for. The delta between those two is high-signal shadow IT, often the most operationally important kind.
• Email & calendar parsing. SaaS sign-ups generate password-reset emails, calendar invites use SaaS domains, vendor onboarding emails route to inboxes. Tooling that parses these - most modern SSPMs and some dedicated shadow-IT products like Grip Security and Wing Security do - surfaces apps that have neither network signal nor finance signal.
• Inline CASB / browser-extension telemetry. Per-session view of where users are going and what they are doing once they get there. The most invasive source but also the highest-resolution. Browser-based products like Push Security, Island, and Talon (now Palo Alto) sit at the browser layer specifically for this.

The reconciliation produces a single SaaS inventory keyed by app, with a per-app evidence trail of how the app was discovered, how many users use it, what the org spends on it, and whether it has SSO integration. The typical first-pass finding when an org runs this exercise: they have 2-3x more SaaS apps in use than the official catalogue claims, and at least a handful of Tier-0-data apps (typically a file-sync tool, a survey tool, or a marketing-automation tool) are running outside IT's awareness.

Discovery is the easy half. The hard half is what you do with the list: onboarding apps to SSO and SCIM, negotiating enterprise tenancy with vendors that started as employee sign-ups, deciding what to retire, what to consolidate, what to leave alone. That work is operational, not technical, and it is the difference between a SaaS inventory that gets used and one that sits in a dashboard.

SSPM vs CASB

The two categories are confused frequently. The simplest distinction: CASB sits in the data path; SSPM sits outside it. The longer version:

The categories overlap on API-mode posture features - most CASBs have an "API mode" that reads tenant configuration, and some SSPMs are starting to add lightweight DLP via the SaaS's native APIs. But the primary value propositions remain distinct. CASB is the inline-control layer; SSPM is the posture-management layer. Mature programs run both, and increasingly they run them from different vendors specifically because the depth of SSPM coverage in a CASB rarely matches a focused SSPM, and vice versa.

One emerging consolidation pattern: SSE platforms with bolted-on SSPM. Netskope, Zscaler, and Microsoft Defender for Cloud Apps each have SSPM-shaped features, and they are getting deeper. The trade-off is the same as any "platform with everything" play - a 70%-good integrated suite versus an 95%-good best-of-breed pair. Pick the trade-off knowingly.

SSPM platform landscape

The category has consolidated significantly in 2024-2025. The major dedicated vendors:

• Adaptive Shield - acquired by CrowdStrike in 2024 and now part of Falcon. Broad app coverage (150+), strong on Microsoft 365 and Salesforce.
• AppOmni - enterprise-focused, deepest Salesforce coverage of any SSPM (the founders came out of the Salesforce security team), strong on ServiceNow and Workday.
• Obsidian Security - heavy ITDR overlap; strong threat detection and breach reconstruction in M365 and Workspace.
• Wing Security - discovery-first model, broad app coverage, OAuth and supply-chain emphasis.
• Grip Security - email-parsing-based shadow IT discovery as a primary entry point, growing into full SSPM.
• Reco - AI-led identity-graph approach, strong on cross-app data exposure and AI app sprawl (the ChatGPT / Copilot / Claude problem inside the enterprise).
• Valence Security - workflow-automation emphasis, strong OAuth and supply-chain coverage.
• Suridata - broad coverage, strong on identity and data exposure surfaces.
• Spin.AI - heritage in SaaS backup; SSPM features added more recently, strong on data-recovery integration.
• Push Security - browser-extension-based, blurs SSPM / ITDR / shadow-IT lines; particularly strong on identity-attack detection in-session.
• Atomicwork - newer entrant, SaaS management with security overlap.

Native and platform-vendor offerings:

• Microsoft Defender for Cloud Apps - deep on M365, broad CASB capabilities, growing SSPM coverage of major non-Microsoft SaaS. For Microsoft-first shops the default choice; for diversified estates, often a complement to dedicated SSPM.
• Cisco Cloudlock - long-standing API-mode CASB / SSPM hybrid.
• Netskope SSPM, Palo Alto Prisma SaaS Security Posture, Zscaler SSPM - SSPM modules inside the SSE platforms. Useful if the SSE is already in place; rarely the deepest option on a per-app basis.

How to evaluate

• Depth on your Tier 0 apps. Every SSPM lists 100+ supported apps. The relevant question is: how many checks does it run on M365, Workspace, Salesforce, GitHub, and Slack - and how do those compare to the same vendor's coverage of a long-tail app you also need?
• OAuth-app inventory and risk-scoring. The feature most likely to deliver value in week one.
• Time-to-value. Connecting to M365 and Workspace should be 30 minutes each; if onboarding a Tier 0 app takes weeks, the vendor's integration depth is shallow.
• Workflow integration. Findings need to flow to your ticketing system (Jira / ServiceNow) and your SIEM, with the per-finding context the assignee needs.
• Framework mapping. SOC 2, ISO 27001, NIST CSF, plus per-app benchmarks (CIS Microsoft 365 Foundations, CIS Google Workspace, CIS Salesforce). See the GRC page for how to use these.

CASB platform landscape

For completeness - the CASB category is mature and largely consolidated into the SSE platforms:

• Netskope - among the strongest standalone CASB capabilities, deep DLP, inline + API modes for most major SaaS.
• Zscaler ZIA - inline-first, very strong on shadow-IT discovery at the network egress layer.
• Cisco Cloudlock - API-mode CASB; integrates with Cisco's broader SSE.
• Palo Alto Prisma SaaS - part of Prisma Access SASE.
• Microsoft Defender for Cloud Apps - particularly deep on M365 and Entra-integrated apps; included with E5.
• Skyhigh (Trellix) - heritage CASB lineage, now part of Trellix's portfolio.
• Symantec / Broadcom CloudSOC - long-running enterprise CASB.

If you are starting from zero in 2026, the practical recommendation is: pick the SSE / SASE that your network team has already chosen, take its CASB module, and add a dedicated SSPM if the diversified-SaaS depth matters. Standalone CASB without an SSE wrapper has largely stopped being a viable category.

SaaS apps to prioritize

Not every SaaS deserves the same investment. A useful tiering applied to most enterprises:

• Tier 0 - extinction-event apps. Microsoft 365 / Google Workspace (mail, files, identity, communication), the IdP (Okta, Entra ID, Ping, JumpCloud), Salesforce (customer data, deal pipeline), GitHub / GitLab (source code, deployment keys), the secrets manager (1Password, Vault, AWS Secrets Manager if SaaS-fronted).
• Tier 1 - major systems of record. Atlassian (Jira, Confluence), ServiceNow, Workday, Slack / Teams, Zoom, Box / Dropbox, Snowflake, Databricks.
• Tier 2 - operational SaaS. HubSpot, Marketo, Zendesk, Intercom, DocuSign, the BI tools, the survey tools, the marketing-stack tools.
• Tier 3 - the long tail. Everything else. Baselined to SSO + SCIM + MFA; not deeply audited.

Coverage flows top-down. A program that has not baselined Tier 0 has no business spending time on Tier 3. The Tier 0 systems also share a property: their compromise or their vendor's compromise is a same-day, all-hands event, which is why their per-app deep work - Salesforce permission sets, GitHub branch protection, M365 Conditional Access - pays off disproportionately.

Microsoft 365 security

M365 is, for most enterprises, the highest-stakes SaaS tenant in the estate. The control surface is broad; the licensing structure determines which controls you actually have access to. The work breaks down across several products:

• Microsoft Secure Score - the native posture-management dashboard. Useful as a baseline but shallow compared to a dedicated SSPM. Treat as the floor, not the ceiling.
• Conditional Access - the policy engine that decides who can authenticate from where, on what device, under what conditions. The single most important control surface in M365; the place where Zero Trust intent meets enforcement.
• Microsoft Defender for Office 365 - anti-phishing, Safe Links, Safe Attachments, attack simulation. Particularly important given the role email plays in initial-access attacks.
• Microsoft Defender for Cloud Apps - the CASB / SSPM-adjacent layer.
• Microsoft Defender for Identity - ITDR-shaped detections on Active Directory and Entra ID.
• Microsoft Purview - sensitivity labels, DLP, retention policies, e-discovery, Insider Risk Management. The data-governance layer.
• SharePoint & OneDrive sharing - anonymous link sharing is the single most common public-data exposure in any M365 tenant; the default in many tenants still allows it. Default it off, override per-site where business justification exists.
• Exchange external sender rules, mail-forwarding restrictions, OAuth app consent policies - three quick wins that close a disproportionate share of M365 attack paths.

Baseline references worth following: the CIS Microsoft 365 Foundations Benchmark and the CISA SCuBA (Secure Cloud Business Applications) baselines. SCuBA in particular ships open-source assessment scripts (ScubaGear) that produce evidence the auditors will accept.

Google Workspace security

Workspace's security model is more uniform than M365's - fewer products, more consolidated under the admin console - but the discipline is similar:

• Security Center - posture dashboard, security investigation tool, the place to triage findings.
• Alert Center - the detection feed; surfaces phishing, suspicious logins, data exfil patterns. Forward to your SIEM.
• Drive sharing audit - the equivalent of M365's anonymous link problem. Audit "anyone with the link" sharing, restrict to internal-only by default, override per-folder where required.
• Context-Aware Access - Workspace's Conditional Access equivalent. Combine with BeyondCorp Enterprise for full Zero Trust enforcement on Workspace apps.
• Third-party app whitelisting - the OAuth app problem expressed in Workspace's vocabulary. Admin console → Apps → Third-party connected apps → restrict to allowed apps; require admin approval for new requests.
• 2-Step Verification enforcement - including hardware keys (Titan / YubiKey) for admin and high-risk users.
• Data Loss Prevention - Workspace DLP scans Drive and Gmail for sensitive data patterns; pair with sensitivity labels and Vault retention.
• Vault - Workspace's e-discovery and retention. Critical for regulated industries; needs configuration before you need it.

Reference baselines: CIS Google Workspace Foundations Benchmark and the CISA SCuBA Workspace baseline, which ships ScubaGoggles for assessment.

Salesforce security

Salesforce is the SaaS whose security model rewards specialization. The sharing model - org-wide defaults, role hierarchies, sharing rules, manual shares, account teams, opportunity teams, public groups, queues - is sufficiently nuanced that a generalist SSPM check is rarely sufficient. The Tier 0 work:

• Health Check - the native posture score. Floor, not ceiling.
• Salesforce Shield - paid add-on. Event Monitoring (the high-fidelity audit log), Field Audit Trail (long-term history of field changes), Platform Encryption (BYOK / HYOK), Einstein Data Detect. For any regulated industry, Shield is functionally required.
• Permission set rationalization - most production Salesforce orgs accumulate years of permission-set sprawl. Permission Set Groups + a regular review cadence is the only known cure. Tools like AppOmni and the native Permission Set Group Analyzer help.
• Guest user (Experience Cloud / Communities) controls - historically a source of major data exposures (multiple high-profile Salesforce-Communities incidents in 2020-2023). Audit guest-user object permissions, sharing rules, and Apex class access on every Experience Cloud site.
• Connected Apps / API access - OAuth app inventory in Salesforce vocabulary. Restrict who can install Connected Apps; require admin approval; audit IP restrictions on Connected App tokens.
• External-organization sharing - partner portals, Experience Cloud sites, Salesforce-to-Salesforce - each is a way data can leave the org's primary sharing model.
• Multi-Factor Authentication - required by Salesforce since 2022; verify enforcement, particularly for API users and integration accounts.

The Salesforce-focused security community is small but vocal; Salesforce Ben, Trailhead's security trails, and the annual Salesforce TrailblazerDX security tracks are reasonable starting points for the depth this app needs.

GitHub & GitLab security

The source-code system is the SaaS whose compromise is closest to "extinction event" for engineering organizations - your code, your CI / CD secrets, your deployment keys, often a path to your production cloud accounts via OIDC. The non-negotiables:

• SAML / SSO enforcement at the organization / group level. Without enforced SSO, ex-employees may retain personal-account access to org repos. Enforce it.
• SCIM provisioning. Tie membership to your IdP so leavers are removed automatically.
• Hardware-key MFA for every member of the org, particularly for accounts with org-admin or repo-admin rights. GitHub Enterprise allows enforcement.
• Branch protection on every default branch - required reviews, status checks, no force pushes, no direct pushes to main.
• Secret scanning + push protection. GitHub Advanced Security (or open-source equivalents like Trufflehog, Gitleaks) catches credentials before they land in the repo. Push protection blocks the push instead of detecting it after.
• Dependabot / Renovate / GitLab dependency scanning. Supply-chain CVE coverage at the dependency level.
• Third-party OAuth app review. CI / CD vendors, IDE integrations, code-analysis tools all request broad GitHub scopes. Audit the org's authorized apps quarterly; revoke unused ones.
• OIDC over PATs. Personal Access Tokens are long-lived secrets and a frequent leakage source. Wherever the cloud target supports OIDC federation (GitHub Actions ↔ AWS / Azure / GCP), use that instead of PATs.
• Code-scanning (CodeQL, Semgrep, Snyk Code) in the default branch's required checks. See the CI/CD page for the supply-chain depth.
• Audit log shipping to SIEM. GitHub Enterprise's audit log is the evidence trail for every code, secret, and Actions event. Forward it.

The same principles apply to GitLab (organization-level SSO, branch protection rules, dependency scanning, secret detection, push rules, audit events) and to Bitbucket. The brand names differ; the discipline is the same.

Slack & Teams security

Chat platforms are the corpus where the most sensitive ad-hoc conversations happen - incident bridges, deal negotiations, salary discussions, customer escalations. Their security controls are often underconfigured relative to the data they hold.

• DLP & sensitive-data detection. Slack DLP, Microsoft Purview Communication Compliance, and SSPM-side DLP all surface secrets, PII, and customer data in messages. The first scan of any organization's Slack typically finds AWS keys, Stripe keys, and customer records in DMs.
• App / bot whitelisting. Slack workspace apps and Teams apps each have their own marketplace and consent model. Restrict who can install apps to admins; require approval for new requests.
• Default channel sharing & external connections. Slack Connect (cross-org channels) and Teams Shared Channels make external collaboration trivial - and easy to misuse. Default to off, allow per-channel with approval.
• Retention policies. Per-channel and per-workspace; aligned with regulatory and legal-hold requirements. The default in many tenants is "forever," which is rarely the right answer.
• E-discovery. Slack Discovery API and Teams Compliance Center; required for litigation hold and regulated industries.
• Enterprise Key Management. Slack EKM and Teams Customer Key let customers hold the keys; required for the most regulated tenants. Operationally heavy; do not adopt without a use case.
• Identity & SCIM. Treat the same as any other Tier 0 SaaS - SSO, SCIM, dormant account pruning.
• Audit logs to SIEM. Slack Audit Logs API requires Enterprise Grid; M365 Unified Audit Log covers Teams. Forward both.

ITDR - Identity Threat Detection & Response

ITDR is the detection-and-response layer over the identity provider and the SaaS audit logs - the SOC-side counterpart to SSPM's preventive posture. Where SSPM tells you the configuration is wrong, ITDR tells you an identity is being abused.

The detections that matter

• Impossible travel / geo anomalies. A login from New York at 09:00 and Singapore at 09:30; classic but still relevant when adversaries forget about residential-proxy hygiene.
• MFA fatigue / push-bombing. Repeated MFA pushes that eventually get approved by a frustrated user. The Uber 2022 pattern.
• Session-token theft. A token used from a different device fingerprint than where it was issued. The AiTM phishing pattern.
• Malicious OAuth app installation. A new OAuth grant with high-impact scopes - particularly mail.read or files.readwrite.all - appearing in the audit log. Often the first observable of a tenant-takeover campaign.
• Privilege escalation patterns. A user added to a privileged role group; an admin role granted outside the normal request workflow; a service account given new permissions outside its IaC source.
• Golden SAML / cross-tenant trust abuse. Federated trust being abused to move from one tenant to another.
• Mass-download / mass-export events. A user downloading 10,000 Salesforce records in an hour. A user exporting an entire SharePoint site. A GitHub user cloning every repo in the org.
• Anomalous service-account behaviour. A long-static service account suddenly performing new API calls.

The data sources

• IdP logs - Okta System Log, Entra ID Sign-in and Audit logs, Google Workspace Login Audit, Ping audit events.
• M365 Unified Audit Log - Exchange, SharePoint, OneDrive, Teams, Azure AD events in one stream.
• Workspace Reports API - Login, Drive, Admin, Token, SAML audits.
• Salesforce Event Monitoring - high-fidelity login, API, and data-access events (requires Shield).
• GitHub Audit Log - org, repo, and Actions events.
• Slack Audit Logs - Enterprise Grid only.

The vendor landscape

• Push Security - browser-extension-based identity attack detection at the session layer.
• Permiso - identity-graph approach across cloud and SaaS.
• Mitiga - cloud and SaaS IR + ITDR overlap.
• Beyond Identity - phishing-resistant authentication with ITDR overlap.
• Vectra Identity - AI-led detection in Entra and Active Directory.
• CrowdStrike Falcon Identity Protection, Microsoft Defender for Identity, Proofpoint ITM - major-platform identity-detection modules.
• SIEM-side - Splunk, Sentinel, Chronicle / SecOps, Panther all have identity-detection content packs; pair with a dedicated ITDR or build in-house using detection-as-code patterns.

The model that works in practice: SSPM for the preventive baseline, ITDR for the live detection, both feeding a SIEM that the Cloud SOC watches with IR playbooks per Tier 0 app.

Compliance for SaaS

SaaS-specific compliance work splits into two halves: what you owe your customers about your SaaS estate, and what you ensure your vendors deliver to you.

• Vendor SOC 2 / ISO 27001 reports. Every Tier 0 SaaS should produce a current SOC 2 Type II or equivalent. The TSC scope matters - Security plus Confidentiality is the minimum for most data-handling vendors. Review annually; track expirations.
• BAAs for HIPAA-adjacent SaaS. A Business Associate Agreement is required for any vendor that handles PHI. Verify the vendor's signed BAA and that the specific service in scope is on their BAA-eligible list - both M365 and Workspace have feature subsets that fall outside the BAA boundary.
• Data residency. Where does the SaaS store data; can you constrain that region; what happens to backups? GDPR, China PIPL, India DPDP, and several other regimes have hard residency requirements that the SaaS may not natively enforce.
• Sub-processor lists. Major SaaS publish their list of sub-processors (the cloud providers and tools they use). GDPR requires the customer be notified of changes; CCPA / state-privacy regimes have similar mechanics. Track and review.
• Data Processing Addenda (DPAs) & Standard Contractual Clauses (SCCs). The contractual layer for cross-border data flows; refreshed regularly as case law and adequacy decisions evolve.
• Right-to-audit, security questionnaires, CAIQ / SIG responses. Vendor-due-diligence artefacts. Most SaaS now self-publish via Whistic, SafeBase, OneTrust Vendorpedia, or similar trust portals.
• Breach notification SLAs. Your vendor contracts should commit them to notify you within a defined timeframe so you can meet your own regulatory clock (72 hours under GDPR).

See the GRC page for the broader framework landscape and the Compliance Frameworks page for per-framework specifics.

Building a SaaS security program

The work, sequenced:

1. Discovery. Reconcile SSO + finance + DNS / SSE + email parsing into a single SaaS inventory. Expect to find 2-3x more apps than IT believed it ran.
2. Inventory enrichment. Per app - owner, data classification, user count, SSO status, SCIM status, MFA status, last access, BAA / SOC 2 status, spend.
3. Tiering. Apply Tier 0 / 1 / 2 / 3 by data sensitivity and blast radius. Tier 0 gets per-app deep work; lower tiers get baselined.
4. Baseline. Run an SSPM (or the equivalent native tooling per Tier 0 app) against CIS / SCuBA / framework-aligned baselines. Generate a backlog of findings.
5. Remediation. Top of backlog: public-share remediation, dormant account removal, MFA enforcement, admin role rationalization, OAuth app review. Some of these are operational, not one-shot.
6. OAuth app governance. Set admin-consent policies; build the review cadence; document the revocation playbook.
7. Continuous monitoring. Wire SSPM findings to ticketing and to the security backlog. Drift becomes an alert, not a quarterly discovery.
8. ITDR detection. Forward Tier 0 audit logs to the SIEM. Build / buy detections for the IdP, M365 / Workspace, Salesforce, GitHub, Slack.
9. IR playbooks per Tier 0 app. What does "compromised M365 tenant" look like; who do you call; what evidence do you collect; how do you revoke tokens; how do you communicate. See the IR page.
10. Lifecycle. Onboarding workflow for new SaaS (SSO required, SCIM required, security review required, OAuth scopes reviewed). Offboarding workflow when an app retires (SCIM deprovisioning, tenant data export, account closure).

This is a 12-18-month program for a typical enterprise, and it does not finish - SaaS sprawl is monotonic; the work is permanent. The teams that do it well treat SaaS security like vulnerability management: a continuous program with rotating per-app deep dives, not a project with an end date.

AWS, Azure, and GCP side-by-side

SaaS is, definitionally, not the hyperscalers' core business - but each cloud has identity, CASB, and SaaS-management capabilities that intersect with the SaaS-security discipline. The native overlap:

The pattern: Microsoft is by far the deepest of the three on SaaS security as a native discipline, because M365 itself is a major SaaS estate and Defender for Cloud Apps is a real CASB / SSPM hybrid. AWS is the thinnest - there is no AWS-native CASB. GCP sits between, with Workspace controls and BeyondCorp filling much of the gap. For most enterprises, native tooling is a starting point and a dedicated SSPM + CASB combination provides the depth.

Maturity stages

A useful staging model for a SaaS security program:

Most enterprises in 2026 are Stage 1 with pockets of Stage 2. Stage 3 is the realistic target for a mature security program with a year or two of dedicated SaaS-security investment.

Common pitfalls

• Relying on SSO logs alone. SSO logs tell you about authentication; they tell you nothing about what happened inside the SaaS after authentication. You need the per-app audit logs too - M365 Unified Audit, Workspace Reports, Salesforce Event Monitoring, GitHub Audit Log, Slack Audit Logs.
• No OAuth app review. Every SaaS security incident assessment in the last three years includes a finding about an unreviewed OAuth grant. Stand up the inventory and the review cadence before anything else.
• No shadow IT discovery. An inventory built from the SSO catalog alone misses 40%+ of the SaaS in use. The inventory you act on is wrong.
• SSPM bought but not configured to alert. The platform sits in "monitor" mode; findings accumulate in a dashboard nobody opens. Findings need to flow to a ticket queue with an owner.
• No IR playbook for SaaS. "M365 admin account compromised" is the wrong moment to figure out how to revoke tokens, force password resets, audit recent OAuth grants, and pull mailbox-access evidence. Pre-write the playbook.
• Salesforce treated like just another SaaS. Its sharing model is unique; its blast radius is enormous; its native logging is paid-tier. It deserves an order of magnitude more depth than the average app in the inventory.
• SCIM not enforced. Manual deprovisioning misses apps; ex-employee access persists for months. Every Tier 0 SaaS should be SCIM-integrated.
• Underestimating the log-licensing problem. "We'll just pull the audit log" assumes the audit log is in your tenant tier. Often it isn't. Inventory log entitlements per app during program design.
• Confusing CASB with SSPM. Buying one and assuming it covers the other's job. They overlap on API mode; they do not substitute for each other.
• Treating SaaS security as a one-off project. SaaS adoption is monotonic. The program is permanent staffing, not a one-time engagement.

Further reading

Frameworks & baselines

• CISA SCuBA - Secure Cloud Business Applications
• CIS Microsoft 365 Foundations Benchmark
• CIS Google Workspace Foundations Benchmark
• CSA Cloud Controls Matrix
• CISA ScubaGear (M365 assessment)
• CISA ScubaGoggles (Workspace assessment)

Vendor documentation

• Microsoft 365 security documentation
• Google Workspace security checklist
• Salesforce security overview
• GitHub security documentation
• Slack Trust Center

Industry research

• CSA SaaS Governance research
• Gartner - SSPM definition
• Verizon DBIR - identity-driven breach trends

Related CSOH pages

• CSPM vs CNAPP - the IaaS-side companion to this page; the two together cover most of the modern *PM landscape.
• IAM & Identity - the bedrock that SaaS security depends on.
• Detection Engineering - how to build the ITDR detections referenced above.
• Cloud SOC - the operations function that consumes SaaS detections.
• Incident Response - the playbooks every Tier 0 SaaS needs.
• Zero Trust - Conditional Access and Context-Aware Access fit here.
• GRC - the framework / audit-evidence layer SaaS security feeds.
• Data Security & KMS - Customer Key / EKM / BYOK across SaaS.

FAQ

What is SSPM and how is it different from CSPM?

SSPM (SaaS Security Posture Management) is the configuration-posture management discipline applied to SaaS applications - M365, Workspace, Salesforce, Slack, GitHub, and so on - read through their admin APIs. CSPM does the same job for IaaS / PaaS - AWS, Azure, GCP. The concept is identical: connect, enumerate, evaluate, alert on drift. The APIs and the rule sets are entirely different, and a CSPM that "also does SaaS" is almost always thinner than a focused SSPM, particularly on Salesforce and the long-tail SaaS depth.

Do I need SSPM if I already have a CASB?

Most mature programs run both. CASB is inline (DLP, access control, traffic-side enforcement); SSPM is out-of-band (configuration posture, OAuth inventory, admin-role audit). They overlap at the edges - most CASBs have an API mode that does some SSPM-ish checks - but the depth on individual SaaS apps in a focused SSPM almost always exceeds the depth in a CASB's API mode. The decision tree: if you only have budget for one, pick CASB first if the dominant risk is data exfil via uploads / downloads, pick SSPM first if the dominant risk is misconfiguration and OAuth sprawl.

How urgent is the OAuth app problem really?

Very. Recent campaigns - Storm-0558, Midnight Blizzard's M365 OAuth abuse, the GitHub OAuth incidents from compromised CircleCI and Heroku integrations, the Okta cross-tenant takeovers - all centred on OAuth-grant abuse, not credential phishing. OAuth tokens bypass MFA, often do not expire, survive password resets, and are typically invisible to the user. Every SaaS security program in 2026 needs an OAuth app inventory, an admin-consent policy, a revocation playbook, and detection rules for new grants with sensitive scopes. If the program does not have these, OAuth is the most likely future incident.

Is Microsoft Defender for Cloud Apps enough on its own?

For Microsoft-first shops whose non-MS SaaS estate is limited, frequently yes. For diversified estates with Salesforce, Slack, GitHub, Workday, ServiceNow, Snowflake, and others as core systems, Defender for Cloud Apps is best paired with a dedicated SSPM that goes deeper on those apps. The depth difference shows up in Salesforce permission-set rationalization, Slack workspace fragmentation, and GitHub org configuration - all places where a focused SSPM has hundreds of checks and Defender has dozens.

How do I get started if I have nothing in place?

Start with discovery and OAuth. Run a discovery exercise that reconciles SSO + finance + DNS / SSE + email parsing into a single SaaS inventory. In parallel, pull the OAuth app list for M365 and Workspace (you can do this in the admin console without buying anything) and review the high-impact grants. Together those two exercises produce immediate findings and immediate value. From there, buy an SSPM if the budget exists; if not, start with the CISA SCuBA baselines for M365 and Workspace and the CIS Benchmarks for the rest of the Tier 0 apps.

How does this relate to the *PM family - CSPM, KSPM, DSPM?

They are all configuration-posture management disciplines applied to different surfaces. CSPM handles cloud infrastructure (AWS / Azure / GCP). KSPM handles Kubernetes. SSPM handles SaaS. DSPM (Data Security Posture Management) handles data wherever it is. The *PM acronym proliferation reflects the same insight applied to different domains: configuration drift is the dominant attack surface in modern cloud systems, and continuous-assessment-against-baseline is the dominant control. The unified tooling story (CNAPP for IaaS + workloads; emerging unified SSPM + DSPM platforms; SSE + SSPM bundles) is the industry's attempt to collapse them back together.

Where does AI-app sprawl (ChatGPT, Copilot, Claude in the enterprise) fit?

It is the newest and fastest-growing slice of the SaaS-security problem. Every enterprise is now discovering AI tools in its environment - sanctioned and unsanctioned - and each one is a SaaS with identity, data, and OAuth implications. The discovery sources are the same (SSO, finance, DNS, email). The configuration questions are slightly different (does the tool train on your data, what's the retention, what's the data-residency posture, what tenant isolation does it provide). Several SSPM vendors - Reco and Push Security in particular - have made AI-app visibility a primary feature. See also the AI/ML Security page.