The cloud gives businesses scalability, agility, and built-in resilience. But it’s created a dangerous illusion: that moving workloads to SaaS platforms and managed services automatically makes them secure.
Reality: the cloud doesn’t erase risk, it shifts who holds responsibility.
You can patch what you own. When the system isn’t yours, patching becomes someone else’s problem. Recent high-profile breaches prove that blind spots can put entire organisations at risk.
SaaS security risks: when cloud vendors become attack surfaces
Case 1: Okta (late 2023)
Attackers compromised Okta’s customer support portal and stole valid session tokens. They impersonated customers and accessed sensitive systems. No customer could patch their way out; the breach was upstream, inside the provider.
Case 2: Salesloft/Drift (2025)
Attackers stole OAuth tokens tied to Salesforce integrations, queried customer environments, and exfiltrated data. Customers couldn’t patch the vulnerability; it sat inside a third-party integration.
The message is clear: in a SaaS-first world, attackers don’t need to target your infrastructure when they can target the providers you depend on. And when they do, you’re left with consequences, not control.
The hidden web of SaaS dependencies
Modern organisations rely on dozens, sometimes hundreds, of cloud services. Some are obvious (productivity suites, CRMs). Others lurk quietly in the background (plugins, API connectors, embedded SDKs). Each one expands your attack surface, and most sit outside your patch management cycle.
Here’s what most security teams miss:
| Dependency type | The risk | How attackers exploit it |
| Core SaaS platforms | You rely on their security updates and monitoring | Support system breach exposes tokens across all customers |
| APIs and partner integrations | Vulnerable APIs expose your data directly | Stolen tokens let attackers impersonate legitimate connections |
| Third-party plugins / connectors | Small vendors patch slowly, if at all | Vulnerable CRM add-ons open doorsto core customer data |
| Embedded SDKs / libraries | Indirect vulnerabilities become your problem | Compromised logging or analytics library runs in your environment |
| Shadow SaaS | Entire platforms exist outside IT oversight | Teams spin up unapproved tools handling sensitive data with zero security review |
You remain accountable, even when you’re not fully in control.
Why traditional patching fails for SaaS security
Traditional security thinking says patching fixes problems. But in the cloud:
- You don’t control the patch cycle. Vendors update on their schedule, not yours.
- Attackers don’t need zero-days. Stolen tokens and misconfigured APIs work just as well.
- Persistence is easy. Even after a vendor applies a fix, stolen credentials or exfiltrated data remain compromised.
- Blind spots multiply. Integrations and shadow SaaS create entry points you may not even know to protect.
Patching is necessary, but never sufficient.
SaaS security best practices: building resilience against the unpatchable
If you can’t patch what you don’t own, how do you defend against it?
Shift from a patch-first mindset to a visibility and resilience-first strategy.
- Map your entire SaaS landscape
Use discovery tools and internal audits to uncover every platform, plugin, and integration. Unknown dependencies are your biggest risk. - Harden your integration boundaries
Treat SaaS connections as lower-trust zones. Enforce strong access controls, network segmentation, and API mediation. Zero trust isn’t optional. - Embed security into vendor contracts
SLAs must include breach notification timelines, patch commitments, and access to security logs. Without contractual leverage, you’re accepting blind trust. - Prioritise detection over prevention
Monitor SaaS sessions, API calls, and credential use for anomalies. Assume compromise and focus on detection speed. - Rotate credentials and keys frequently
Stolen tokens and keys are the real prize for attackers. Keep their lifespan short to limit persistence. - Exercise your SaaS breach playbook
Run tabletop exercises for scenarios where your provider is compromised. Most organisations don’t prepare for this. Attackers count on that.
Offensive Security: The Missing Counterweight
The biggest risk with SaaS security? Complacency. Trusting your providers to handle security while attackers actively probe for weak spots in your SaaS estate.
Attackers exploiting cloud security vulnerabilities don’t wait passively. They probe continuously, hunting for overlooked misconfigurations, stale credentials, and forgotten integrations.
The only way to stay ahead is to match their approach.
Continuous offensive security means:
- Actively probing your SaaS estate for misconfigurations and weak points.
- Simulating real-world attacker behaviour against your integrations and APIs.
- Identifying how far an adversary could pivot if a single SaaS dependency was breached.
- Stress-testing your systems and your assumptions about vendor security.
This isn’t a one-off pen test. It’s a persistent, adaptive practice, matching the persistence of adversaries who don’t respect quarterly testing cycles.
Rethinking SaaS security in a multi-vendor world
The cloud transformed business. It also created new blind spots. Every SaaS platform, every plugin, and integration is a potential attack surface you can’t patch yourself.
The Okta and Salesloft breaches prove that “everything in the cloud” doesn’t mean “everything is safe.” Security teams must adapt by demanding visibility, building resilience, and preparing for provider compromise as an inevitability, not a remote possibility.
More importantly: security must shift from defensive patching to continuous offensive discovery. Because if you’re not testing your SaaS blind spots, attackers already are.
Test your SaaS blind spots before attackers do
At CovertSwarm, our continuous offensive security model operates without pause, simulating the exact adversaries who exploit SaaS dependencies. We don’t wait for quarterly pen tests. Attackers don’t either.
Want to understand how an attacker could move through your cloud estate tomorrow, not just how it looked in the last quarter? See how we test cloud environments.
