The Difference Between CSPM and SSPM

Years ago, a marvelous cartoon in The New Yorker featured one bearded college professor yelling at another, “Wait, all this time, I was talking macro and you were talking micro?” This is how conversations unfold when people talk about cloud security posture management (CSPM) versus software-as-a-service (SaaS) security posture management (SSPM). The two are similar and overlap to a certain extent. Yet, SSPM is quite different from CSPM. This article will explore those differences.

First, Some Definitions

Security posture, in general, is about how well an organization is prepared to defend itself against cyber threats. Typically, posture amounts to being able to detect threats and respond to them effectively—and quickly. In specific terms, security posture deals with guarding networks and protecting an organization against malware, ransomware, denial of service (DoS) attacks, data breaches and other serious threats.

CSPM applies the principles of security posture to instances of cloud computing. It involves automating the detection and remediation of risks across infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS).

SSPM realizes security posture goals with software-as-a-service (SaaS) applications. It combines tools, people, processes, and policies with the goal of reducing cyber risk exposure for SaaS apps. For example, an SSPM solution might monitor and remediate insecure SaaS configurations or third-party integration plugins.

Why Cspm and Sspm Are Important

CSPM is essential because traditional security processes and countermeasures don’t work very well in the cloud. The cloud is exposed to risks that do not affect on-premises infrastructure. For one thing, there’s no perimeter. The very flexibility and ease of access that makes the cloud so useful, in business terms, makes it vulnerable to threats that you don’t run into in traditional IT environments. Nor is there the kind of centralized management that’s common with on-premises infrastructure. Manual processes don’t scale well in the heterogeneous landscape of the cloud, either. After all, in addition to encompassing IaaS, SaaS, PaaS, and other “as-a-service” technologies, a cloud environment can also be public, private, or hybrid.

Like CSPM, SSPM is an important element of an overall security program because it addresses SaaS apps’ unique risks. A SaaS app can be accessed, in theory, by anyone, from anywhere, on multiple device types. This is great for operational agility but terrible for security. Countermeasures, such as multi-factor authentication (MFA) are critical for protecting SaaS apps and the sensitive data they contain, if they are turned on, which they often aren’t. The problem is partly one of scale. The average organization uses over a hundred SaaS apps, each of which has its own unique custom security settings that can be modified by individual users. The security team cannot keep up without SSPM tooling. 

How CSPM and SSPM Differ

CSPM and SSPM both address themselves to the parts of the IT estate that live in the cloud, which are outside the standard zone of security policies and operations. They overlap, to some extent, with CSPM potentially monitoring access to SaaS apps, for example.

Similarities and overlap aside, CSPM and SSPM are different, but also complementary. CSPM is concerned with cloud infrastructure, while SSPM deals with applications.  It’s the micro to CSPM’s macro, if we go with the cartoon’s theme. CSPM is broader in scope than SSPM. For instance, CSPM might include the integration between software development and cloud operations, while SSPM does not.

SSPM, conversely, deals with a level of detail in SaaS security that CSPM does not touch. An SSPM solution, such as Suridata’s SSPM platform, monitors the configurations of all SaaS apps. It flags, and can automatically remediate, insecure configurations. SSPM inventories third-party plugins and alerts security managers to integrations that may expose the organization to risk.

An SSPM solution identifies all of the places in the SaaS ecosystem where corporate data is stored, and identifies any security risks that arise from such data storage. An SSPM platform monitors SaaS user sessions and flags suspicious activity, such as excessive file downloading, which can signal a ransomware attack in progress. An SSPM platform prioritizes SaaS security alerts and recommends remediation of the most urgent issues first.

Conclusion: You Probably Need Both CSPM and SSPM

If you have cloud assets and SaaS, which would make you like most organizations, you probably need both CSPM and SSPM. On their own, they each provide part—but not all—of the cloud security you need. CSPM protects your cloud infrastructure, with possibly some defense of SaaS. To get thorough SaaS security, however, you need SSPM in addition to CSPM. You have to talk micro as well as macro.

Lee Kappon

Co-Founder & CEO

Back to list

SaaS Ransomware: Getting Ready for a New Generation of Threats 

Last month, a new SaaS ransomware had been seen “in the wild” for the first time. The attack, which affected Microsoft SharePoint software, did not come from a compromised endpoint. This fact has alarmed SaaS security experts. Nor is it good news for security managers. However, there are ways to defend against such threats.  

The Attack  

