How to Build a SaaS Security Program: Discovery, Risk, and SSPM
- Aman Bansal
- Jul 9
- 5 min read
SaaS has become the default way to deliver software due to its ease of use, leaving organizations with little choice but to rely on a small set of leading software providers, embedding risks into global critical infrastructure.
In today's enterprise architectural ecosystem, every system, service, or application is connected either directly or indirectly. Many of you have read JPMorgan Chase CISO, Patrick Opet's, open letter on the rising SaaS Security risks. Opet noted:
"The modern ‘software as a service’ (SaaS) delivery model is quietly enabling cyber attackers. As its adoption grows, it is creating a substantial vulnerability that is weakening the global economic system."
In my recent CISOs gathering in NYC, it was surprising how little the Security Leadership was aware of the SaaS Security risks, and were not prioritizing SaaS Security programs within their organizations. In 2024 itself, there is a 75% increase in SaaS breaches from last year. There is a list of 2025's All-Star SaaS Threat Actors to Watch, which highlights how threat actors are seeking to exploit SaaS risks. Microsoft Threat Intelligence also recently authored a blog post that Chinese state actors were shifting tactics to target SaaS applications to gain initial access” to their downstream customers.
So even though SaaS brings great risks but you can't deny that the SaaS delivery model has served its purpose and has made life easier for technology teams. Since we can't stop using SaaS, we must use it in the most secure way to minimize the risks.
A smarter way to handle SaaS Security Risks is to build a SaaS Security Posture Management (SSPM) program to establish continuous monitoring of your SaaS applications. SaaS Security is still relatively new compared to other security programs that have been running for decades, which is why building SSPM is something that needs to start from scratch, needs to be discussed within security leadership to allot time and resources.
How to minimize SaaS risks?
SaaS Discovery:
The first step to secure anything is to know what you have, which leads to the initial step, SaaS Discovery. It is best practice to discover all SaaS applications and create an inventory of them within your organization. You can be smart here to inventorize SaaS apps by monitoring existing tools like your IdPs (ex: Okta, Entra ID) and Cloud Access Security Broker(CASB) to constantly monitor what applications are being used/accessed in your internal environment. Otherwise, if you have resources and enough security budget, getting a SaaS Security tool is also a great option to have. SaaS Discovery is still doable using existing tools, but having continuous monitoring around your SaaS apps is hard without getting an SSPM tool in place.
Once you’ve identified your SaaS apps, tag and categorize them. For example, apps like M365, Salesforce, and Snowflake hold sensitive data and should be labeled based on sensitivity. This helps you prioritize which apps need the strongest protections.
Misconfigurations:
SaaS applications are delivered to the customers with some default configurations/settings, and application admins have very little idea if the delivered application configurations are secure enough to protect the data.
The recent snowflake breach of various of their customers is due to the lack of enforced MFA. It's a perfect example where customers have to set secure configurations on their own once the SaaS is delivered to them.
In the shared responsibility model for SaaS, the underlying physical, application, and network security is the SaaS provider's responsibility, but the configurations, access controls, and data security underlie with the customers. Ensuring your SaaS application configurations to the most secure manner minimizes risks hugely. But anyone who has administered the M365 suite knows how complex this can be; settings are scattered across multiple admin centers, making misconfigurations common.
Identities:
The absence of strong authentication with MFA in place or SSO to access different applications in your environment leaves the attack surface for the adversaries. It is important to ensure your application is configured with SSO, and it's best if the application supports SCIM so that no manual steps are needed in provisioning the user account. Even after that, the risk of having local accounts, service accounts, and other locally defined entities within the SaaS application itself has caused many breaches in the past. In any organization, there are probably 1-2 application owners, but there are multiple administrators for different use cases.
Who is making sure the user account that has admin access needs admin access?
Is the application owner performing admin access review continuously or periodically?
Are we monitoring our service accounts' usage?
Inactive Admin Accounts, Over-provisioned accounts?
Are you de-provisioning user accounts when users are offboarded?
Who is responsible for monitoring all these use cases?
These are some of the questions that should be answered by tightly controlling SaaS Identities as part of your SSPM program. More than that, educate your application admins to have a security mindset so that they don't just have to rely on security teams but can configure their applications securely on their own.
Third-party Integrations:
Third-party integrations represent one of the largest and fastest-growing attack surfaces. Whether it’s Salesforce add-ons or M365 plug-ins, these apps often come with over-permissioned access. Worse, many of them are installed without security team involvement, creating a shadow SaaS ecosystem that’s difficult to monitor or control. A compromised third-party app can lead to data exposure, lateral movement, or supply chain compromise. Unreviewed access tokens and APIs issued to third-party apps are especially high risk.
Platform admins should review their third-party connected apps periodically as part of their SSPM program.
Create a list of sanctioned third-party applications.
Regularly review tokens for scope, usage, and necessity.
Include automations to send alerts to admins in case of unused integrations or unused API tokens, so that platform admins can take necessary actions.
Just three to four years ago, very few vendors offered SSPM solutions. But recent breaches and growing SaaS adoption have shifted the landscape.
Now, even major players like CrowdStrike (via its acquisition of Adaptive Shield), Palo Alto Networks, Cloudflare, and Zscaler offer SSPM tools. This highlights the growing importance of SaaS visibility and control.
However, bringing in an SSPM tool is just the beginning. Operationalizing it is another challenge entirely. You’ll need to:
Coordinate with dozens of app owners
Push for prioritization
Often acts more like a project manager than a security engineer
That’s why building an SSPM operating model is key. Define ownership, workflows, and review cadences.
How to operationalize SSPM?
Hope this helps anyone building their SSPM program to gain perspective:
Understand the risks
Plan for the complexity
Prioritize the right integrations and apps
Empower your teams with the right mindset and tools
The SaaS application map is only growing, and securing it demands deliberate action. Start now, before the complexity overwhelms your ability to manage it.
References:
Comments