SBOMs and the importance of inventory

Software producers need to understand what components their products are built from, and which of those are known to be vulnerable. SBOMs are a mechanism for recording this component inventory, which can be used with other tools to identify software in the supply chain with known vulnerabilities.

SBOMs are a standardised way of listing the component parts and software dependencies involved in the development and delivery of an application. This doesn’t make SBOMs a cyber security tool per se; although the inability to produce an SBOM is a red flag. However, SBOMs can be paired with tools such as vulnerability scanners to identify vulnerabilities that may be present in the software being analysed. This visibility allows developers and vendors be aware of what could affect their software, and take any actions necessary to mitigate risks.

SBOMs should be cryptographically signed, ideally at the same time and using the same certificate used to sign the associated software. A signed SBOM gives you the confidence that the SBOM has not been modified and belongs to the software it is attached to. Unsigned SBOMs cannot do this and offer no level of trust or verification, like how unsigned software could have been modified without being known. 

Once there is a process for generating SBOMs for software, a new SBOM should be generated every time the software is built. Therefore having a dynamic SBOM, where a new up-to-date version is produced with every new version update of the software is preferred, as inaccuracies in SBOMs greatly decrease their effectiveness. In this sense, an inaccurate SBOM offers false assurance, which in turn leads to a higher chance of being at risk.

If a third party generates an SBOM for software, one would have to trust that third party to create it (and maintain it). SBOMs are next to useless if they cannot be trusted, which means they should be created by developers of the software. Likewise, vendors should know what they are selling/distributing.

Whilst there is a lot of talk about the uses of SBOMs and whether they help, it is important to consider how and when SBOMs are generated. Ideally, an SBOM would start being generated during the development phase of the software life cycle using automation, and this should be encouraged if SBOMs are required. The earlier in the development cycle this occurs, the easier it can be to generate an accurate and complete SBOM. 

Since the US Executive Order in 2021, there has been a growing number of tools which allow the creation of SBOMs. For developers, perhaps an important development is tools which have been developed which can generate SBOMs at time of building software, which means they can be as up-to-date as the software they are packaged with.

Organisations most likely to benefit from SBOMs as a tool to increase their understanding of risk across their supply chain would need an existing level of technical expertise within an established, mature approach to cyber security. The existence of an SBOM alone does not improve cyber security in itself; it would have to be combined with other tools and techniques (such as vulnerability scanners) in order to improve an organisation's security. 

Users of software may gain more confidence in a product if the vendor has produced an SBOM. That confidence may come from the idea that by the vendors or developer have considered the components of their product. For end users of software, the utility of the SBOM will be depend upon their own understanding of the cyber risk, and their technical expertise. As far as reassuring the end user is concerned, the time and effort taken by an organisation to create and maintain SBOMs would likely be better spent on other cyber security practices. 

As previously mentioned, SBOMs do not provide standalone security; they are a tool which can increase transparency. As a source of information about software, SBOMs must be stored securely themselves as they could be useful for an attacker. Protecting the SBOM itself is therefore another security overhead organisations must consider.  

An incomplete or inaccurate SBOM makes it harder to understand the true risk associated with the software. An SBOM that cannot be trusted can be effectively useless, which would raise the risk of using the associated software.  

SBOMs can have limitations when it comes to custom and proprietary libraries. When combining a vulnerability scanner with an SBOM for proprietary software, vulnerabilities in the proprietary software will not be found, nor do they help to identify zero-days. SBOMs paired with vulnerability scanners will only show results for known vulnerabilities.

A company with legacy systems may be seeking to use SBOMs but may have large complex systems with legacy software where SBOMs need to be generated. It may be difficult to generate an SBOM for legacy software, especially if the code is no longer supported. Maintaining many SBOMs for complex systems may also become resource intensive, especially when creating them retroactively. 

To reiterate, an SBOM does not guarantee that your software supply chain is secure. It is simply a tool which, if used correctly, can help create the transparent inventory needed to help secure the supply chain. An SBOM should be viewed as simply one option within your secure development practices, and as such it is not the answer to addressing all of your supply chain risks.  

Harrison L
Research Lead for Software Supply Chain Security