Manage risk with a Software Bill of Materials

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.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

SBOMs can also be used as part of an integrity checking process for components received from the supply chain as the metadata associated with each component typically includes checksums which are used primarily to protect against accidental corruption.

These checksums can be used to validate that the components ‘as received’ are ‘as produced’ by the supplier. Cryptographically strong checksum algorithms may be used to detect deliberate corruption or to confirm the desired version of a component, if multiple versions are available.

The continued use of obsolete or no longer supported software is a key risk to any solution, as this increases the potential that vulnerabilities could be exploited. By monitoring the supported versions of components against an SBOM, identification of software which may need additional measures in order to limit the likelihood of compromise can be performed.

And finally using SBOMs to ensure that the components are being used in accordance with their licence is still a very important use case to consider as part of the overall risk management associated with the supply chain.

Conclusion

So, next time you acquire some software, ask for a SBOM to be also provided; some industries are already starting to expect this. It will demonstrate that you are taking your security risk exposure seriously, but you will also be far better placed to respond when the next Log4Shell type incident happens.