Getty Images/iStockphoto
How to create an SBOM, with example and template
SBOMs help organizations inventory every component in their software. This free template, which includes an SBOM example, can help you secure your own software supply chain.
Modern software development involves using a large number of components, often with a mixture of custom-written code, open source libraries, firmware and commercial software. Organizations need help keeping track of the different components used throughout the organization so they can more easily find security vulnerabilities that may affect them.
To help organizations secure their software supply chain, they can utilize something called a software bill of materials (SBOM).
What is an SBOM?
An SBOM is a document created to inventory all these components. It provides a comprehensive overview of every software dependency and license information used. This enables the organization to quickly determine if it uses any software affected by vulnerabilities in a particular component without needing to investigate every piece of software manually.
For example, when the infamous Log4j vulnerability was discovered, most organizations scrambled to find where they used the component. Organizations relying on SBOMs were able to quickly determine where the component was used and apply relevant mitigations.
Each application an organization utilizes could have numerous dependencies: shared objects and libraries, statically linked libraries, supporting middleware, JavaScript libraries and more.
SBOM template
Use this downloadable SBOM template to get started with creating your own software bill of materials.
How to create an SBOM
Here is an example of an SBOM template to show what information should be included and how to lay out your first SBOM. The template is helpful as a starting point, as it demonstrates how SBOMs are used to enumerate the component parts of the software. These components create an easy method to track where specific components are used by the organization and any software vulnerabilities that may affect them. The SBOM should include all internally developed components, open source and commercial external software, libraries, frameworks, firmware and other software components used to build this software.
The document includes a table that shows the component name and any subdependencies, with an example in the first column. This is a hierarchical relationship where the component in question is itself reliant on other software, which also can be reliant on additional software components, which have been included in the table as sub-subdependencies. This can be further deconstructed as needed for organizations, but for the purposes of usability, the example does not list any further layers of dependencies.
SBOM formats
For most organizations, manually creating SBOMs is too time-consuming and can lead to errors. Organizations can store SBOMs in common formats such as SPDX (Software Package Data Exchange) and OWASP CycloneDX, as well as with SWID (software identification) tags, for a more automated approach.
Using these formats is advantageous because the SBOM can be automatically created during the development process. Tools that scan software and automatically create the SBOM in one or more of these formats can be run. This tends to be useful for organizations that create a significant volume of software.
