The accelerated adoption of software as a service (SaaS) has fundamentally changed software consumption patterns, but it has also introduced a significant concentration of risk across enterprise environments and global critical infrastructure.
JPMorganChase CISO Pat Opet laid out the threat in "An open letter to third-party suppliers," warning of the risks that SaaS brings and stating that third-party software risk management (TPSRM) is essential to any enterprise's security.
Opet's call to action described these risks as rapidly escalating, noting that many SaaS vendors are prioritizing speedy feature delivery over robust security practices. Here are the key takeaways for your organization — and how a SaaSBOM can bolster your TPSRM.
[ Report: Beyond the SBOM | Webinar: CycloneDX's xBOM | Learn about RL's SaaSBOM ]
SaaS' ubiquity equals Danger
Opet wrote that SaaS had become the default — "and is often the only format in which software is now delivered, leaving organizations with little choice but to rely heavily on a small set of leading service providers."
"While this model delivers efficiency and rapid innovation, it simultaneously magnifies the impact of any weakness, outage, or breach, creating single points of failure with potentially catastrophic systemwide consequences."
—Pat Opet
Opet's letter chronicles Chase’s firsthand struggles with multiple incidents among its third-party SaaS providers over the past three years. The supply chain incidents forced the company to isolate compromised vendors and pour significant resources into threat-mitigation efforts, Opet said.
At a broader level, rapidly growing SaaS and API-driven integrations are eroding traditional security boundaries and introducing significant risk through overly permissive identity protocols, weak token management, and opaque third- and fourth-party dependencies, Opet cautioned. Modern SaaS architectures are "upending traditional security approaches" and "eroding decades of carefully architected security boundaries," Opet argued.
Traditional security approaches are failing
Well-tested security practices such as network segmentation, protocol termination, and layered trust zones are being systematically dismantled by modern SaaS integration approaches, Opet said. The SaaS model's identity-based integrations — often built on protocols such as OAuth — have completely blurred the line between internal and external systems while reducing authentication and authorization to dangerously simplistic, token-based access. And threat actors — many of whom are backed by nation-states — are increasingly targeting these weaknesses.
"This architectural regression undermines fundamental security principles that have proven durability."
—Pat Opet
Opet makes some key points about the growing risks introduced by the widespread adoption of SaaS as the default software delivery model. Outages, breaches, and software vulnerabilities have already disrupted entire industries, and more is likely to come. Examples include Progress Software's disclosure last year that the vulnerabilities CVE-2024-5806 and CVE-2024-5805 had been introduced into its MOVEit file transfer application and had impacted numerous corporations and government agencies. Another striking example is the global disruption to Windows systems caused by a faulty CrowdStrike update in 2024.
Why TPSRM is now essential
These incidents reveal just how much exposure organizations — and entire industries — face due to their dependency on a small number of critical software providers. But that's the trade-off organizations made, said Scott Johnson, vice president of product management at Black Duck. Most companies moved to SaaS as a way to reduce capital costs and the management overhead of traditional on-premises updates, Johnson said. But SaaS risks are significant and growing, he added. "Of course, SaaS has more impactful risks, and probably no matter how securely designed will still have risks given the shared infrastructure usage that if infiltrated or compromised inherently impacts entire industries using those solutions," Johnson said.
Avoidable misconfigurations and the adoption of remote work and BYOD often exacerbate SaaS-related security challenges. Obsidian Security researchers recently found that one out of every six breaches stemmed from a posture-related misconfiguration of a SaaS or platform-as-a-service (PaaS) application.
Third-party shadow SaaS applications are another factor, said Omri Weinberg, CEO at DoControl. The flexibility and scalability of SaaS apps have often resulted in individual users and business groups within organizations adopting SaaS applications without the IT team's knowledge or consent. The trend is introducing significant risk through unchecked access and hidden permissions, he said.
"While SaaS vendors have a responsibility to improve by offering secure-by-default settings and greater transparency, they can’t solve this issue alone. The scale and complexity of modern SaaS ecosystems require dedicated security [approaches] that deliver contextualized visibility, risk scoring, and governance controls."
—Omri Weinberg
Last year, the Australian Signals Directorate — a member of the so-called Five Eyes Intelligence alliance— warned of Russia intelligence groups pivoting from endpoint malware to identity-based SaaS attacks as their initial access vector. That is just one example of a growing trend among threat actors to target SaaS platforms, said Sean Roche, senior director of product marketing and value engineering at Obsidian Security. "SaaS is the latest target for sophisticated nation-state actors," he said.
Security teams have invested in controls to protect authentication to SaaS applications. However, these tools are typically blind to the fast-growing SaaS-to-SaaS data movement that is not governed or monitored, Roche said.
"The lack of visibility into the applications, identities, and app-to-app connections in corporate environments hides risk and creates an ever-growing unknown attack surface."
—Sean Roche
The call to action is clear
Opet's open letter demanded that SaaS providers prioritize security as a core design principle. He wants SaaS providers to embed secure-by-default configurations and granular access controls to prevent vulnerabilities.
Specifically, the letter lays out core new requirements for improving TPSRM:
- Software providers must prioritize implementing security over rushing out features. Comprehensive security should be built in or enabled by default.
- We must modernize security architecture to optimize SaaS integration and minimize risk.
- Security practitioners must work collaboratively to prevent the abuse of interconnected systems.
He urged organizations to reject SaaS integrations that sacrifice safety for convenience and called for collective action around areas such as self-hosting SaaS applications. "Providers must urgently reprioritize security, placing it equal to or above launching new products. 'Secure and resilient by design' must go beyond slogans — it requires continuous, demonstrable evidence that controls are working effectively, not simply relying on annual compliance checks," Opet said.
How the SaaSBOM can improve your TPSRM
CycloneDX's extended bill of materials (xBOM) standard defines a SaaSBOM as a way to represent critical details about networking services used by a software application. Dave Ferguson, director of technical product management at ReversingLabs, wrote recently about how RL's SaaSBOM provides new insights and explained how a SaaSBOM expands on the concept of an SBOM by providing an inventory of external services — and details such as service name, specific API endpoints, data classifications, directional flow of data, and authentication requirements.
External services function as remote dependencies, and they’re just as integral to the security of an organization’s software supply chain as the open-source libraries and commercial components built into its applications. As with any other dependency, relying on these services can introduce risk to the environment, Ferguson wrote.
Examples of potential issues that can arise with third-party services:
- Exposed PII: A user identity or tracking service requires access to your customers’ personally identifiable information. Sharing this data increases the chance of exposure, especially if the third party’s systems are vulnerable or lack strong security controls.
- Vulnerable APIs: Most services are accessed through REST APIs, which can contain exploitable vulnerabilities. The OWASP Top 10 API Security Risks outlines common pitfalls developers face when security is overlooked.
- Inadequate monitoring: Insufficient logging or monitoring by a service can hinder the ability to detect and respond to threats or anomalous behavior.
- Manipulation: A compromised file exchange service could be manipulated to deliver malware instead of legitimate files, putting downstream systems at risk.
- Failed isolation: Many third-party providers — especially those in the cloud — operate on shared infrastructure. If proper data isolation isn’t enforced, customer data, intellectual property, or workloads could be exposed or compromised.
"SBOMs have been part of the mainstream for some time, offering valuable insight into the components included in a software package. However, they don’t provide complete visibility into all dependencies — particularly external services. That’s where SaaSBOMs come in, offering a deeper layer of transparency by identifying third-party services in use."
—Dave Ferguson
In a recent IT GRC Forum webinar, where ReversingLabs was a key participant, attendees were asked which emerging BOM type — SaaSBOM, ML-BOM, or cryptography BOM — would be most helpful to meet their compliance and security goals, Ferguson said. With 259 attendees voting, SaaSBOM was the clear winner, with 46% of the votes. ML-BOMs garnered 18% of the votes, and CBOMs managed 10%.
Learn more about how RL Spectra Assure's SaaSBOM can get a handle on SaaS risk by providing software transparency.
