In the last post we discussed the importance of knowing what components go into a software package. Knowing this helps with testing, maintenance, and security of that code, and will reduce the risk to your business of a software supply chain security problem.
In this post we are going to look at SBOMs—software bills of material—and how they can help by identifying software components.
What is an SBOM?
An SBOM is essentially a machine-readable list or catalogue of the details and relationships of components used in building software. SBOMs are now required by US Government procurement, and so are highly likely to spread across industries. While not yet required here in the UK, the National Cyber Security Centre is recommending the use of SBOMs, as do equivalent organisations around the world.
What is in an SBOM?
The US National Telecommunications and Information Administration (NTIA) has specified the minimum elements for an SBOM.
So that you, the consumer of an SBOM, can use them effectively, SBOMs are expected to include at least:
Supplier name
Component name and version
Any other unique identifier to help the SBOM consumer (you) find components in key databases
Dependency relationship (usually ‘includes’, for example, X includes component Y)
Author name (author of SBOM data, usually but not always the software supplier)
Timestamp (SBOM creation date and time)
How the SBOM was created (typically which tool; manual creation is possible, but time-consuming).
In addition:
The SBOM must be in one of three formats, so it can be machine readable
A new SBOM must be generated
with each new software version, so it is up to date
if the original version contained an error
or if the creators learn more information about the components
The SBOM should include all top-level components and all transitive dependencies; and the SBOM must also explain where dependency relationships probably exist but are not yet known.
Other useful information that could be included might be, for example, the licensing status.
What are the benefits of an SBOM – as a producer?
Using SBOMs as a producer means that the software company will be able to:
Improve development and testing by understanding the dependencies and identifying potential vulnerabilities in the product
Potentially reduce the number of libraries called, and therefore the extent of potential vulnerabilities
Demonstrate knowledge of the code content and quality, possibly earning preferential treatment as a supplier
What are the benefits of an SBOM – as a consumer?
Using SBOMs as a consumer means that you will be able to:
Know what you’ve got, and improve development and testing with a common understanding of software content and dependencies
Track vulnerable components and plan remediation to improve security
Understand your legal position regarding licensing and use of external code components.
What else do I need to know?
Whether consumer or producer of SBOMs, there are things you’ll need to bear in mind.
A new SBOM will be required whenever the codebase changes
An SBOM contains sensitive information, so storage and access should be controlled and secure
They may not capture all the dependencies so may not include enough information to capture all the vulnerabilities in the codebase
They are not yet always produced to the same standard: they may not always be compliant with the NTIA requirements, or they may have been produced in inconsistent ways (NTIA is the US National Telecoms and Information Administration agency)
They are not easy to manage for smaller businesses, and there is not yet an established ecosystem, though this is changing.
Any tips for how to manage the SBOMs?
SBOMs available in your business could quickly get out of control, as new ones should be issued along with every new version of software. Tips to control this proliferation of documentation include:
Creating a central repository
Automate the generation and management of SBOMs if possible; there are an increasing range of tools available to help with this
Consider the security of the SBOM (for both storage and transmission) because it contains sensitive information that could be used in an attack
As the consumer of SBOMs
ask for an SBOM for all incoming software and software components (including software-as-a-service applications), to maximise the value of the knowledge base you are creating in your repository
actively analyse the information provided as part of your risk management process, to assess and mitigate the risks in your software supply chain
As the creator of SBOMs:
choose one of the three standard formats, and be consistent about which one you use
schedule regular updates to make sure that they are accurate and up to date; you should revise the relevant SBOM every time you create an update to the software
add as much metadata as possible to your SBOM, to make it easier for the consumer of your SBOM
use the SBOM to reduce the redundancies in your codebase; create a standard list of components
use the SBOM to validate your compliance with any licensing requirements for the components you are using
Remember that an SBOM is primarily a catalogue of components; what you do with that catalogue will be the topic of our next blog post: how to make use of SBOMs.
If you’d like more information, or to discuss how CSP could help you with the security of your supply chain—or any other cyber security issues that are worrying you—contact us on 0113 5323763.
