Getty Images/iStockphoto
How to create an SBOM: Example and free template
SBOMs provide an inventory of every component in an organization's software supply chain. Use this free downloadable SBOM template to create one for your organization.
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 to keep track of the components used throughout their network so they can detect security vulnerabilities that might affect them.
To do this, organizations should use a software bill of materials (SBOM).
An SBOM is a living document created to inventory software components, including shared objects, libraries, statically linked libraries and middleware. It provides a comprehensive overview of every software dependency and license information in use. This enables an 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 that had SBOMs were able to quickly determine where the component was used and apply relevant mitigations.
Follow this step-by-step guide to create an SBOM for your organization. Review best practices to follow and SBOM formats to consider.
How to create an SBOM, step by step
The following steps explain how to build an SBOM. The SBOM template included in this article is a helpful starting point because it demonstrates how SBOMs enumerate the component parts of the software. Here are the steps:
Use this free downloadable
SBOM template to get
help creating an SBOM
for your organization.
- Select an SBOM tool. Creating an SBOM manually is time-consuming and cumbersome. Many tools are available to help with the task. Therefore, the first step is to choose a tool. Look for one that generates SBOMs both from using software source code and independently. Open source SBOM tools include Syft, Fossa, Tern and Retire.js.
- Select an SBOM format. SBOM formats include CycloneDX, System Package Data Exchange (SPDX) or Software Identification (SWID) tags.
- Generate the SBOM. Use the tool and selected format to create an SBOM that includes all internally developed components, open source and commercial external software, libraries, frameworks, firmware and other software components in use.
- Maintain the SBOM. SBOMs are living documents. As such, it is important to update them regularly, for example, when patching or updating software. This keeps the SBOM up to date with its components and known vulnerabilities.
What to include in an SBOM
SBOMs provide an exhaustive breakdown of every software component, listed by name and followed by any subdependencies. 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 that should be listed as sub-subdependencies. This can be further deconstructed as needed for organizations, but for the purposes of usability, the SBOM template and example do not list any further layers of dependencies.
The National Telecommunications and Information Administration lists the following as minimum elements for an SBOM:
- Component name.
- Supplier name.
- Component version.
- Additional unique identifiers, such as licensing information.
- Dependency relationship information.
- Author of the SBOM data.
- Timestamp of when SBOM was created.
Other elements to add to an SBOM include subdependencies, sub-subdependencies, cryptographic hashes of the components and any known vulnerabilities (CVEs).
SBOM best practices
Follow these best practices for creating and maintaining SBOMs:
- Promote open communication between DevOps and security teams. Siloed teams increase the chances of security gaps or discrepancies within SBOMs. Communication is key.
- Work with software vendors to create SBOMs. When adopting new software, ask the vendor for a complete breakdown of all the components used.
- Update SBOMs with every software release. To ensure they remain accurate and ready for review, update SBOMs after every software update.
- Automate SBOM updates. Automate the SBOM process to streamline generation and updates, increase efficiency and mitigate errors.
- Use the same SBOM format. Create all SBOMs using the same format to improve interoperability and make them easy to maintain and update.
- Scale SBOM generation. Ensure that the creation of current and future SBOMs is scalable, especially when it comes to managing version history and changes.
SBOM formats
As mentioned, SBOM formats include CycloneDX, SPDX and SWID tags:
- CycloneDX. This open source standard is supported by the OWASP Foundation and is designed to be a lightweight protocol that accepts multiple formats, such as JSON, XML and more.
- SPDX. Created by the Linux Foundation, this open source standard is useful for providing in-depth details, such as license information, and enables organizations to include code snippets and comments in the SBOM.
- SWID. While not a full-fledged SBOM standard, SWID is backed by NIST and can be used to comply with licensing agreements and to gain transparency into software components.
Learn more about these three SBOM formats.
Editor's note: Informa TechTarget editors revised this article in 2025 to improve the reader experience.
Rob Shapland is an ethical hacker specializing in cloud security, social engineering and delivering cybersecurity training to companies worldwide.