Until now, ransomware attacks on SaaS applications have followed a pattern wherein the attacker first compromises an endpoint such as a laptop or server. After encrypting the data on the endpoint, the encrypted data synchronizes across all the storage/backup services, rendering it unusable, and the attacker demands a ransom for it to be decrypted. However, that is not what happened in this case. 

In this attack, a hacker compromised a Microsoft global admin service account’s credentials. The attacker was able to compromise the credentials because the service account did not have MFA/2FA enabled. Therefore, the account could be accessed over the public internet simply with a password. Specifically, the attacker accessed the service account from a virtual private server (VPS) host. Even though the VPS had an anomalous IP-geolocation, vis a vis “normal” access patterns, the attacker was still able to access the account. 

From there, the attacker set up a new Active Directory (AD) user called “Omega” using the compromised service account. The attacker then used the compromised service account to grant, and then elevate, the Omega account’s permissions—to roles that included Global Administrator, SharePoint Administrator, Exchange Administrator, and Teams Administrator. (Wow!) The compromised service account also granted Omega site collection administrator capabilities for multiple SharePoint sites and collections.  

The attacker proceeded to remove the other 200 admins from the system within two hours. The stage was set for a massive data breach, and at that point, the attacker was able to exfiltrate files. 

Implications for SaaS security 

The SharePoint ransomware attack “in the wild” presents a new twist on an old(ish) attack. What stands out is the fact that the attack did not involve compromising an endpoint like a server. With hackers no longer needing to gain access to an endpoint, they can focus instead on SaaS services. In this case, they used an admin account to lock out other users and breach the target’s data. They could have also encrypted the data and demanded a ransom to decrypt it. While most SaaS vendors are able to help victims restore their access and possibly recover lost data, the process tends to take a long time to complete, and it will not necessarily be able to restore all the affected data. 

The attack makes it clear that SaaS applications are now targets for ransomware attacks. It also shows the importance of defining and enforcing clear and effective policies regarding administrative accounts. The SharePoint attack would not have worked if MFA/2FA, along with better geo anomaly detection and response, had been operational. 

Mitigating This New Type of SaaS Risk 

This attack is a sign of what the future holds. It may have been the first known SaaS ransomware “in the wild,” but it will not be the last. The method of the attack underscores the importance of setting up, maintaining, and monitoring SaaS security controls. Though this idea is simple enough, its execution can be quite challenging. 

For most organizations, which on average employ more than 100 SaaS apps, each with their own unique configurations and settings, the task of defending against ransomware in the wild is going to be a daunting prospect. There are simply too many opportunities for security measures to fall apart. Individual users may be able to change their security settings without anyone knowing. Admin accounts may not be configured securely, e.g., without MFA/2FA. Third-party plugins might grant access to unauthorized users, and so forth. 

A SaaS security posture management (SSPM) platform, such as Suridata, offers a way to mitigate these new risks. Suridata comprises a single, unified solution for SSPM. With this SSPM platform, it becomes possible to achieve secure configurations of all SaaS apps in an organization—and then monitor those configurations for changes that reflect a change in security posture. The SSPM platform can also tightly control access by users and plugins, while monitoring for abnormal behavior. As it works, it is able to prioritize the security problems it detects, and in some cases, automatically remediate them. 


A new era is dawning in SaaS security. Ransomware attacks are lurking in the wild. It’s time to be prepared to defend against them. An SSPM platform is arguably the best technology available to mitigate threats that exploit weaknesses in access control, configuration, and anomaly detection.  

To learn about the Suridata SSPM platform, contact us now. 

Lee Kappon

Co-Founder & CEO

Back to list

SSPM vs. idP

Security managers typically conduct regular reviews of their solutions and assess whether they need to maintain, enhance, or replace what they currently use. As Software-as-a-Service (SaaS) applications become more prevalent and critical, concerns about SaaS security have grown increasingly urgent. In response, enterprises are considering the adoption of SaaS Security Posture Management (SSPM) tools to mitigate SaaS risk.
In some cases, however, the security team will reject the idea of SSPM because they are already using an identity provider, or idP. Their perspective seems to be, “We don’t need SSPM. We’re good. We have idP.” While understandable, this view is not correct. SSPM and idP are not the same. And, idP alone cannot provide the depth of SaaS security that today’s enterprises need.

A brief overview of SaaS security

SaaS applications have a distinctive risk profile. They’re comparable to but different from other kinds of digital assets. A SaaS app typically contains sensitive or valuable corporate data, but it can be accessed from virtually anywhere on any kind of device. Controls over user access are therefore critical to maintain strong security. Third-party plugins represent a potential threat vector, as well. In addition, each SaaS app—and the average company now uses dozens if not hundreds of them—has its own security settings and unique configuration. The volume and variety of SaaS apps, and their respective configurations create a broad attack surface.

