Software supply chain security (SSCS) is a really curious subject. On the one hand, nearly everyone has an intuitive understanding of what SSCS means and how critical it can be for the success of a modern digital business. After all, we have seen the consequences of multiple large-scale incidents recently, which have all been labelled “supply chain attacks” by the press.
A bit of history
Perhaps the first widely known event of this kind was the notorious SolarWinds hack in 2020, when a malicious actor managed to inject malware into a popular IT management tool that was then deployed to thousands of clients and used as an attack vector in multiple security breaches. In late 2023, we had the breach at Okta, a leading identity provider, that affected many of their enterprise customers, including several security vendors (who were, luckily, the first to raise the alarm). Finally, just a couple of weeks ago the entire world observed the catastrophic consequences of the botched software update by CrowdStrike, that literally grounded entire airlines and forced multiple banks and hospitals to halt their operations.
On the other hand, there still seems to be no common agreement on what exactly defines an issue as a supply chain attack and consequently, who should be responsible for the damage. Consider, for example, the recent case of attempted compromise of XZ Utils, when an unknown but possibly state-sponsored threat actor tried to infiltrate the open-source project and introduce a backdoor into a ubiquitous Linux utility.
Luckily, this attempt was not successful, but we do know how massive the potential consequences of an implanted backdoor could be – you need to look no further than Crypto AG, a Swiss cryptography provider that has posed as a front for a CIA operation for nearly 50 years. Multiple other vulnerabilities in popular open-source projects have been recognized as supply chain attacks as well: Heartbleed, Log4Shell, regreSSHion, etc. To be honest, the entire package management systems for popular languages like JavaScript or Python are currently such a mess that they can be considered huge attack vectors as well.
As a result, there seem to be a widespread opinion among not just the public, but industry experts as well, that software supply chain security is a field of cybersecurity that is entirely focused on dealing with dangerous open-source libraries and is thus primarily a responsibility of software developers. While there is definitely a grain of truth in this sentiment, it quickly becomes completely irrelevant when we try to come up with practical recommendations for organizations affected by an ongoing incident or just looking for measures to prevent a future one from happening. Most of those organizations are not directly involved in software development and simply want to be more resilient against problems caused by their suppliers.
What is software supply chain security anyway?
Software supply chain security involves managing risks associated with software acquired from third-party sources. In today's interconnected world, every organization uses third-party software, including operating systems, commercial off-the-shelf software, custom applications produced by contractors or, in some cases, even programs developed in-house. Ensuring the integrity and security of all these software components is paramount yet challenging, especially considering the confusion about the responsibilities of the multiple parties involved.
Organizations face increasing regulatory pressures, including NIS2 and DORA, which mandate constant risk management and supply chain risk assessments. These regulations require organizations to understand their entire supply chain, including indirect dependencies. Typically, end users lack in-depth knowledge about software development. They seek compliance with regulations without delving into the technical intricacies and often this can lead to costly mistakes.
Perhaps the biggest misconception about SSCS is that it falls under the responsibility of an organization’s cybersecurity team. What the CrowdStrike incident has clearly demonstrated is that having too much security can indeed be bad. Companies that were following the security best practices – deploying agents on every machine, automated deployment of patches, etc.- were in the end affected the most, having to deal with much more damage.
This reminds me again about the decade-long debate between the IT and OT security experts and people ridiculing the latter for placing process continuity and personal safety above the quick response to security breaches. Well, how the tables have turned… If the CrowdStrike incident is supposed to teach us anything, it should be that security is never the goal, but just a means for achieving better business resilience against catastrophic events and finding the right balance between security and availability should be the guiding principle for everyone.
So, how about calling it “Software Supply Chain Risk Management” instead?
The pragmatic approach
As analysts, we strive to offer practical advice to every organization. However, such advice would be substantially different for various organizations and stakeholders within them. For example, businesses with strong internal software development activities, such as CrowdStrike itself, obviously need to invest a lot into securing their entire software development lifecycle. The market nowadays offers numerous solutions ranging from universal application security testing platforms to highly specialized solutions, like the ones for managing secure artifact delivery or producing the software bill of materials.
Ever more important is to understand that the traditional view of the software development lifecycle within a single organization simply no longer reflects the reality of our interconnected world. The life of a software product does not end at the moment it is delivered to a customer – in fact, it only just begins. And since it no longer remains in the hands of one party, the responsibility must be shared properly among several stakeholders. We have figured this model out for cloud services already – why not adopt something similar for every software product?
In a sense, Software Supply Chain as a strategy, just like Zero Trust, cannot be bought off-the-shelf. It requires a combination of careful planning, changing the business processes, improving communications with your suppliers and customers and, of course, a substantial change in regulations. We are already seeing the first laws introducing stronger punishment for organizations involved in critical infrastructure, with their management facing jail time for heavy violations. Well, perhaps the very definition of “critical” must be revised to include operating systems, public cloud infrastructures, and cybersecurity platforms, considering the potential global impact of these tools on our society.
But how can end-user organizations influence these processes if they are not involved in developing the software they are using? My colleague Mike Small has already published his recommendations right after the CrowdStrike incident. To his practical advice I can only add another bit of philosophical musing: security is impossible without trust, but too much trust is even more dangerous than too little security.
Start utilizing the Zero Trust approach for every relationship with a supplier. This can be understood in various ways: from not taking any marketing claim at its face value and always seeking a neutral 3rd party opinion to very strict and formal measures like requiring a high Evaluation Assurance Level of the Common Criteria (ISO 15408) for each IT service or product you deploy. If you are looking for more information and practical advice, why not join us at the upcoming cyberevolution 2024 conference in Frankfurt this December? Software Supply Chain Security, Cyber Resilience, and NIS2 and DORA regulatory compliance will be major topics presented by industry experts.
