Most organizations I work with have invested heavily in cloud security. They have endpoint detection tools, SIEM platforms, cloud security posture management, and skilled security teams running on a 24/7 shift. And yet, when I ask them a simple question — who has admin access in your Salesforce tenant right now? — The room goes quiet. Nobody knows. Not because they are negligent. Because they genuinely cannot see it.
That is the SaaS blind spot.
Ashish Mishra
SaaS: Numbers speak volumes
I ask this question in almost every engagement: how many SaaS applications does your organization run? The answers I get range from 30 to maybe 50. The real number, once someone counts, is usually north of three hundred. AppOmni’s 2024 research put it even higher — 49% of Microsoft 365 organizations believed they had fewer than ten apps connected to their tenant when the actual average was over a thousand.
Here is the part that concerns me more than the count. Of all those applications, security teams have clear sight into maybe one in 10. The rest — where your customer records live, where your source code sits, where your financial reports get shared — nobody is watching. Not because the team is careless. Because the tools they have were never built to look there.
The following incidents will discuss these realities.
Salesforce in 2023
In April 2023, KrebsOnSecurity broke the story — Salesforce Community sites were quietly leaking sensitive data belonging to government agencies, banks, and healthcare providers. No sophisticated attack technique. Just the right API endpoint and a misconfigured guest user profile. The exposed records included Social Security numbers, account details, and home addresses. Salesforce was clear in its response: this was not a platform vulnerability. Administrators had misconfigured guest access policies, and nobody had checked.
Guest user profiles in Salesforce Communities can be granted access to data records. When administrators set those permissions too broadly — often without realizing it — unauthenticated external users can query that data straight through the API. Over 150,000 companies were potentially sitting in that window before anyone raised the alarm.
The pattern is always the same. Configuration made under time pressure, default set slightly too permissive, nobody looks at it again. SaaS applications accumulate these quiet exposures over months and years.
GitHub in 2022
In April 2022, GitHub disclosed that an attacker had used stolen OAuth tokens — issued to Heroku and Travis CI — to access and download private repository contents from dozens of organizations, including npm. GitHub’s own systems were never touched. The tokens came from third-party applications that users had authorized to connect to their accounts, and those applications had been quietly compromised.
The entry point was not GitHub. It was not even the organizations that lost their data. It was the CI/CD tools those organizations had connected to GitHub months or years earlier — tools that had been granted broad read and write permissions that were never revisited.
That is the OAuth problem in plain terms. The moment you authorize a third-party application; its security posture becomes your problem too. Most organizations have dozens of these connections sitting open across their SaaS platforms — and no one reviewing them.
Ashish Mishra
Microsoft in 2023
The Microsoft case from 2023 is the one I bring up when people assume this only happens to careless organizations. Wiz Research found that Microsoft’s own AI team had exposed 38TB of internal data — private keys, passwords, and more than 30,000 internal Teams messages — through a single misconfigured Azure access token. The token was supposed to share one training dataset on GitHub. Instead, it opened an entire storage account to anyone who found the link.
What gets me about this one is the timeline. That token had been sitting there since October 2021. Nearly two years, inside Microsoft, before anyone caught it. If a team with that level of resources and expertise can leave a door open for two years, the idea that “we’d notice” is not much of a security strategy. And it’s worth noting — this wasn’t a database leak. It was Teams messages. The same collaboration tools your employees use every day are just as exposed as the platforms holding structured records.
Why traditional security tools miss this
Cloud Security Posture Management tools — CSPM — are designed to monitor infrastructure configuration: virtual machines, storage buckets, network rules, and IAM policies at the infrastructure level. They do an acceptable job at that layer. What they do not do is look inside SaaS applications. CISA’s Secure Cloud Business Applications (SCuBA) guidance specifically calls out the gap between infrastructure security tools and SaaS-layer visibility as one of the most under addressed areas in enterprise cloud security.
This is the gap SSPM was built to close. Instead of watching infrastructure, it watches the configuration of the SaaS applications themselves — permissions, sharing settings, who has access to what. And the distinction is not just academic. Infrastructure misconfigurations tend to expose systems. SaaS misconfigurations tend to expose data — directly, quietly, and often without any detectable attack activity at all.
Ashish Mishra
What security teams should do now
You do not need to deploy a full SSPM platform tomorrow to start closing the gap. There are practical steps that move the needle immediately.
Audit connected OAuth applications across your primary SaaS platforms. Revoke any integration that cannot be justified by a current business need.
Common source of public data exposure: Review guest and external sharing permissions in Salesforce Communities and Microsoft SharePoint.
Check whether legacy authentication protocols are disabled in Microsoft 365. Legacy auth bypasses MFA and becomes a potential entry point in enterprise environments.
Establish a quarterly access review for high-privilege accounts in SaaS applications. Most organizations run annual reviews at best — that is not frequent enough for platforms that change configuration daily.
A map of which SaaS applications hold sensitive data, and which have no security team ownership at all. That list will be longer than you expect.
The core issue is not that organizations are careless. It is that they have built security programs around the perimeter and the infrastructure, and SaaS applications grew up inside that perimeter without ever being brought into scope. The data is there. The access is there. The misconfiguration is often there too. What has been missing is the visibility to see it.
SSPM closes that gap. But even before a formal tool is in place, simply asking the question — what can the applications we already run see and share? — is a meaningful first step. In my experience, the answer surprises almost every organization that takes the time to look.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
No Responses