What is an idP?

An idP stores users’ digital identities and enables their management. Sometimes implemented as a commercial solution, sometimes built using open-source components, an idP typically checks user identities using a combination of username/password pairs and other factors, such as a PIN code or device characteristic. An idP may be part of a single sign-on (SSO) solution. It may also be a component of a broader identity and access management (IAM) solution. idPs often work together with multi-factor authentication (MFA) solutions, as well.

idPs verify user identities, a foundational cybersecurity control. Knowing who is who, and confidently authenticating their identities, are essential steps to the effective realization of many other controls. For example, it is impossible to enforce access privileges without being certain of a user’s actual identity. idPs perform this task.

For an idP, a “user” does not necessarily have to be a human being. It could be a device or another software application. The OAuth token, for example, a common ingredient in idPs, authenticates machine users in app-to-app interactions. This capability is relevant to SaaS security because a SaaS app may treat a third-party plugin running in another app as a user.

What is SSPM?

Posture, the “P” in SSPM, refers to the quality of an organization’s preparation to defend its digital assets from cyber threats. This usually means being able to detect threats and respond to them thoroughly and efficiently. Going further, security posture relates to how well an organization is guarding its networks and protecting itself against malware, ransomware, denial of service (DoS) attacks, data breaches and so on.

SSPM brings security posture principles to SaaS. SSPM combines tools, people, processes, and policies to reduce SaaS apps’ inherent cyber risks. For instance, SSPM is aimed at preventing a breach of data stored inside a SaaS app. To accomplish this goal, SSPM tools monitor and remediate insecure SaaS configurations. They detect threats to SaaS apps, while also monitoring third-party integrations and bolstering regulatory compliance, where relevant.

Tracking security issues related to SaaS app users is part of SSPM. For this reason, SSPM solutions generally integrate with IAM solutions. They can monitor user access attempts and behavior to detect activity that might indicate the presence of a threat.

Do you need both an idP and an SSPM solution?

To some extent, the identity functionality of an SSPM solution overlaps with that of an idP. However, the SSPM solution does not have the depth of identity management and security features present in the idP. For example, an SSPM tool cannot enable SSO.

Does this mean you need both an idP and an SSPM solution? You probably do, especially if you want to enforce strict identity authentication policies as part of your SaaS security. An idP on its own does offer some powerful identity management and security capabilities, assuming it’s correctly implemented and managed. However, the idea that “you’re good” for SaaS security if you have an idP, but not an SSPM, is worth rethinking.

An idP cannot analyze SaaS configurations and security settings. It cannot examine third-party plugins, except perhaps to the extent that the plugin is treated as a user. It cannot remediate vulnerabilities. These are what an SSPM solution does. For optimal SaaS security posture, you probably need both.


Keeping control over user identities is essential for SaaS security. That said, an idP is not enough to deliver robust SaaS security posture on its own. An SSPM solution complements the idP, adding automated monitoring, analysis, and remediation of security weaknesses in SaaS configurations, settings, and third-party integrations. Together, idP and SSPM can provide the high level of SaaS security posture that most organizations need to stay secure in today’s threatening cyber environment.

Haviv Ohayon

Co-Founder & COO

Back to list


SaaS security posture management (SSPM) and the secure access service edge (SASE) don’t have a lot in common, but they do overlap. Hype about SASE has led to many organizations “doing SASE,” which can mean a lot of different things. There can be confusion about why an organization might need SSPM if it’s implementing SASE. As a result, it’s worth taking a moment to understand what each technology is about, how they are similar, and where they differ.

What is SASE?

The “E” in SASE is the key to understanding what it’s all about. E is for edge. SASE enables endpoints, such as mobile devices or Internet of Things (IoT) sensors to connect securely to applications and data at the edge. The user does not have to connect through a data center, which adds latency and creates network congestion.

SASE is not a product, at least not at this point. As defined by the Gartner analyst firm, SASE is an architecture that combines a software-defined wide area network (SD-WAN), zero trust network architecture (ZTNA), secure web gateway (SWG), cloud access security broker (CASB), firewall as a service (FWaaS) and centralized management. That’s a lot of technology to implement, integrate, and manage. Even if the components are all from the same vendor, it’s still a big job.

