SaaS security vendors: who they are and how CISOs compare them

On CISO Tribune's record as of 31 October 2026, 11 vendors file under SaaS security posture, the taxonomy category for tools that monitor configuration, integrations, users and data exposure inside third-party SaaS applications. Between them, their products connect to a company's software-as-a-service applications over the vendor's own API, read configuration and permission settings, map which third-party apps and non-human identities have access, and flag drift from a secure baseline. Chief information security officers (CISOs) compare them on which applications they actually connect to, how they handle third-party OAuth integrations, and how findings route into a ticketing system.

Key facts

• Our record files 11 vendors under SaaS security posture: 5 as their primary category (AppOmni, Grip Security, Obsidian Security, Spin.AI, Valence), 6 as a secondary one (category record).
• The Cloud Security Alliance published the SaaS Security Capability Framework (SSCF) on 24 September 2025, the first industry-wide baseline for the controls a SaaS vendor itself should expose to its customers.
• CISA's own Secure Cloud Business Applications (SCuBA) project, established in 2022, gives every organization, not just federal agencies, free tools that check Microsoft 365 and Google Workspace tenants against a secure configuration baseline.
• The August 2025 Salesloft Drift OAuth token breach showed the category's reason for existing: the attacker never touched Salesforce's own platform, only a third-party integration's stolen tokens.

What SaaS security posture management actually does

A SaaS security posture management (SSPM) tool connects to a company's software-as-a-service applications, such as Salesforce, Microsoft 365, Google Workspace, Slack or ServiceNow, over each vendor's own application programming interface. It reads configuration settings, user and group permissions, and the list of third-party applications and integrations a user has connected, then compares that state against a secure baseline. When a setting drifts, such as a new integration gaining broad data access or multi-factor authentication being disabled for a group, the tool raises it as a finding.

That is a different blind spot than the one most security tools cover. A cloud-native application protection platform watches infrastructure a company builds and runs; a SaaS security tool watches software a vendor runs for the company, where the customer's only lever is configuration and the identities it grants access to.

The framework CISOs now have to compare vendors against

Before September 2025, there was no common language for what a SaaS vendor's own security controls should look like, so CISOs comparing products were really comparing each vendor's own description of what it does. The Cloud Security Alliance closed part of that gap with the SaaS Security Capability Framework (SSCF), developed with CSA's SaaS Working Group and released 24 September 2025.

The SSCF sets six control domains: change control and configuration management, data security and privacy lifecycle management, identity and access management, interoperability and portability, logging and monitoring, and security incident management, e-discovery and cloud forensics. Some controls in those domains are not optional. The framework treats enforcing multi-factor authentication, disabling anonymous access, and delivering logs within 24 hours as hard requirements, not best-practice suggestions.

This changes a buyer conversation that used to run one way. Instead of asking a SaaS security vendor what it checks for, a CISO can now ask which SSCF domains a monitored application actually meets, and push the application vendor itself, not just the monitoring tool, to answer against a published standard.

The federal government runs a parallel, narrower baseline. CISA established the SCuBA project in 2022 to address cybersecurity and visibility gaps exposed by SaaS intrusions, and it publishes secure configuration baselines for Microsoft 365 and Google Workspace along with two free tools, ScubaGear and ScubaGoggles, that check a tenant's actual settings against those baselines. CISA has made the tools and baselines available to all agencies and private sector organizations, so a company evaluating a commercial SaaS security vendor has a free government reference to check its findings against for those two applications.

The breach that made the category's case

For years, the pitch for SaaS security tools rested on a hypothetical: a stolen token or a misconfigured integration could expose a company's SaaS data without anyone breaching the SaaS vendor itself. In August 2025, that stopped being hypothetical.

Google's Threat Intelligence Group reported that, beginning as early as August 8, 2025 through at least August 18, 2025, a threat actor it tracks as UNC6395 targeted Salesforce customer instances through compromised OAuth tokens associated with the Salesloft Drift third-party application. The attacker ran structured queries against Salesforce objects such as Account, Case and User, and exported data at scale, then searched what it took for credentials such as Amazon Web Services access keys and Snowflake tokens.

Google was explicit about where the fault line sat: the issue did not stem from a vulnerability in the core Salesforce platform. Salesforce itself was never compromised. A connected third-party application held tokens with broad data access, and once those tokens were stolen, the attacker could query Salesforce as if it were the legitimate integration. Salesloft and Salesforce revoked every active Drift token on August 20, 2025, and Salesforce pulled the Drift app from its marketplace while the investigation continued.

Our read: this is exactly the exposure path SaaS security and non-human-identity tools are built to see before an attacker finds it, which third-party application holds which OAuth scope against which SaaS platform, and whether that scope is wider than the integration actually needs. A posture tool that inventories every connected application and its granted permissions would have flagged the Drift integration's Salesforce access as a standing risk long before any token was stolen.

How CISOs compare the vendors

Start with application coverage measured against your own SaaS footprint, not a vendor's marketing list, since broad coverage of Salesforce or Microsoft 365 says nothing about a smaller but still sensitive application your company actually runs. Then check how a tool handles third-party OAuth connections and non-human identities such as service accounts, API keys and integration tokens, since that is precisely the category of risk the Salesloft Drift breach turned from theory into incident. Ask how a vendor maps its checks to the SSCF's six domains or to CISA's SCuBA baselines where those apply, follow a sample finding into your ticketing system to see whether it reaches the team that can actually fix it, and confirm the tool can export evidence a board or auditor can read without translation.

We think the practical first question for any shortlist is narrower than "which tool has the most integrations": ask each vendor to show, specifically, what it would have surfaced about a third-party chat or marketing integration's OAuth scope before a breach, not after one.

Vendors on CISO Tribune's record

The vendors below are pulled live from our record, alphabetical and unranked. Each files under SaaS security posture as either its primary or a secondary category.

Two of the five vendors that file it as their primary category show the range inside it. AppOmni monitors configuration settings, user permissions and AI agent activity across SaaS applications such as Salesforce, Microsoft 365 and ServiceNow, and detects threats, data exposures and compliance gaps. Grip Security takes a discovery-first approach, finding every AI tool and SaaS application in use across an organization, including ones nobody told the security team about, then managing the identity risk those applications create. Both approaches answer a version of the same question the Drift breach raised: what is connected to our SaaS applications, under what identity, with what scope, and did anyone approve it, before an attacker asks it for you.