Security exploits are an ever-changing domain. We constantly witness new attacks, old tricks in new modalities, and evolving approaches to breaching data. Over the past decade, the software supply chain has been a burgeoning area for API security vulnerabilities. APIs are at the core of much software development these days, and as such, understanding exactly how these APIs form the complex and vulnerable supply chain concern that they do is vital.

Below, we’re going to look at the software supply chain and how it can create extreme vulnerabilities for API developers. We’ll examine two recent examples and provide some best practices to address the long-term vulnerabilities and concerns.

Physical Supply Chain Vulnerabilities

Before we look at the software supply chain, let’s consider what a supply chain even is. The best way to do this is to look at a physical example.

Imagine for a moment that you are a healthcare provider. You need to collect patient information and process insurance documentation, sure — but what about all the other elements that require a strong supply chain? What happens to your patients if your tools aren’t properly sanitized? What if there’s a production issue with gauze or with the equipment used to maintain ambulances? This is where the supply chain comes into action — the supply chain is designed to deploy products that facilitate all of these small little (yet critical) functions.

Now imagine these same issues, but this time, assume malice — what if your tools are not only not sanitized properly but are instead purposefully damaged or dirtied? What if your patient records are stolen? What if the medication dosage is filled incorrectly on purpose? The bad actors that can affect such a supply chain could dramatically cause high levels of damage, which could affect multiple providers in that same chain at an incredible level.

The Analogous Software Supply Chain

Now consider this exact scenario, but instead of scalpels and gauze, consider an online health vendor. This vendor utilizes a variety of solutions to deliver care, document patient outcomes, measure treatment effectiveness, and more. These functions rely on other solutions and systems to deliver the full outcome. In the world of software development, supply chain providers are a dime a dozen — they provide everything from transit to verification to frontend GUIs.

The threat of some bad actor breaking into this system and utilizing the supply chain to cause damage, expose data, or fundamentally assault critical systems is real. In many cases, a single vulnerability can significantly damage an industry. Let’s look at some examples where software supply chain vulnerabilities have dealt significant damage in recent years.

Recent Attack Examples

The threat of software supply chain attacks is not just theoretical — two significant examples of this vulnerability have occurred in recent years.

Firstly, let’s look at SolarWinds. SolarWinds was an attack that targeted IT infrastructure in 2020. The attack occurred when bad actors injected a piece of malware into Orion, an IT resource management system in the SolarWinds family of products. This attack allowed hackers to add malware to a regular update signed by what should have been a certificate of authenticity and trustworthiness, propagating the attack to a multitude of clients.

Once all was said and done, 18,000 of 33,000 customers were vulnerable, with clients like Microsoft, NATO, and VMware having notable vulnerabilities. It should also be noted that the initial attack began in March and June of 2020, but the attack was not discovered until December of 2020.

Another prominent example was the British Airways attack of 2018. In this attack, bad actors targeted the processing and service systems of British Airways, injecting code into the system that routed credit card payment information. This information was then sent to an external site located at a URL designed to mimic the official naming conventions of British Airways, causing customers to believe payment processing was taking place at that URL. This harvested data, including payment and processing information, from many users.

Why Software Supply Chains are Especially Vulnerable

Part of the danger of supply chain attacks is that they can be challenging to detect because they are abstracted away from their core targets. A threat actor may be targeting a specific entity or organization, but instead of attacking that entity directly, they choose to attack the supply chain itself. In doing so, the actual targets aren’t made aware of an attack. However, they are still made more vulnerable than they were before.

It should also be noted that this abstraction is not just in terms of targeting but also timing. A vulnerability in the supply chain may remain undiscovered for months or years until a victim is directly interacted with.

Another dangerous element is that these attacks are typically very complex. Firstly, organizations tend to look for threats externally as opposed to internally. There is a belief that internal systems are more secure than external ones. Since supply chain attacks are very much internal, many organizations may not even be aware of these vulnerabilities and the complex underlying mechanisms that promote them — in other words, they remain unaware of the intensity, scope, and reality of the danger until the attack actually occurs. When it does occur, it’s not obvious where the attack actually came from until the damage is done.

These types of attacks can also be multi-vector in that not just a single element of the supply chain is attacked. In such cases, multiple small attacks can add up over multiple vendors and providers, combining in odd and unpredictable ways, doubling down on the complexity. This also means the attacks can take wildly different formats that obscure the threat modality and nature.

Additionally, the reality is that tooling that could resolve much of this complexity is often designed to find weakness in code, open vulnerabilities, or heuristic behaviors. In other words, they’re typically meant for internal functions and systems, not for external ones. Typically, downstream components won’t usually have access to source code or artifacts, making testing and verification difficult if not impossible. This makes any ability to audit the code limited, and therefore it’s harder to detect issues along the software supply chain.

Mitigating Software Supply Chain Concerns

So how do we address these issues? Firstly, adopt a zero trust model — no system should ever be allowed access to any internal systems, functions, or data sets without authentication, authorization, and continual validation. Zero trust is a core solution here because there’s no way to know if the supply chain is trustworthy. This model should be a part of a larger approach toward the supply chain based on suspicion and verification.

Track everything, apply heuristics, limit requests, and treat everything that’s not internal to the codebase and created by your team as suspect. By tracking everything and ensuring that things are doing what they should be doing, you ensure that if something were to happen in the supply chain, you would be aware of it early on.

Organizations should make an effort to understand the supply chain at a deep level. Doing an end-to-end supply chain audit to understand where data flows in and out of the system is a great first step. Additionally, developers should investigate third-party solutions and look for audits, tests, and other surveys to ensure the software provider’s integrity. Best practices in the local organization mean nothing if dependency organizations do not adopt their own best practices, so ensuring adequacy is vital. Simply put, developers must get a greater view of the supply chain and trust nothing.

Developers should also invest in understanding the possible attack vectors. Understanding where the potential attack vectors are, both internally and externally, is a vital step to ensuring a secure environment. This is generally a good piece of advice regardless of whether or not the supply chain is being dealt with, but this is even more important when it comes to supply chain security. Once you understand where the attacks could come from, you can begin to create systems to combat those weaknesses and secure potential vectors before they’re ever realized. There will be some vectors you can’t secure, and in those cases, you should ensure mitigation and awareness so you can find issues before they get larger.

Finally, there are architectural and managerial solutions that can be applied. For example, providers handling vital data such as PII or medical information might try to avoid third-party dependencies. Such organizations might consider building internally rather than adopting third-party solutions, as off-the-shelf implementations often carry a higher threat of supply chain attack.

Providers should be security minded, adopting a security posture that is questioning and verification-based. Create an incident response plan and be aware of what happens if an attack occurs. Connect with third-party vendors to evaluate their security, and make an effort to understand what happens when things go wrong. Train often, secure internal systems, and treat every element in the supply chain as if it is an attack vector of utmost importance — because it very well might be.

Conclusion

Software supply chain attacks can cause much damage, but they can also be mitigated with common sense approaches. While the approaches do carry their own cost — especially when building first-party rather than third-party solutions — the cost incurred is far less than the cost spent mitigating data breaches, answering legal requests, or otherwise dealing with breached data, loss of trust, and decreased perception of value.

What do you think about our approach to securing the software supply chain? Let us know in the comments below!