SASE, or something just like it, has become a necessity, however. Enterprises need it to support modern work scenarios—where users are accessing cloud and on-premises assets from pretty much anywhere. Allowing users to connect at the edge, via a cloud-based service, is an effective solution.

What is SSPM?

SSPM concerns itself with the collective security posture of an organization’s software-as-a-service (SaaS) ecosystem. This can be a sprawling, complicated environment, with the average organization using 130 SaaS apps as of 2022, up from 110 in 2021. To protect those SaaS apps, and the data they contain, SSPM combines tools, people, processes, and policies to reduce SaaS apps’ inherent cyber risks.

For example, SSPM might monitor SaaS apps for insecure configurations—and remediate configuration problems when they are discovered. Other SSPM tasks include monitoring user sessions for anomalies, examining data access rules to prevent data breaches, tracking third party integrations between SaaS apps, and so forth.

SSPM is a unique, coherent solution, in contrast to SASE, which is basically an architectural pattern. It is comparatively easy to implement. (Realistically, at this point, almost anything is easier to implement than SASE, which requires installing six different products and making them work together…)

Where SSPM and SASE overlap?

SSPM and SASE overlap with a common goal of protecting SaaS apps from malicious users. SASE does provide a number of defenses for SaaS. With SASE, for example, the CASB serves as a policy enforcement point that sits between users and cloud service providers, including SaaS apps. It can handle tasks like authentication, encryption, and threat detection. ZTNA helps ensure that only authorized, verified users, can access SaaS apps. The SWG component of SASE also offers some protections for SaaS apps. For example, an SWG can execute data loss prevention (DLP), by detecting and blocking unusual data transfers out of SaaS apps.

Do you need SSPM if you’re implementing SASE?

On the surface, it seems like SASE mitigates SaaS risk for the enterprise. Going a little deeper, however, a number of significant gaps emerge. Unlike SSPM, SASE does not inspect SaaS configurations, for instance. Its components do not monitor SaaS security settings and flag insecure situations. SASE does not track the use of third-party plugins that integrate one SaaS app with another. Nor does SASE monitor SaaS user sessions with the goal of detecting anomalous behavior.

Without SSPM, SASE leaves SaaS apps exposed to risks related to configuration and third-party integration, among others. And, SSPM solutions, such as Suridata, offer risk prioritization and automated remediation. SASE is a connection paradigm. It’s not a cybersecurity toolset. It does not have built-in SaaS risk remediation capabilities.   

Now, it may not be entirely fair to say that SASE can’t perform these tasks. Some SASE components are highly customizable and come with advanced developer kits. It’s probably possible to program a SASE solution to perform most SSPM processes. That would be a huge, unnecessary investment of time, however.

Making SSPM part of SASE

There is a way to resolve SASE’s gaps in SaaS security: make SSPM part of a SASE architecture. SASE already involves acquiring and integrating six or more technologies. Adding SSPM to the mix is not a huge extra step. One reason is that SSPM could operate independently from SASE, though an SSPM platform could feed data into a centralized SASE management tool, as well as related security operations (SecOps) solutions.


SASE and SSPM cover different aspects of SaaS security. SASE protects SaaS apps from unauthorized access and enforces security policies related to data loss, and so forth. Any organization that has people and IoT devices operating remotely is going to need some sort of SASE solution. SASE does not provide complete SaaS security, however. It doesn’t track SaaS configurations and third-party integrations. Nor does it manage SaaS risk remediations. For optimal SaaS defense, the two technologies should ideally be deployed together.

Haviv Ohayon

Co-Founder & COO

Back to list

SaaS and the Shared Security Model

Who is responsible for securing digital assets in the public cloud, the customer, or the cloud service provider (CSP)? Most of the time, it’s both. CSPs require their customers to agree to what’s known as a Shared Security Model, sometimes called the Shared Responsibility Model. In this approach to cloud cybersecurity, the CSP is responsible for securing their own infrastructure, but the customer is on the hook for almost everything under its control, such as application security and identity management. The Shared Security Model makes a great deal of sense, especially when the division of control is clear, such as in the case of Infrastructure-as-a-Service (IaaS). With Software-as-a-Service (SaaS), things get a little more complicated. This article looks at how SaaS security works under the Shared Security Model.

What is the Shared Security Model?

The Shared Security Model is embedded in the “fine print” of the contract the customer signs with a CSP. In fact, the word “model” is not quite right. It should really be called the shared security responsibility agreement. When you sign up with a CSP, you’re assigning yourself several critical security duties, with disputes potentially ending up in court. So, pay close attention here…

