Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
Hope everyone had a good RSA week and is mostly recovered! I went into RSA with little to no expectations, but I actually had some great conversations with friends. It felt a bit like old RSA, and it was refreshing. Anyway, out of these conversations, I have a new set of ideas for my newsletters, which is always a plus! Talking about SSPM is one of them.

This newsletter continues a long series of my thoughts on various security companies and categories where I talk about their potential failure modes. Here are just some examples:
This newsletter is inspired by a conversation with Abhishek Agrawal, CEO and founder of Material Security. We were talking about changes that allowed for a new wave of email security vendors. A key part of it was the movement of email away from self-hosting and to the cloud. This was true not just of email but also of many traditional applications, such as payroll, CRM, etc. Moving from on-prem applications to SaaS applications was an important part of the “cloud movement.” This changed the way companies managed software, and naturally, this led to a new security category, SSPM. However, with all new security categories, the question is if it’s actually a category that should exist.
It’s a topic that I haven’t thought much about, but as more data flows into SaaS applications, it’s worth understanding what does SaaS security even mean.
What is SaaS security posture management (SSPM)?
It’s what it sounds like. SSPM tools are automated tools used to monitor security risks, such as misconfiguration, compliance risks, etc., in SaaS applications. It is the SaaS equivalent of cloud security posture management (CSPM), which focuses just on cloud infrastructure.
Most of the companies in this area are relatively new. Some examples are AppOmni, DoControl, and Adaptive Shield.
How did this start?
Many companies move to the cloud with SaaS applications before moving toward cloud infrastructure. This was an easy way to reduce operational costs because IT teams no longer needed to maintain this software. This shift has fundamentally changed the way we develop and operate software. Customers no longer have to store data and configurations on their own servers. (This has also changed the way development and software deployment work as it is easier and faster to deploy software changes. That’s a focus of my newsletter in general, but not a focus of this particular one.)
Keep reading with a 7-day free trial
Subscribe to Frankly Speaking to keep reading this post and get 7 days of free access to the full post archives.