Enhancing Security in the Software Supply Chain
Supply chain attacks have been thrust into the limelight recently. This often overlooked type of vulnerability will suddenly be forefront of many people’s minds. Whilst we don’t all face threats from nation state adversaries, supply chain vulnerabilities can affect all organisations.
A lot of people would assume that this is limited to hardware supply chains, however software also has complex, sometimes nested, supply chains, which can be next to impossible to fully document.
Challenges and Risks in Software Supply Chains
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.
Mitigating the Risks and Overcoming the Challenges
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.
How URM can Help
Software suppliers and the digital supply chain can pose significant risks to your organisation’s security, and, as such, effective cyber security risk management is an essential element of any engagement with a software supplier. Leveraging nearly 2 decades of experience providing risk management consultancy, URM can assist your organisation through each stage of its supply chain risk management plan. As you look to select and procure new suppliers, URM’s supplier information security risk management software, Abriska 27306, streamlines and automates the process of conducting supplier due diligence. Abriska reduces the administrative burden associated with managing a diverse range of suppliers and the possibility for human error, as well as improving the effectiveness and efficiency of your supplier security due diligence. Meanwhile, a CREST-accredited organisation, URM can also offer effective and trustworthy penetration testing services, where we will identify any vulnerabilities affecting your IT estate and ensure the third-party software your organisation relies on for its continued operation and success is secure.