Briefly, the Shared Security Model holds that the CSP is obligated to protect its data centers, internal networks, and the hardware that supports its cloud platform. This means securing internal software development workflows and complying with security standards. It also involves monitoring infrastructure for threats, mitigating those threats, and responding to security incidents.
The SaaS provider is responsible for protecting its way of using of the applications and data it hosts on the CSP’s infrastructure.

It’s a good practice to develop a sophisticated, detailed understanding of just what is, and isn’t covered by the CSP’s side of the model. Think of the cloud platform stack. With IaaS, the CSP secures all infrastructure components on its side, including servers, network switches, and so forth. The customer may be on the hook for the operating system (OS), database server, application software and identity and access management (IAM). With Platform-as-a-Service (PaaS), the CSP usually secures the platform software, such as Linux, because that’s part of the service they’re providing. Always check, however. It is not wise to make assumptions about the CSP’s specific areas of responsibility.

The Shared Security Model comprises a logical set of rules sense for both the CSP and the customer. The CSP has little to no control over the way its customers deploy and configure their systems. Nor can the CSP control the customer’s endpoints. If the customer does not regularly patch its OS, for example, that is a deficiency the customer has to address.

SaaS and the Shared Security Model

The Shared Security Model for SaaS is different from those utilized for IaaS and PaaS, for several reasons. With SaaS, the vendor is the application provider and the cloud provider. In some cases, the SaaS vendor runs the SaaS application on a CSP like Microsoft Azure. In that scenario, the CSP is obligated to the SaaS vendor under the Shared Security Model, but the SaaS customer still has its share of security responsibilities.

The SaaS vendor is responsible for application security. This includes protecting the data stored by the SaaS app. However, the customer is responsible for data security, as well. This may sound confusing but remember that a threat to SaaS data can come from an attack on the cloud infrastructure or through the SaaS interface or application programming interface (API). In the latter attack surface, the customer is responsible.

With SaaS, the customer is also responsible for its endpoint security and user security. It is up to the customer to protect itself by preventing unauthorized access to the SaaS application. In practice, this means the customer takes care of IAM, user security and credentials, configuration, APIs and middleware.

How to Manage SaaS Security in the Context of the Shared Security Model

Managing SaaS security under the Shared Security Model requires attention to detail. It’s essential to do a careful review of the terms of the agreement and any Service Level Agreements (SLAs) it contains. The customer is protected by the legal agreement, but it’s wise to keep in mind a basic fact of life in IT: If you end up in a lawsuit, even a lawsuit you win, you are not succeeding. The best approach is to understand your responsibilities and translate the most urgent of them into clear assignments for all relevant teams and stakeholders.

Data security should be a priority, for instance. Know what data you have in your SaaS application, how it’s protected, and who has access to it. This means implementing IAM that defines and enforces cloud access policies. Privileged Access Management (PAM) needs to be part of this thought process, too.

It’s also smart to know where your SaaS application is integrating with other SaaS applications, as well as with other parts of your IT estate. The SaaS attack surface can be quite a lot larger than you realize, once you start factoring in all the ways a malicious actor can access a SaaS application beyond its front-end user interface.

A security partner can help, too, as can solutions for SaaS security posture management. Keeping track of number of SaaS configurations can be overwhelming, especially with the added burden of figuring out what is your responsibility and what is covered by the SaaS vendor. Technologies that automate SaaS security posture management can be quite helpful in minimizing risk to SaaS applications.


Haviv Ohayon

Co-Founder & COO

Back to list

SSPM vs. CASB: What Do You Need for SaaS Security?

If you have a Cloud Access Security Broker (CASB), do you also need a solution for SaaS Security Posture Management (SSPM)? Yes, you do, and this blog will explain why. CASBs have an important role to play in protecting Software-as-a-Service (SaaS) applications and their data. However, the CASB is only one element of strong SaaS security posture. A variety of other risks remain present, even with CASB’s protections. They include configuration errors, malicious code, deficiently secured third-party integrations, and more. An SSPM solution, which can integrate with a CASB, offers more complete SaaS security.

How CASBs work and why enterprises use them

The CASB has been around for a decade. It came into existence to help security managers deal with risk exposure from SaaS that did not exist when apps and data were only on-premises. Traditional firewalls can do little to protect SaaS apps and data. Indeed, with SaaS and Bring Your Own Device (BYOD) policies, users could be almost anywhere on the public Internet, on any device. This environment increased the likelihood of unauthorized access and data breaches.

