Introduction
In recognition of our commitment to help make the UK a safe place to do business, we are going to release a regular ‘CSP Academy’ piece.
In this first series we are going to discuss Software Bills of Material (or SBOMs) in three posts over the next few weeks, explaining their function, benefits, and the risks they address. Today’s post explains the software supply chain security problem.
Dependencies in the software supply chain
As part of securing your supply chain, it’s important to think about the software that you use. It may not be as obvious a part of your supply chain as any physical components that you need to deliver your products or services, but it still adds risk.
One risk is that vulnerabilities or malware are present in (or introduced into) the code that you depend on. They might have been present from the outset, but unknown; they might have been there, known about but not yet fixed; they might have been introduced as the result of a change.
- Vulnerabilities are flaws in the software that leave a security hole. Attackers may be able to exploit this security weakness to gain access to your system.
- Malware is intentionally introduced and aims (among other things) to encrypt or steal your data, get control of your system, or make it unavailable.
For example, you may have heard about the Log4j problem; a significant computer vulnerability was found in a component of Log4j, called Log4shell. Log4j is open-source (meaning free to use) code used by millions of computers worldwide—and the vulnerability meant that until they were updated, all these computers were open to attack.
Another risk is that the creator of the code component may stop updating it. As that code ages, new security issues may arise, adding vulnerabilities.
As a sidenote: another kind of risk is that of licensing. If you are using open-source software components (and almost all organisations are) there may be a requirement that any resulting software is also open source. Knowing the components that you are using—even if used indirectly—will help you understand whether this is an issue. This will depend on any requirements that the creator put on the code; you should consult a legal expert.
Software supply chain security is intended to ensure that software is not compromised at any stage during development. In this short series, we are going to focus on:
- A description of some of the security issues in the software supply chain
- How a software bill of materials (an SBOM) helps you identify what is in a software package
- How a VDR (vulnerability disclosure report) or a VEX (which stands for vulnerability exploitability exchange) can help you identify if there are vulnerabilities in that code that might cause a problem for your business.
Wait: first an explanation of what we mean by vulnerability
Designing and coding software is hard. It’s easy to unintentionally introduce flaws in the way that the software is designed, or defects in the way that it is coded. Additional security problems can be created by poor management of information that should be kept secret, or by weak access controls during development.
Whatever the cause, a vulnerability is a flaw in the software that could allow an attacker to gain access to the system to steal data, install malware, or move from that system into the wider network, and cause further problems elsewhere.
Developers can use best practices during development and testing to reduce the risk of such issues, but application code can be very complex and involve many, many lines of code. Windows 11, for example, is estimated to run on 60-100 million lines of code and Facebook is said to run on 62 million. While ‘lines of code’ isn’t a good way of counting, it does give you an idea of the scale of effort involved in creating software.
Vulnerabilities, then, are inevitable—and, as a sidenote, this is why we recommend keeping all your software up to date, as those updates are likely to contain ‘patches’ to mend some of those defects.
The problem: unexpected dependencies mean additional risk
Let’s start with an example.
Suppose you set out to make a meal from a new recipe book, only to discover that each recipe refers to another one. The more you read, the more complicated it becomes—and the more important it is to get a complete understanding of the components, especially if you are catering for an allergy. See the image below: if someone is allergic to nutritional yeast, not knowing that it is a component of the spice blend and therefore also of the broth but not mentioned in the soup recipe could cause a problem.
The same is true of software packages.
Software is rarely written completely from scratch. A software package typically includes multiple pre-written pieces of code which are called on to do specific tasks when needed. These might be written by your own developers but are more likely to be from open-source libraries: code freely available for anyone to use.
This is, overall, a good thing: it reduces rework and speeds up delivery by avoiding reinventing the wheel. Developers typically include libraries of pre-written code ‘chunks’ for easy reuse.
However, the network of components can get very complex very quickly, and the cyber security risks expand as the complexity grows.
See the image above: some components of the resulting code package (C) are internal, and some are external. Some components are called multiple times in different places. Changing one element can have unexpected effects if not properly documented and can affect all software that calls that component.
Dependencies matter: it is important to know what a package contains, so that you can test it, maintain it, and secure it.
Any changes to code anywhere (A – external, in diagram, or B – internal) could influence the final code package, C. And that’s OK—if you know what changes have been made, what the impact on C will be, and are able to mitigate any issues that the changes might cause.
What can you do?
If you have your own team of developers, you can put controls in place, such as:
- using only a predefined set of libraries
- recording what components are being used
- verifying the source code on download
- ensuring that code is tested
- ensuring that unnecessary components in those libraries are minimised
- ensuring that code is kept up to date (this is known as patching)
- keeping up to date with news about any security issues or updates for these components.
If you do not have an in-house team of developers, you are relying on someone else to implement security measures in the development of their software.
The key to the issues outlined in this post is understanding what code components are being used in any given software package. In our next post, we’ll discuss SBOMs (software bill of materials), which are intended to provide information about the components in a software package.
