When and How to Create a Software Bills of Materials (SBOM)
Published April 26, 2024.
A Software Bill of Materials (SBOM) inventories all of the open source components and other third-party libraries within a codebase. Much like IKEA instructions explain which parts are included in the package for your new furniture, an SBOM describes all of the third party components in your codebase.
Most SBOMs contain the following information about the make-up of an application:
Package name: see a full list of every package in your codebase.
Version: understand the version of each package, so that you can quickly spot outdated versions that may contain security vulnerabilities.
Location: shows the code repository where each package resides.
Open source license: some open source licenses can present legal troubles if you’re selling a commercial application. Quickly spot GPL and other copyleft licenses that require users to open source the entire application if the component is used.
Security vulnerabilities: a key use case for SBOM is understanding the security risks of third party components. With a full inventory of every component and the known vulnerabilities within them, engineering and security teams can quickly understand the security of their software supply chain.
It usually takes the form of a long list, which can be filtered to find specific information like whether the codebase relies on dependencies that are licensed under GPL or contains critical vulnerabilities. This makes it easy for software engineering teams to keep track of any problematic open source components in their codebase.
>> Learn how to generate an SBOM with open source tools Syft and Grype
Why and when are SBOMs needed? Key use cases
Generating an SBOM can provide several benefits, including:
- Ensuring software transparency and accountability: with a full list of third party software components, software engineering teams can easily share
Quickly respond to newly disclosed vulnerabilities: SBOMs can immediately provide information needed to understand
Meet compliance requirements: many security standards require a complete list of software components and their known vulnerabilities to demonstrate a secure software supply chain.
Let’s dive into these points in more detail.
Meet the security demands of customers and quickly respond to new vulnerabilities
The source of many cyber security attacks stem from vulnerabilities in open source components, which has placed a spotlight on software supply chain security. An SBOM enables companies to be transparent about the open source libraries they use, which provides peace-of-mind and fulfill compliance checkboxes.
Before purchasing a digital product, many companies will require the vendor to produce an SBOM to verify whether it relies on components that have known vulnerabilities documented as CVEs. This is a common practice to reduce third-party risk – a cyber security category that focuses on the security risks of allowing sensitive data to be handled by vendors.
Beyond just meeting the demands of customers, SBOMs can also provide peace-of-mind or urgent action items when new vulnerabilities are disclosed. For example, when Log4j was discovered, those who had an SBOM could quickly search their codebase for components that were affected – leading to a sigh of relief or a high priority remediation exercise.
Meet compliance requirements
Another common reason to generate SBOMs is to gain compliance with a security framework that enables companies to sell into new markets. For example, the Cyber Resilience Act requires companies selling digital products in the EU to generate a continuously updated SBOM.
Similarly, according to a Whitehouse statement in 2021, companies doing business with the US government will need to produce an SBOM to meet their standards. As new security standards are rolled out, you’ll likely find a requirement to document all third party components in your codebase.
How to generate an SBOM with common tools
Start by choosing a tool like Syft, which can scan filesystems and containers to show users which third party components are used in the codebase.
After installing the tool, you can run commands to point the scanner at a specific file:
This will generate an SBOM within the terminal.
Common data formats
One common data format for SBOMs is CycloneDX, which is open source and maintained by the OWASP community to standardize the ways this data can be generated, exchanged, and analyzed.
It is supported by many software supply chain security tools including ZAP, Trivy, and GitHub, which makes it easier to share information across toolsets. You can specify these tools to generate an SBOM in this format as you run your commands:
Another common data format is SPDX (Software Package Data Exchange), which is also machine-readable and open source, and is maintained by the Linux foundation. SPDX is also supported by Syft.
Augment your data to extract more insights about your third party components
There are many ways to augment and manipulate the data to provide different kinds of information – let’s use Syft as an example:
Integrate Syft with Grype to enrich your SBOM with vulnerabilities associated with each third-party component. This can help you quickly understand if you’re impacted by the next Log4j vulnerability.
Extract the open source license for each component. Open source components licensed under copyleft licenses like GPL require that the entire application is open sourced if it uses that component. You can also add a filter to only return components that use a GPL license.
Extract the package name, version, and location of each third-party component. This provides greater visibility into which components need to be updated, and where you can find them within your codebase to make the change.
Automate SBOM generation with Jit
Jit is a DevSecOps platform that unifies SBOM alongside other security controls like SAST, SCA, secrets detection, CSPM, IaC scanning, and more.
To generate an SBOM with Jit, follow these steps:
Create a free Jit account and install Jit on the Github marketplace
Login to the Jit platform and select which repos you’d like to scan
Go to Security Plans > Max Security Plan and click “activate” next to the SBOM security control
This will automatically generate an SBOM for all the repos you selected, which includes the package name, version number, associated open source license, and the repo where it resides.
Simply click on the repo, which will take you straight to Github to see the component.
You can also filter for specific licenses like GPL to highlight any packages that might present legal troubles.
To view open source security vulnerabilities, follow the same steps as above and hit “activate” next to the Software Composition Analysis security control. This will automatically scan your repos for open source components and their vulnerabilities, while also providing continuous scanning for each PR as it is created.
Looking to get started? Start free or request a demo.