CASB mitigates these risks by functioning as a point of visibility and control. As its name suggests, it brokers SaaS access requests and resulting user sessions—enforcing security policies in the process. A CASB typically works through a cloud proxy architecture. It intercepts requests for SaaS access, regardless of where they originate, blocking the ones that don’t match the rules and routing the rest to the right place. In the meantime, the CASB monitors traffic and access requests, checking for malware and suspicious behavior, among other factors. It sends alerts to system admins if it detects threats or policy violations.

The limits of CASBs in the bigger picture of SaaS security posture

CASBs contribute significant risk mitigation to SaaS security. However, they cannot help in every area of risk. When a CASB is part of a Secure Access Service Edge (SASE)architecture, it combines with Zero Trust Network Access (ZTNA),Firewall-as-a-Service (FWaaS), Security Web Gateway (SWG) and aSoftware-Defined Wide Area Network (SD-WAN) to enable even better cloud security. Yet, even with SASE, certain aspects of SaaS security posture remain neglected. 

Weaknesses in SaaS security posture that continue, despite CASB or SASE, include SaaS configuration problems, deficient access management controls, and third-party risks. Configuration errors, for example, are internal in nature. A CASB cannot help when SaaS file shares are open to public access by default, to name one common configuration scenario. Regarding access management controls, CASB will do its job even if a SaaS customer allows overly simple passwords or password sharing.Third-party risks, such as those created when one SaaS app can access another, bypass CASB’s policy enforcement point. 

Compliance is another area of SaaS security posture that is not addressed by CASB. A SaaS customer might have to abide by regulations covering data sovereignty or consumer privacy. CASB does not have an impact on such compliance requirements.

Poor accountmanagement is also a problem that cannot be alleviated by CASB. If a SaaScustomer does not stay on top of user accounts, closing them when an employeeleaves the company, for instance, CASB will still let them through.

How SSPM solutions complement CASBs for SaaS security

An SSPM solution addresses the gaps in SaaS security posture left by a CASB operating on its own, or as part of a SASE architecture. These solutions work in various different ways, but in general, they thoroughly and regularly scan SaaS instances with the goal of identifying and prioritizing SaaS security problems. Using automated processes, augmented by Artificial Intelligence (AI), they can spot misconfigurations, questionable third-party integrations, and external sharing that may violate security policies. 

Some SSPM solutions, such as Suridata, enable system owners to monitor SaaS security posture across multiple SaaS applications. This is an increasingly important need, given that the average mid-sized enterprise runs more than 185 SaaS apps. Keeping track of configurations and third-party integrations in such a broad, complex environment is nearly impossible using manual processes. The solution may also provide unified management and monitoring capabilities, which simplifies SaaS security operations. 

An SSPM solution can also monitor SaaS user behavior to detect suspicious events that might reveal a cyber-attack in progress or the presence of a malicious user. Here, the SSPM solution starts to overlap with the CASB. As the solution detects problems, it may be able to orchestrate their remediation. This process could be automated and continuous enabling the ongoing strengthening of SaaS security posture. 

As products evolve, some CASBs are starting to offer functionality that incorporates that of SSPM solutions. Alternatively, the two solutions can be integrated. Connecting a CASB with an SSPM solution helps the CASB do its job better. The SSPM solution can ingest data and alerts from the CASB into its SaaS security monitoring, and respond accordingly, for example.


CASBs do a lot for SaaS security, but they cannot address all the elements of SaaS security posture on their own. Certain areas of risk, such as SaaS configuration, remain open. An SSPM solution can fill in the missing pieces, monitoring configurations, third-party integrations and more. Together, a CASB and an SSPM can deliver a fuller, more robust SaaS security posture.

Lee Kappon

Co-Founder & CEO

Back to list

GitHub’s New Security Feature Made Available to Everyone

GitHub, the popular Internet hosting service for software development and version control, recently announced the availability of a new service that scans for secrets in developers’ code. It offers “push protection” that blocks the accidental publication of secrets that can cause security vulnerabilities. This is a significant advance in application security.

Image Credits: Suridata

What Is a Secret?

For GitHub users, the word “secret” has a meaning that’s distinct from the general understanding of the word. In the context of GitHub and software development, a secret is any kind of private information, such as a token, password, or private authentication used by a service provider to enable interactions between applications. The development of software frequently involves the use of secrets and the embedding of those secrets in code.

With secrets, however, comes the risk that a secret has been compromised. A developer might commit a secret to a piece of code without noticing, and by doing so, reveal it publicly — rendering the secret to be insecure. In other words, the secret is not a secret anymore. Its ability to provide unique, private connections is no longer assured. A malicious actor can use the secret as a stolen credential to mount an attack.

