Matt Middleton-Leal, Managing Director EMEA at Qualys, discusses the importance of software supply chain security.
Every day, you will see headlines around IT security issues affecting companies and public sector bodies. These organisations will be affected by attacks that could involve everything from data theft or sensitive information being leaked through to full blown ransomware deployments and interruptions to service. One of the biggest routes for these attacks over the past few years has been the software supply chain – if an attacker can jeopardise one software component, then they can attack multiple companies through that hole.
Applications are now more complex too. They have more moving parts, from open source software projects and internally developed software code through to third party applications that are embedded into services. They can expand and scale up to meet demands, created on-demand using infrastructure as Code or in Kubernetes containers. And they can be created using public software hosted on services like GitHub or the Python Package Index.
As a result, many security teams are not able to track those software assets effectively. To solve this, we have to make it easier to manage those software components and prevent potential attacks from coming in.
Bills of materials and software management
In practice, security teams need insight into what IT assets the organisation has. Without this list, it is impossible for IT security leaders to call their organisations secure. This has to be expanded to software as well.
The first step for this is to create a full inventory of the software that you have in place and the components used to make it. For internal applications – otherwise termed first-party software – this level of insight is often lacking. Studies have shown that between 70 to 90% of first-party software includes open-source components; according to our analysis of more than 13 trillion anonymised data points in the 2023 TruRisk Research Report, 79% of servers installed use open-source components.
Application and security operations teams most commonly rely on manual checks or siloed scripts to evaluate the security of first-party software. This depends on how well those checks work and how often they are carried out, and delays teams from prioritising the right risks for remediation.
Setting up a full process for software supply chain management starts with knowing what applications components you have and what versions those components are. Traditional vulnerability assessment or software composition analysis tools do not detect the presence of embedded open-source packages across the production environment. So, expanding your approach to cover these first-party software applications should be a natural first step.
Alongside looking internally, you should also look at the software that you consume from others. This third-party software will itself be built of different components and services, and any one of those can have an issue. As you don’t ‘own’ the software, it may be difficult to peer inside and know if there are any out-of-date components that could affect your security.
To fix this problem, the US Government supported the use of software bill of materials, or SBOMs. SBOMs provide customers with a list of all the components used within a given application, so security teams can spot any faults that come up. However, uptake of SBOMs is still in its infancy.
Regulation may help on this in time. SBOMs were mandated by the US Government in an Executive Order in May 2021, while the European Union’s Cyber Resilience Act also includes resolutions to implement SBOMs for hardware and software manufacturers that provide products to European consumers. The UK Government is also developing its approach to cyber resilience, and SBOMs are expected to be part of that approach.
The challenge here is that SBOMs are still relatively new, and CISOs have other more pressing issues around security that take up their teams’ resources and commitment. Regulation may force this up the agenda in time, but software supply chain attacks are happening now. SBOMs can deliver more insight into what cyber risks exist and consequently where to concentrate. As part of an overall software supply chain strategy, SBOMs will be essential in future, but the data they provide will help you manage risk around misconfigurations or vulnerabilities now too.
Improving overall processes around security
Just like any security process, software supply chain security depends on the data coming in and how quickly that information can be turned into actions. The issue is that software today is so complex that you can easily miss potential problems, whether they are in your organisation’s own software or contained in another company’s products.
Getting more data on what is in place is necessary in order to begin improving security. However, this data is not useful without the right context. Without that insight, you will not be able to prioritise where changes are needed in your own applications, and you will not be able to put pressure on your suppliers around their updates. Equally, you will not be able to manage those potential risks effectively and mitigate problems before they come up.
To improve your approach to software supply chain management, you will have to look at your overall approach to risk and how you manage software within your organisation. Bringing first-party software and third-party application risk data together will help your team understand the potential threats that exist, where changes are needed, and how you can support those problems getting fixed in an efficient and timely manner.
To make this work for you, look at how you can automate the data gathering so you have a continuous level of insight into what you have in place, and then prioritise your risks so you can always get ahead of any potential problems before they become serious or lead to attempted attacks.
