SaaS Security and SSPM: Looking After SaaS Apps

SaaS security means protecting the apps you rent over the internet, such as corporate email, document tools or a CRM (customer relationship management system). The provider runs the servers and the software, but your organization still owns the main risks, starting with who can sign in, how each app is configured, and who the data is shared with. SSPM (SaaS Security Posture Management) is a tool category that re-checks SaaS settings on a schedule and reports any setting that drifts from the standard you chose. This article covers the main risks, how to use vendor-neutral baselines, and a step-by-step routine for looking after SaaS apps.

Who looks after what in SaaS

The SaaS provider runs everything behind the app, so you do not install or patch servers. But the provider rarely configures the app to fit your organization. What stays with you is the user accounts, permissions, sharing settings, connections to other apps, and log collection. CSA (the Cloud Security Alliance, a non-profit that publishes cloud security guidance) has a SaaS governance paper that covers customer-side risks and mitigations across the whole lifecycle, from evaluating a provider to ending the service.

The main risks in SaaS apps

Most SaaS risk does not come from bugs in the software. It comes from settings and usage that your organization controls. This grouping is our own, not taken from a single standard.

• Insecure or drifting settings: for example, file sharing open to outsiders or MFA (multi-factor authentication) not enforced. A good setting can be changed later without anyone noticing, which is called configuration drift
• Excess accounts and permissions: too many administrators, accounts of people who left still active, and guest accounts nobody owns
• Apps connected through OAuth: OAuth is the mechanism that lets one app reach data in another app on a user's behalf without sharing the password. A user clicks allow once, and that app can keep reading mail or files until someone revokes it. MITRE ATT&CK (a knowledge base of attacker techniques) has a technique, Steal Application Access Token, that relates to this
• Unapproved apps (shadow SaaS): staff sign up on their own without IT knowing, so company data ends up where nobody is watching it. See Shadow AI: Risks and How to Respond
• Unmanaged machine accounts and API keys: automations connected to SaaS use tokens (codes an app uses instead of a password) that often never expire and have no owner. See Service Accounts and Non-human Identity: The Overlooked Risk

What SSPM is and what it can do

SSPM is a category of tool, not a standard. The idea is to connect to a SaaS app with read access to its settings, compare them with the baseline you chose, and report what does not match. Real capabilities differ by product and by which apps are supported, so test with the apps your organization actually uses before deciding. The work this kind of tool generally does is listed below.

• Check settings against a baseline: a baseline is the minimum standard setting, such as enforcing MFA or limiting external sharing
• Detect changes: raise an alert when someone changes a setting that was correct
• Review permissions and accounts: point out admin accounts, guest accounts and inactive accounts
• Review connected apps: the list of apps granted access to data, which some vendors cover in more depth than others

SSPM does not replace other controls. It tells you which setting is wrong, but it does not watch everything users do inside the app, and it does not fix identity problems by itself. You still need MFA, log monitoring and an owner for each app. For SaaS logs, see Cloud Logging and Detection: What to Log.

Choose a baseline from a neutral source

You do not have to invent every setting yourself. CISA (the US cybersecurity agency) runs the SCuBA (Secure Cloud Business Applications) project, started in 2022. It publishes secure configuration baselines, which are documents listing the settings to apply, for Microsoft 365 and Google Workspace. It also provides two free tools, ScubaGear for Microsoft 365 and ScubaGoggles for Google Workspace, that read your settings and compare them with the baselines. Results come out as HTML and JSON reports.

SCuBA is written mainly for US federal agencies. In December 2024 CISA issued directive BOD 25-01 requiring those agencies to apply it. Other organizations can use it as a reference but are not bound by it, and it covers only the two products above. For other apps you need the provider's own baseline, or the CSA framework called the SaaS Security Capability Framework (SSCF), whose version 1.0 came out in 2025. SSCF is not a list of settings for one particular app. It lists the controls a SaaS provider should offer customers to configure, so you can use it to assess a provider before buying and to compare against what the provider answers.

A routine for looking after SaaS apps

This routine is our own arrangement of practice drawn from the sources above. Repeat it in cycles rather than doing it once.

• List the apps: collect every SaaS app in use, including those staff signed up for, using invoices, the central sign-in system and the list of OAuth grants
• Assign owners and rank them: each app has a named owner, then rank apps by the data they hold, starting with those holding critical data or broad admin rights
• Configure to a baseline: apply the chosen baseline and record accepted exceptions with a reason
• Centralize identity: have apps sign in through a central system (SSO, single sign-on, means one login for many apps) and enforce MFA, so that when staff leave one account is closed in one place
• Monitor and re-check: send app logs to your monitoring system, re-check settings on a schedule by hand or with an SSPM, and review connected apps every cycle

Common mistakes

• Assuming the provider secures everything: the provider runs the back end, but settings, permissions and data sharing remain your job
• Configuring once and never checking again: settings can change at any time, through admins or through provider updates
• No owner for an app: when a problem appears nobody knows who to ask or who must fix it
• Letting users approve outside apps freely: users can grant apps access to mail or files without any review
• Buying an SSPM before listing the apps: the tool only sees apps you connect, so you must first know which apps exist

Start today

• Pick the first 5 apps: choose by the data they hold, such as email, HR files and finance systems
• If you use Microsoft 365 or Google Workspace: read the SCuBA baselines and try ScubaGear or ScubaGoggles on a test tenant first
• Review the OAuth grants: remove apps nobody recognizes or uses any more
• Review admins and guest accounts: cut admins to what is needed and close accounts without an owner

To see where your SaaS controls stand today, try the self-assessment.

References and further reading

• CISA: SCuBA Project: overview of the baselines and tools
• ScubaGear: tool that checks Microsoft 365 against the baselines
• ScubaGoggles: tool that checks Google Workspace against the baselines
• CISA BOD 25-01: Implementing Secure Practices for Cloud Services: the directive for US federal agencies
• CSA: SaaS Security Capability Framework (SSCF): the controls a SaaS provider should offer customers
• CSA: SaaS Governance Best Practices for Cloud Customers: customer-side risks and mitigations across the SaaS lifecycle
• MITRE ATT&CK: Cloud Matrix: attacker techniques covering SaaS, IaaS and identity providers
• MITRE ATT&CK T1528: Steal Application Access Token: the technique tied to tokens of connected apps