GitHub’s New Secret Scanning Push Protection

To mitigate the risk of embedding secrets into code and making them public, it is necessary to scan the code for the existence of the secret prior to publishing it. A developer should not use a secret in the code, especially if the code is published on the internet. That sounds simple enough, but there are two challenges in this scenario. One is correctly identifying secrets within the code, as they vary in structure from one service to another. Then, there’s the prevention. How will the developer know if he or she has secrets in their code before publishing it?

GitHub offers a solution. It has offered a built-inservice that detects secrets and alerts developers if those secrets are in their code. This feature is useful, but it only scans code that has already been published. This is not ideal, because it makes application security reactive in nature. Inevitably, some leaked secret vulnerabilities would fall between the cracks. 

The new “push protection” feature, recently announced by GitHub, changes the dynamics of the situation. Push protection checks for more than one hundred types of tokens/secrets as developers push code into production. It blocks the push if it detects the presence of a secret. GitHub describes the process as scanning for what it calls “high-confidence secrets,” which has a low rate of false positives. 

Push protection has two goals. First, it stops secrets from getting into code. Second, it aims to keep code secure without disrupting the developer’s experience. The alerts are built into the developer’s integrated development environment (IDE) or command line interface(CLI). The alert may contain recommendations for remediating the problem. This approach enables developers to review alerts and remove secrets from their code before they push it again. If the suggested remediation does not work, or makes sense, the developer can move ahead with the push by resolving the secret as a test case or false positive. Or he or she can flag it as a real instance but fix the issue later. 

A developer can bypass the push protection.However, in that event, GitHub creates a closed security alert. If the developer flagged a secret as something to deal with later, GitHub generates an open security alert so the developer and repository admin can collaborate on remediation when they are ready to tackle the problem.

Why Push Protection is a Big Deal

It may not seem like push protection is a major advance in AppSec. It’s an incremental feature that adds to GitHub’s existing secret scanning capabilities. However, it is a significant development because it shifts code protection from being reactive to proactive. Now, instead of waiting for scans of published code to reveal the presence of secrets, developers can know about secrets before they commit and push the code into production. This makes the code more secure.  

Secret scanning’s push protection is already delivering results. Since its beta release in April 2022, when it was made available to GitHub Advanced Security users, push protection has prevented 17,000 potential secret leaks. This resulted in savings of over 95,000 hours that would have been spent revoking, rotating, and remediating exposed secrets.


The leak of a secret exposes applications to risk. Existing reactive methods of detecting and remediating secret leaks were deficient. They were not aligned with the way developers worked, and they allowed for too much time to elapse between the discovery of a leak and its correction, if in fact such a correction ever occurred. GitHub understood that developers had to be part of the solution, empowered to deal with secrets, but in a way that would not negatively affect their productivity or overall experience. Secret scanning’s push protection is the solution. It enables proactive detection and remediation of leaked secrets.

Suridata will make sure your GitHub configuration is set to enable the new push protection feature. For more information, contact us.

Haviv Ohayon

Co-Founder & COO

Back to list

Identifying SaaS App Risks

SaaS vendors tend not to enforce strong security settings by default. Rather, they leave the details up to the client’s discretion. They do this mostly to reduce their responsibility for security. They also want to make their services less complex and easy to use, but nonetheless, the result is security risk exposure. Moreover, system administrators may inadvertently change and lower existing security settings, creating risk exposure in the process. If left untreated, inadequate security settings may allow external attackers, as well as malicious insiders, to access the SaaS. This could lead to the loss of data and other negative outcomes, such as system shutdowns, data breaches, denial of service attacks, increased expenses, and more. This article explores the issue, examining SaaS app risks and offering an approach to their mitigation.

Image Credits: Suridata

A Growing Area of Risk Exposure

The scale of SaaS activity is one reason why risks can be such a challenge with SaaS apps. According to, the average organization uses 130 SaaS apps.Each app has hundreds of unique controls and settings that are subject to adjustment at will. Users have expectations for SaaS apps that may run counter to what security teams want. It can get tricky to balance security with functionality, a problem that can get more difficult to address as SaaS apps interact with one another.

The Impact of a Dynamic Environment

The dynamic nature of SaaS apps is a further factor complicating their security. SaaS apps seldom sit still. Their makers update them frequently—in some cases every day. This is one of the great things about SaaS. Users don’t have to wait for new versions. They appear automatically in the browser, usually as the result of Continuous Integration/Continuous Delivery (CI/CD) pipelines that push new code into production. The difficulty with this process is that new code often affects security settings. 

