In 2025, cybersecurity is more difficult to manage than ever. One of the factors is our antiquated “SaaS” approach. JP Morgan’s CISO, Patrick Opet, recently made a case for why we need to throw away the whole system and start anew.
In the current landscape, we are seeing an upward trend of attacks, and this is only continuing to rise. The way we’ve been approaching applications needs to change drastically to address the growing risk vectors. In this blog, we’ll talk about what the responsibility of SaaS vendors is towards their customers, and what needs to change.
The Software as a Service, or “SaaS” model has led to enterprise organizations relying on a number of external providers, and while this system can be efficient in developing new applications and models, it can also be a security liability.
Now, if one customer of a SaaS platform has a breach, there’s a good chance the other customers who used the same platform will also be affected. The potential for incidents to have ripple effects that could expand on a global scale is now a very real issue.
“At JPMorganChase, we've seen the warning signs firsthand. Over the past three years, our third-party providers experienced a number of incidents within their environments. These incidents across our supply chain required us to act swiftly and decisively, including isolating certain compromised providers, and dedicating substantial resources to threat mitigation.”
According to Opet, SaaS models have effectively “reshaped” how companies integrate services.
Before SaaS, security teams would enforce segmentation, boundaries, and more around applications and access to the data into those applications. However, modern integration patterns rely heavily on identity protocols such as OAuth to create “direct, often unchecked interactions between third-party services and sensitive internal resources” (Patrick Opet).
This means that the likelihood of compromise can be much higher, since companies are depending on already-existing technologies to secure their new technologies, potentially leading to many issues falling through the cracks. Patrick states that, “the most effective way to begin change is to reject these integration models without better solutions.”
Automated or AI-powered integration models will overly simplify functions authentication and authorization, “effectively creating single-factor explicit trust between systems,” which is obviously a problem for a number of reasons. And the effects it could have on so many applications is staggering.
FireTail builds security into our applications from code to cloud. We take application security seriously because it’s what we do!
FireTail is built on APIs and designed to protect APIs. So when it comes time to secure FireTail, we run it on FireTail! Dogfooding our product and being “customer one” has allowed us to stay on top of API-based authentication and authorization and create the leading tool in the space.
And while we do allow customers to use single sign-on (SSO), we require multi-factor authentication (MFA) of all users, whether they are administrators on the FireTail platform or not.
We also run the detection and response aspects of FireTail on FireTail, to find suspicious API usage and unauthorized activity. We follow industry best practices around vulnerability management, continuous pentesting, and other security practices.
At FireTail, we take customer data seriously.
Not only do we encrypt your data both in motion AND at rest, we also offer two separate locations to use FireTail, depending on your data sovereignty requirements- the US or the EU. We even offer dedicated customer deployments of FireTail for customers who prefer a private instance of FireTail!
Finally, we operate with an audited SOC2 Type 2 certification and handle all data in accordance with GDPR.
See how FireTail can work for you by scheduling a demo here or starting with our free tier, today.