SaaS supply chain attacks: lessons for managers
Incidents from early 2025 show that a company's security perimeter now runs through its SaaS providers. What this means in practice.
In early 2025, several major incidents served as a reminder that when attackers cannot breach a perimeter directly, they attack through suppliers. In the context of modern business, that means primarily SaaS providers: tools for work, communications, development, and data management.
This is not a new topic. SolarWinds in 2020 made this attack vector unmistakably clear. But incidents in the SaaS context have their own specifics worth understanding separately.
How SaaS dependency differs from conventional third-party software
When a company installed third-party software on its own server, it controlled the version, the timing of updates, and network access. With SaaS, all of that is under the provider's control.
This means:
- an update that introduces a vulnerability or compromises the system happens without the customer's knowledge;
- the customer cannot see what is happening inside the provider's infrastructure;
- authentication tokens and integrations run continuously, and compromising them opens access to the customer's data.
For most companies the SaaS stack is now wider than ever before. Marketing, sales, HR, finance, development - every department works with several specialised tools. Each one is a potential entry point.
What early 2025 incidents showed
The common pattern across several incidents of this period:
First - attacks through integrations. Attackers do not compromise the main SaaS tool but a small auxiliary service that has OAuth access to the main one. Through it they extract data or gain the ability to act on behalf of users.
Second - attacks through CI/CD and development tools. Compromising tools used by the development team allows injecting changes into the product's code. This is the classic supply chain attack, moved into a cloud environment.
Third - compromise of credential stores. Tools for storing configurations and secrets are a special target because through them access to the entire rest of the infrastructure can be obtained.
What this means for a manager
Most managers cannot and should not dive into the technical details of every incident. But a few management questions have become relevant regardless of company size.
First question: do we have a current list of SaaS tools with a record of which data and systems they have access to? Most companies I ask this question do not have such a list. Without it, risk management is impossible.
Second question: is there a process for reviewing new SaaS tools before they get access to corporate data? Or does a new tool appear whenever an employee simply registers for it?
Third question: can we quickly revoke a tool's access if its provider reports an incident? This requires centralised management of OAuth access grants, which many companies do not have.
A practical minimum
Full SaaS risk management is a mature practice that is built up gradually. But there is a minimum set of actions that makes sense to take in the near term:
- Run an inventory of SaaS tools with the business owner and the data they have access to.
- Review OAuth grants in the main corporate accounts and revoke access for unused or unknown applications.
- Establish a procedure: any new SaaS tool with access to corporate data goes through a minimum security review.
- Make sure that critical SaaS providers have signed data processing terms that include incident notification.
This is not protection from all threats. But it is the basic visibility without which all other measures lose their meaning.