Security teams may struggle to keep up, leading to a situation known as “configuration drift.” Additionally, because frequent updates to SaaS features usually result in a need to change security settings, security teams may let users change their own settings – granting excessive permissions to users so they can perform this task. The problem is that the security team may then fail to revoke those permissions at a later time. This creates risk exposure.

A Brief Note about Shared Responsibility for SaaS Security

SaaS apps work on a shared security model. This means that the vendor covers certain areas of security, such as the protection of the vendor’s physical infrastructure, networks, application security, and server operating systems. The customer is responsible for its own data security and user access controls, along with numerous security settings.This model makes sense, because the vendor cannot possibly know how to assign access privileges for the customer, to name but one example. However, the shared model can lead to confusion and omissions in security practices on the part of the customer.

Drivers of Common, but Serious SaaS App Risks

SaaS apps are exposed to risk through a variety of factors. Some of the most common include:

Misconfigurations — SaaS apps offer users and admins many configuration options, some of which can expose the user to risk. For example, Google Drive shares are available to anyone by default. This means that sensitive data could accidentally be exposed to virtually any malicious actor if this default configuration is not changed.

Deficient access management controls — Most SaaS apps allow access based on just a user name password pair. This is not secure, given the prevalence of credential stuffing attacks and comparable threats. A better practice is to implement multi-factor authentication (MFA). Risks can also arise out of misconfigured single sign on(SSO) solutions, which can accidentally allow unauthorized users to access SaaS once they have signed in elsewhere.

Third-party risks — Some SaaS apps can integrate with other, third-party SaaS apps, e.g.,using a plugin to connect a SaaS to a SaaS-based storage app, and so forth.These plugins can create risk because they may be given access permissions that are not aligned with security policies.

In attention to regulatory compliance factors — The customer is responsible for many important aspects of regulatory compliance, e.g., protecting consumer data privacy, abiding by “data sovereignty” laws, and so forth. If SaaS owners do not pay adequate attention to compliance, they can increase risks of compliance penalties and costly remediations.

Data management oversights — The SaaS vendor is not responsible for data management.It is up to the customer to define and enforce the necessary data security policies, e.g., encryption, data retention and lifecycle, and privacy controls.Without such policies, storing data in a SaaS app creates data security risk.

Lack of strong password policies — Deficient password policies can lead to excessive risk of breach, e.g., if users can choose simple passwords, and are not required to change them periodically, it becomes easier for a malicious actor to gain entry to the system, especially if MFA is not in use. It’s worth noting that not all security professionals agree that strong passwords lead to better security. Ina great example of unintended consequences, a requirement to maintain strong (i.e., difficult-to-remember) passwords can cause users to employ the same password for multiple systems, which creates risk exposure. 

In attention to account statuses — When users leave their jobs, or switch to departments where they will no longer need access to a SaaS app, it is essential to switch off their access. This does not always happen, which leads to the risk of unauthorized access. The web-based nature of SaaS makes this risk particularly acute, as a former employee can access the SaaS from home and access data to which he/she has no permission to access. These are sometimes called “zombie accounts.” Sharing of accounts is a related risk, one that exposes the organization using the SaaS app to risk of unauthorized access.

Detecting and Mitigating SaaS App Risks

What can be done to mitigate such SaaS app risks? The simple answer is that the SaaS client must constantly monitor and correct the SaaS security settings to properly protect it. However, considering the number of SaaS apps at the average business, it becomes obvious that any manual processes for monitoring and correction of security settings is going to be unfeasible. There are simply too many apps and too many variables to keep track of, especially in a dynamic environment. Undetected risk exposure is a virtual certainty.

The mitigation of SaaS app risks will require automated risk detection and remediation processes. Specialized solutions, now on the market, can continually scan SaaS apps and flag potential security risks. They can then automatically address risks caused by misconfigurations, zombie accounts, and so forth. These tools can be set to conform with an organization’s unique security policies.


SaaS app risk is, or should be, a main area of focus for cybersecurity teams and their partners in IT operations. The potential for data breaches and system outages looms if SaaS security weaknesses are not discovered and addressed. It can be a daunting subject, though, given the number of apps in question and the range of security configurations present in each app. Solutions are available, however. They leverage automation to overcome the administrative burden of detecting and mitigating SaaS app risks.

Haviv Ohayon

Co-Founder & COO

Back to list