SaaS Security Posture Management (SSPM): Closing the Configuration Gap in Your SaaS Stack

These three categories are frequently confused. The boundaries matter for program design:

CASB (Cloud Access Security Broker): Monitors data flows to/from cloud services. Enforces DLP policies on uploads and downloads. Identifies unsanctioned SaaS usage (shadow IT). Applies access control policies based on device posture, user identity, and location. Does not inspect SaaS application configuration settings — only traffic.

CSPM (Cloud Security Posture Management): Assesses IaaS and PaaS configuration (AWS, Azure, GCP). Detects open S3 buckets, overly permissive IAM roles, unencrypted databases, missing security group controls. Focused on infrastructure layer — does not cover SaaS application configuration.

SSPM (SaaS Security Posture Management): Connects directly to SaaS applications via API and reads configuration state. Assesses settings against benchmarks (CIS, vendor hardening guides, compliance framework mappings). Tracks configuration drift over time. Inventories OAuth-connected third-party apps. Provides per-user license and permission review. Covers the layer neither CASB nor CSPM can reach.

Coverage summary:

A mature cloud security program needs all three. Most organizations have CASB and some CSPM, with SSPM as the gap.

SaaS misconfigurations follow predictable patterns. Understanding them helps prioritize what to assess first.

Default settings that prioritize convenience over security: Most SaaS applications ship with permissive defaults designed to reduce friction at initial adoption. External sharing is often enabled by default. MFA is often optional by default. API access may be unrestricted by default. Unless a security team reviews settings at deployment, these defaults persist.

Configuration drift over product updates: SaaS vendors update their products continuously. New features introduce new security settings. Admins who configured a platform 18 months ago have not reviewed the 12 new security controls added since then. SSPM tracks drift continuously rather than relying on point-in-time reviews.

Common high-risk misconfigurations by platform:

Microsoft 365:

• Legacy authentication protocols enabled (Basic Auth, POP3, IMAP) — bypass MFA and enable password spray attacks
• External email forwarding allowed without restriction — enables data exfiltration by insiders or compromised accounts
• SharePoint external sharing set to 'Anyone with the link' — exposes documents to anyone with the URL
• Admin consent grants allowing third-party apps to access O365 data without per-user approval
• Audit log retention below 90 days — limits forensic capability

Salesforce:

• Object-level sharing rules set to 'Public Read/Write' — exposes CRM data organization-wide
• Guest user access enabled on Experience Cloud — allows unauthenticated access to specific data sets
• API access not restricted to specific IP ranges — allows API queries from any IP with valid credentials
• Inactive user accounts not deprovisioned — former employees or contractors retain access

GitHub Enterprise:

• Public repositories containing code that should be internal
• Branch protection disabled on main branches — allows direct pushes without review
• Actions allowed from all sources — enables supply chain injection via malicious GitHub Actions
• Personal access tokens with no expiry — persistent credential exposure

Slack:

• Guest users in channels containing sensitive information
• App directory open — employees can install any Slack app without admin approval
• Message retention set to 'Forever' in regulated industry — creates compliance liability
• No DLP configured on file sharing

OAuth-connected third-party apps represent one of the largest unmanaged risks in most SaaS environments. When a user authorizes a third-party app to connect to their O365, Google Workspace, or Salesforce account, that app receives OAuth tokens — persistent credentials that can access corporate data without going through your identity provider's login flow.

The scope of the problem:

• The average enterprise has 200-1,500 OAuth-connected third-party apps across its SaaS stack
• Many were authorized by individual employees without IT or security review
• OAuth tokens often have broad scopes ('Read all mail,' 'Read and write all files') granted because the user clicked through the permission dialog
• Tokens do not expire unless explicitly revoked — a token granted three years ago by a departed employee may still be active
• Apps are often abandoned: the vendor is no longer in business, the app was acquired, or the user stopped using it — but the token remains active

OAuth attack vectors:

• Illicit consent grant (OAuth phishing): Attacker creates a malicious app that requests OAuth access to O365 or Google Workspace. Phishing email directs user to authorize the app. Once authorized, the attacker has persistent token access to email and files — bypassing MFA because no password is used.
• Compromised OAuth app: A legitimate app used by your organization is compromised at the vendor. The attacker uses the vendor's OAuth integration to access your environment.
• Excessive scope: An app granted 'mail.readwrite' when it only needed 'mail.read' has a larger blast radius if the app or its vendor is compromised.

SSPM OAuth controls:

• Full inventory of all OAuth-connected apps across all SaaS platforms
• Risk scoring by scope granted (read vs. write, files vs. mail vs. admin)
• Identification of apps connected by departed employees (tokens that should have been revoked at offboarding)
• Publisher verification status (unverified publisher = higher risk)
• Usage analytics — apps with no activity in 90 days are revocation candidates
• Policy enforcement: require admin approval for apps requesting specific high-risk scopes

