Navigating the Complexity of Today's Digital Supply Chain

Building a software product today requires a massive number of dependencies. Ten or 20 years ago, an organization’s IT portfolio of applications was all in-house in a data center; if you take inventory of a company’s apps and services today, they’re almost entirely in the cloud. In the old days, if you wanted to make sure your enterprise resource planning (ERP) was secure, you could simply walk over and check the log file to see who had access. But today’s software-as-a-service (SaaS)-powered world is much more opaque.

This is true even for smaller organizations — we employ roughly 200 people, but our teams use more than 100 SaaS products. When you add in variables such as developers integrating third-party code into their workflows, it quickly creates a software dependency nightmare.

Here we'll look at how to account for the SaaS products your organization uses, how to prioritize them, and how to help keep the entire digital supply chain secure by leveraging time series data.

First Things First: Self-Evaluation
According to a SaaS trends report from Blissfully, the average small business uses 102 different SaaS apps. Midmarket businesses average 137 apps, and enterprises average 288.

Taking inventory can be daunting, but it's a vital task that should be continuously run and appropriately staffed. The first step is checking with the accounts payable department to determine which SaaS subscriptions you're paying for each month. This will not account for any SaaS products you're using at the free tier, of course, but it's a start.

Once you know which SaaS products you're using, the next step is to determine if there are any subscriptions you can drop. It often doesn't make sense to pay for two services that offer similar functionality — and it never makes sense to pay for something that's not being used at all, such as a service bought for a one-off use case and never canceled.

Once your SaaS products are inventoried, you can prioritize the most vital services per department based on the importance or sensitivity of the information assets involved — think NetSuite or another ERP for financials, Salesforce for customer lists, and so on.

Monitoring With Time Series Data
A handful of more mature SaaS services — I'd say roughly 10% — offer functionality that helps you secure your systems. But that leaves about 90% that don't, meaning organizations are on their own when optimizing security.

One efficient way to monitor security is to model user behavior using time series data and watch it for anomalies over time. Depending on the individual SaaS product or service, there could be five or more metrics to collect for creating a mathematical model that describes "normal" user behavior.

For example, for a developer platform, you could model commands such as "commit" or "clone" to get a sense of a typical level of activity. Over time, you will start to see how often these commands are used per day, week, and month on average, as well as where they originate from geographically. Let's say you have 80 engineers and almost all of them are based in the US and Western Europe, but you suddenly see a connection delivering commands from Ukraine. That would be an obvious red flag that something might be — and likely is — up.

Similarly, most organizations perform only a few clone operations each day or week; employing time series data to model activity over the course of a few months reveals your organization's typical use. If your graph suddenly spikes to 100 or more where you usually see three, you know you've got a problem.

Keep in mind that modeling behavior with time series data doesn't prevent fraudulent activity, it just helps teams respond quicker when anomalies do appear. Take the Codecov breach from earlier this year — a malicious actor tampered with Codecov's Bash Uploader script at the end of January, yet customers weren't notified about the incident until April. If their teams had been using time series data to model typical behavior, they would have noticed something fishy in a day or two at most, as opposed to the roughly two-and-a-half months it took for Codecov to take action.

The Bottom Line
In the end, even if you know what you need to monitor in each of the SaaS services you use, a common roadblock is obtaining the data necessary to do so. That's a key feature I advise our teams to look for in a SaaS solution — exposing logs programmatically through an API, allowing you to harness that data and leverage machine learning to create your models. Avoid services that hide this fundamental capability outside of a basic tier.

Teams need to have access to the log files for the SaaS services that house their most important data. In an industry where it's not a matter of if you get breached, but when, time series data modeling can make the difference between reacting quickly to minimize damage and letting something slip by to become a full-blown disaster.