Enhancing Security in the Software Supply Chain

With hardware, understanding how supply chain vulnerabilities occur is quite obvious. When components are sourced from different manufacturers, each of those suppliers represents an opportunity for a supply chain weakness to be exploited.

In software (including web applications), whilst less tangible, the exact same thing happens.  Much like hardware is assembled from off-the-shelf components, software is built using pre-made libraries, which save developers time and, in theory, provide them with well tested, trusted code.  These libraries, also called dependencies, can make up the majority of the code present a in solution, and the libraries in use can in turn have their own dependencies.  This leads to a complex structure of interconnected code sources from a wide variety of sources.

‍

The above XKCD comic does a good job of summarising this and highlights that often critical software depends on libraries created by hobbyist groups or individuals.  If a hardware component you sourced was manufactured by someone in their shed, how much would you trust it?  Large corporations place huge amounts of trust in open source libraries, often blindly.

Whilst that may sound like a slight on open source developers, open source libraries are the best case scenario. The code can be audited, and, by necessity, all of the dependencies must be listed.  Now imagine a closed source piece of software, where no source code is present.  As the customer, you have no idea how many libraries are in use, or where they have come from.  How can you trust the software to be free from supply chain weaknesses?

Of course, supply chain vulnerabilities in code don’t have to be malicious additions by attackers.  They can simply be exploitable bugs in the code.  What makes them pernicious is the difficulty of patching them when they form part of a larger application. For closed source or proprietary applications, you have to trust that your supplier is updating the libraries they’re using from all of their suppliers. Once this is apparent, it becomes easy to understand why vulnerabilities like heartbleed and log4j were such big news.  Simply patching your operating system can’t fix the vulnerability, and each and every vendor has to repackage their application having updated the vulnerable component.

So, with the problem being as it is, what can you do?  There are a number of things to consider:

• Carefully evaluate the need for third-party libraries/dependencies; the fewer present, the less to manage.
• Consider the trustworthiness of third parties; do you need to perform any internal validation of their security?
• Fully document all dependencies and their versions.  This will allow you to understand your attack surface and when a vulnerability affects you.
• Ask these questions of any commercial suppliers of software; you can perform third-party risk assessments to evaluate this.
• Once the software is deployed, perform regular security assessments to highlight any vulnerabilities present or missing security patches.  It is common for vulnerabilities to be identified in commercial software through their dependencies, with our direct customers having to liaise with their supplier in order to have the vulnerability addressed.  Without this testing, the vulnerability would have remained!

Hopefully this article has given you some insight into the software supply chain and how care needs to be taken when building or acquiring solutions to help minimise the risk of a supply chain vulnerability.