The software supply chain increasingly relies on open source software (OSS) for both underlying components to deliver the software infrastructure and to provide operational software. According to OpenUK’s State of Open Report, there is almost universal adoption of OSS across all types of organisations. However whilst OSS provides easy access to innovations and the latest technologies, it does come with some risk because a lot of software is hidden from use.
This was highlighted with the Log4Shell vulnerability at the end of 2021 in which a critical vulnerability was identified in the widely used Java logging component tool Log4j. The vulnerability affected businesses, governments, and individuals worldwide and given the severity of the vulnerability, everyone was keen to remove their exposure to the vulnerability. However, determining if you were vulnerable or not wasn’t easy. How could you easily determine if you were vulnerable?
What is a Software Bill of Materials?
One answer would have been to use a Software Bill of Materials (SBOM), a formal set of machine-readable metadata that uniquely identifies a software package and its dependent components; usefully it also includes version and supplier information as well as other relevant information including copyright and licence data. A good analogy is to think of a SBOM as the list of ingredients in your product. The SBOM should identify all of the components included which your software is dependent on; these components could be 3rd party components e.g. library modules or an application framework. SBOMs are typically created as part of your development CI/CD pipeline as it should accurately capture the ‘as built’ state of the software.
Formats for a Software Bill of Materials
There are a number of standard formats for SBOMs, the two primary ones being SPDX promoted by the Linux Foundation and CycloneDX which originated from OWASP. The SPDX format has been around for more than a decade and is now an ISO Standard. It is about to have a major version upgrade, hopefully by the end of 2022, which will add additional support for identifying vulnerable components within a SBOM. Various machine-readable formats of SBOMs are supported including JSON and XML. Although there are two standards, there is good interoperability between the two, so that SBOMs provided in one standard can be readily transformed into a format of the other one.
SBOMs are designed to be shared across organisations (hence the importance of having a formal definition) and are particularly helpful at providing transparency to the software supply chain. They also provide a readily accessible form of data to be used to identify vulnerable software components and SBOMs should now be seen as forming a cornerstone of a cybersecurity strategy which is performing active vulnerability management.
Is a Software Bill of Materials a revolution?
The SBOM concept isn’t particularly new having been around for more than a decade where it was originally designed to capture the different (open source) licences of components so that it could be determined if the components were being used in accordance with the licences. However, the importance of SBOMs has been raised recently, driven particularly by the publication in May 2021 of the US President’s Executive Order on improving cybersecurity, where SBOMs were identified as a key enabler to providing greater transparency to the construction of delivered software. This in turn led to a number of key reports:
- January 2022 saw the publication by the Linux Foundation of a set of research on the awareness and readiness of organisations to use SBOMs. The report confirmed that SBOMs enabled a better understanding of software dependencies and were now a key component of the software supply chain.
- May 2022 saw the Open Source Security Foundation publish ten recommendations about improved cyber security practices to be adopted particularly in open source software. One was simply titled ‘SBOMS everywhere’ with the aim of improving SBOM tooling and training to drive wider adoption.
So, having established that SBOMs might be a useful artefact to have, what can you do with them and how can they form part of your security risk management? Clearly, appropriate tooling will be required in order to support the following use cases.
Use cases for a Software Bill of Materials
SBOMs should form part of your vulnerability management process by using them to scan for vulnerabilities when acquiring software from the supply chain and also understanding your vulnerability posture when releasing software to your users. As vulnerabilities are being discovered continuously, vulnerability scanning of released software should be proactively performed so that your users can be informed of any new vulnerabilities as they are discovered.
