
The Adventure of the Compromised Keys
The recent Commvault incident reveals something troubling about how we approach cloud security. Itâs not just another breach story; itâs a case study in how our assumptions about SaaS safety can backfire.
Hereâs what actually happened: Attackers infiltrated Commvaultâs systems and accessed client secrets for their Microsoft 365 backup service, Metallic. This gave them a pathway into some customersâ M365 environments, specifically those using the backup service with application secrets managed by Commvault. While not every Commvault customer was affected, those who were found themselves in an uncomfortable position: their security had been compromised through a service they trusted to protect them.
CISA believes this incident may be part of a broader campaign targeting SaaS providers. The logic is compelling from an attackerâs perspectiveâwhy target individual companies when you can compromise a service provider and potentially access multiple customer environments at once?
This should give pause to anyone using SaaS services with deep integrations into their core systems. Which, letâs face it, describes most modern businesses.
The Trust Paradox
The fundamental challenge here isnât technical. Itâs architectural and philosophical. When we integrate with SaaS providers, weâre making a bet that their security practices will hold up under pressure. Sometimes that bet pays off. Sometimes it doesnât.
Consider what happened with Commvaultâs M365 backup customers. They made a reasonable decision: outsource backup management to specialists who presumably know what theyâre doing. They granted Commvault the necessary permissions to access their M365 environments. Everything worked smoothly until it didnât.
This creates an interesting paradox. The more valuable a SaaS service becomes to your operations, the more access it typically needs. But the more access it has, the more damage a compromise can cause. Weâre constantly balancing convenience against risk, often without fully understanding where that balance point lies.
The security certifications and compliance frameworks that companies rely on provide some comfort, but theyâre snapshots in time. They tell you a company had good processes when they were audited, not whether those processes will withstand a determined attacker six months later.
Beyond Shared Responsibility
The shared responsibility model that governs most cloud relationships isnât wrong, but itâs more nuanced than most people realize. Yes, youâre responsible for your data and access controls, while your cloud provider handles infrastructure security. But when you grant a third-party service elevated access to your cloud environment, youâre creating dependencies that blur these clean lines of responsibility.
In the Commvault case, customers were managing their side of the responsibility equation properly, but they couldnât control how Commvault secured the credentials needed to provide the backup service. When that credential management failed, the shared responsibility model didnât provide much consolation.
This doesnât make the model useless, but it does highlight its limitations. When youâre evaluating SaaS providers, the standard questionnaires and compliance certifications only tell part of the story. They donât reveal how a provider manages the specific credentials and access they need to serve you, which is often where the real vulnerabilities lie.
There are some lower-effort alternatives emerging. Security rating services can provide continuous, external assessments of vendors without requiring lengthy questionnaires or internal audits. These services monitor publicly observable security indicators like SSL certificate management, DNS configuration, and known vulnerabilities to generate ongoing risk scores. SaaS Security Posture Management (SSPM) tools can automatically monitor your existing SaaS integrations for misconfigurations, excessive permissions, and policy violations.
Some organizations are also exploring simplified assessment frameworks. CAIQ-Lite, for example, reduces the traditional Cloud Security Alliance questionnaire from 261 questions to a more manageable subset focused on critical controls, allowing for more frequent reviews with less effort.
But these alternatives have their own limitations. External security ratings canât see inside a providerâs systems to assess credential management practices. SSPM tools only help after youâve already integrated a service. And simplified questionnaires, while more efficient, provide even less insight into the security practices that matter most.
The Reactive Response
CISAâs response to the incident follows a familiar pattern: monitor your logs more carefully, restrict access where possible, implement conditional access policies, rotate credentials regularly. For on-premises systems, they recommend restricting management access and patching the known vulnerability.
These are sensible recommendations, but theyâre inherently reactive. They help you detect problems faster and limit damage when things go wrong, but they donât address the underlying structural issues that make these incidents possible in the first place.
The challenge is that most organizations approach SaaS security as a checklist exercise. Review the vendorâs security documentation, check their compliance certifications, maybe run a basic security assessment, then hope for the best. This process works reasonably well for identifying obvious red flags, but itâs less effective at predicting how a provider will handle sophisticated attacks.
Thinking Differently About Integration
What if we approached SaaS integration differently? Instead of asking âIs this provider secure enough?â we might ask âHow can we limit the impact when something inevitably goes wrong?â
This shift in thinking leads to different decisions. You might choose service accounts with more restrictive permissions, even if it makes the integration slightly more complex. You might implement additional monitoring specifically for SaaS-related activities. You might develop procedures for rapidly rotating credentials when incidents occur.
Several established frameworks support this approach. NISTâs Cybersecurity Framework emphasizes the âprinciple of least privilegeâ for access controls, while Microsoftâs Cloud Adoption Framework provides specific guidance for managing service principal permissions in cloud environments. For credential rotation, OWASPâs Application Security Verification Standard recommends automated rotation schedules and secure secret storage practices.
Zero trust architectures and proper secrets management can help, but they require upfront investment that many organizations are reluctant to make. Itâs easier to rely on your SaaS providerâs security assurances than to build additional safeguards into your own environment.
The honest truth is that thereâs tension between convenience and security, and that tension doesnât disappear just because weâd prefer it to. Sometimes the most convenient integration option isnât the most secure one, and vice versa. Acknowledging this trade-off is the first step toward making better decisions.
The SolarWinds breach offers a perfect example of this tension. Security researcher Vinoth Kumar discovered that SolarWinds had exposed FTP server credentials in a public GitHub repository from June 2018 to November 2019, with the password being simply âsolarwinds123â. SolarWinds had also been advising customers to disable antivirus tools before installing their software, prioritizing ease of installation over security.
These werenât technical oversights. They were deliberate choices that favored convenience. Using simple passwords makes system administration easier. Telling customers to disable security software eliminates support calls about installation conflicts. But these âconvenientâ practices created the vulnerabilities that sophisticated attackers later exploited in what became one of the most damaging supply chain attacks in history.
The Reasoning Problem
Hereâs what troubles me most about how we handle these decisions: we often work backward from the conclusion we want to reach. Someone in marketing discovers they absolutely must have a new social media scheduling tool that connects to seventeen different platforms and stores all your customer data in a server farm somewhere in Eastern Europe. The security team then performs what can only be described as policy yoga, bending and stretching their âzero trustâ framework until it somehow accommodates giving a third party administrative access to the companyâs entire digital presence.
By the time theyâre done, the original policy resembles something you might find at the bottom of a lawyerâs briefcase after a particularly bumpy flight. The tools get approved, the policies get âupdated for modern business needs,â and everyone pretends this was a thoughtful risk assessment rather than an elaborate justification for something theyâd already decided to do.
This isnât malicious. Itâs human nature. We want the productivity benefits that SaaS tools provide, so we find ways to rationalize their adoption. But rationalization isnât the same as reasoning, and the difference matters when youâre making decisions about risk.
Proper reasoning would start with security principles and work forward to conclusions about specific tools. If your principle is âminimize third-party access to core systems,â then certain SaaS integrations become harder to justify. But instead of questioning the integrations, we often question the principles.
Looking Forward
The Commvault incident wonât be the last of its kind. As business processes become more dependent on SaaS tools, and as the connections between different services become more complex, these supply chain attacks will likely become more common.
The organizations that adapt successfully will be those that develop better frameworks for thinking about SaaS risk. This means going beyond compliance checklists to understand the actual security implications of the integrations theyâre considering. It means building systems that can gracefully handle provider compromises. And it means being honest about the trade-offs between convenience and security.
The technical solutions exist: better access controls, improved monitoring, more sophisticated secrets management. The challenge is building organizations that consistently apply these solutions, even when it means accepting some friction in exchange for better security.
Thatâs not just a technology problem. Itâs a thinking problem. And thinking problems require us to be more deliberate about how we reason through risk, rather than just hoping someone else has figured it out for us.
The question isnât whether your SaaS providers will ever be compromised. They will be. The question is whether youâll be ready when it happens.
Consider what happened in just the past few years: LastPass was breached twice in 2022, leading to over $150 million in cryptocurrency thefts as attackers cracked stolen master passwords. Okta, the identity provider that millions of organizations trust for access control, was compromised in 2023 when attackers used session cookies from customer support files to impersonate users and bypass multi-factor authentication. Microsoftâs own cloud services have been breached multiple times, including a 2024 incident where Russian hackers accessed senior executive emails using password spraying against accounts without two-factor authentication.
These arenât small companies with weak security practices. These are the providers that the rest of us rely on to keep our own systems secure. LastPass had a dedicated security team and regular audits. Oktaâs entire business model depends on security credibility. Microsoft spends billions annually on cybersecurity research and employs some of the worldâs top security experts.
Yet they all fell victim to relatively straightforward attacks: password spraying, credential theft, and social engineering. The attackers didnât need to discover zero-day exploits or deploy sophisticated nation-state malware. They succeeded using techniques that any competent cybercriminal group could replicate.
If companies whose core business is security, with virtually unlimited resources and the best talent money can buy, canât prevent these basic attacks, what makes you think your backup service or productivity suite will fare better? Your typical SaaS provider has a fraction of the security budget, fewer dedicated security personnel, and faces the same fundamental challenges around human error and system complexity that brought down the big players.
The uncomfortable truth is that if LastPass, Okta, and Microsoft can be compromised, everyone can be compromised. The question isnât whether it will happen to your providers. Itâs whether youâll have designed your systems to survive when it does.
You Might Also Like
Discover more articles related to your interests

The Post-Quantum Crisis
An analysis of the new NIST cryptographic standards and the global migration to protect against quantum computing threats.

The End of Passkey Prison
The FIDO Alliance's new CXP and CXF specifications aim to solve passkey vendor lock-in, enabling users to move their digital credentials. This article explores these standards and their impact on digital identity.

Unmasking Softwares Hidden Depths: The Supply Chain Security Challenge
Exploring software supply chain security risks, recent high-profile incidents, and how Software Bills of Materials (SBOMs) provide essential transparency and protection

Putting Numbers on Fuzzy Risks: The FAIR Approach
How to transform vague security risk assessments into quantifiable values you can use for business decisions using Factor Analysis of Information Risk (FAIR)