The SSPM market has matured significantly with several credible platforms. Evaluation criteria differ by organization size and SaaS stack composition.

Adaptive Shield: Broad SaaS coverage (150+ integrations), strong compliance framework mapping (SOC 2, ISO 27001, NIST, PCI DSS, HIPAA). Detailed remediation guidance per finding. Good for organizations with compliance-driven programs that need framework mapping out of the box. Owned by CrowdStrike (Falcon platform integration).

Obsidian Security: Strong focus on identity threat detection within SaaS — goes beyond posture management into behavioral detection (unusual admin activity, suspicious login patterns, privilege escalation within SaaS apps). Better for organizations that want SaaS threat detection in addition to misconfiguration assessment.

AppOmni: Deep integration with Salesforce — considered the most thorough Salesforce security assessment available. Also covers ServiceNow, O365, Workday, GitHub. Strong choice for organizations heavily dependent on Salesforce or ServiceNow.

Wing Security: Focus on SaaS-to-SaaS supply chain risk and OAuth app governance. Strong shadow IT discovery via OAuth inventory. Well-suited for organizations whose primary concern is third-party app risk rather than first-party misconfiguration.

DoControl: Data access governance within SaaS — focuses on who has access to what data (files, records, channels) rather than configuration settings. Strongest for data-centric use cases: identifying externally shared files, over-permissioned users, sensitive data in collaboration tools.

Microsoft Defender for Cloud Apps (MDCA): If your organization is Microsoft-centric, MDCA (formerly MCAS) provides CASB + some SSPM functionality for the O365 ecosystem. Less comprehensive than dedicated SSPM platforms for non-Microsoft SaaS, but zero additional licensing cost if you have E5 licensing.

Evaluation criteria:

• Coverage of your specific SaaS applications (check the integration list against your app inventory)
• Compliance framework mapping quality
• OAuth app risk scoring methodology
• Remediation guidance depth (does it tell you what to click, or just what is wrong?)
• SIEM and ticketing integration (findings should flow to your existing workflow, not sit in a separate console)
• API-only integration (SSPM should not require credentials stored in the platform — use OAuth with least-privilege API scopes)

An SSPM platform will generate hundreds or thousands of findings on first scan. Without a remediation strategy, the platform becomes shelfware.

Initial deployment — what to prioritize first:

1. Critical misconfigurations by usage: Focus on the SaaS applications that hold the most sensitive data or have the broadest user base. O365, Salesforce, GitHub, and your HR system are typically the highest priority.

2. Authentication controls across all platforms: MFA enforcement, legacy auth protocol status, SSO coverage, session timeout policies. Authentication misconfigs have the highest exploitation probability.

3. OAuth app revocation pass: Export the OAuth app inventory on day one. Revoke all apps with no activity in 90+ days, all apps authorized by departed employees, and all unverified publisher apps with broad scopes. This single action often eliminates 20-40% of the OAuth risk immediately.

4. External sharing audit: Identify publicly shared files, documents, or records across Google Drive, SharePoint, Salesforce, and Confluence. Determine what is intentionally public vs. accidentally public.

Ongoing governance:

• Weekly review of new high-severity findings
• Monthly OAuth app inventory review
• Quarterly SaaS application access recertification (who needs continued access?)
• Integrate SSPM findings into your ticketing system — findings assigned to application owners with SLA-based remediation targets
• Track remediation rate by application owner as a metric reported to application leadership

SSPM is most effective as part of an integrated security architecture rather than a standalone tool.

SSPM + Identity Governance (IGA): SSPM surfaces which users have which permissions within each SaaS application. IGA platforms (SailPoint, Saviynt) manage identity lifecycle. Integrating the two ensures that SSPM-identified over-privileged users are automatically included in access certification campaigns and that offboarded users trigger immediate SaaS access revocation.

SSPM + CASB: CASB enforces policy on SaaS traffic in real time. SSPM ensures the underlying SaaS configuration matches security intent. Together: CASB blocks a suspicious download in real time; SSPM ensures that the external sharing settings that would have allowed the data to be shared externally are not misconfigured in the first place.

SSPM + SIEM: SSPM findings should flow to your SIEM as structured events. Configuration changes in high-risk SaaS settings should generate SIEM alerts — a Salesforce sharing rule change from 'Private' to 'Public' warrants investigation, particularly if made outside change control hours or by an account that does not typically make administrative changes.

SaaS application access in identity providers: If your IdP (Okta, Entra ID, Ping) manages SSO for all SaaS applications, use SSPM findings to enforce stricter Conditional Access policies for high-risk applications. A Salesforce deployment with multiple open misconfigurations might warrant step-up MFA for admin access while remediation is in progress.