What is a software bill of materials?
A software bill of materials (SBOM) lists all packages and libraries included in an application. It's essentially the digital equivalent of a manufacturing bill of materials. And just like a traditional BOM includes all sub-assemblies, an SBOM includes transitive dependencies – or your components' dependencies. SBOMs make it easy to see if there are any risky packages in an application.
A software bill of materials is the first step toward taking control of your dependencies and managing risk from open source components. In recent years, the number of cyberattacks targeting open source components has skyrocketed. SBOMs give you insight into your dependencies and can be used to look for vulnerabilities, license issues, and other risky components.
Why do I need an SBOM?
Some vendors require an SBOM when purchasing software to manage their security. While they are not universally required at the moment, the US National Telecommunications and Information Administration has laid the groundwork for requiring a software bill of materials from vendors in the future.
What are the minimum requirements for an SBOM?
Data fields
Every SBOM provides general information for component identification.
Information for software bill of materials includes:
-
The supplier name.
-
The component name.
-
The version.
-
The dependency relationship.
-
The author of the SBOM.
-
The time the data was added to the SBOM.
Automation support
An SBOM must include support for automatically generating and parsing, with the goal being interoperability across organizations. An SBOM from one organization should be easy to parse without adopting new tools.
Currently accepted formats that meet the requirements for automation support include:
-
SPDX
-
CycloneDX
-
Software identification tags
Are all SBOM formats the same?
Over time, various software groups have created a few different formats for a software bill of materials. Each software bill of materials format has its advantages
The two most common SBOM formats are:
-
Created by the Open Web Application Security Project (OWASP).
-
Built with cybersecurity in mind.
-
Allows for the inclusion of vulnerability information.
-
Allows links to a separate Vulnerability Exploitability Exchange (VEX), which can indicate false positives and component vulnerability information.
SPDX (Software Package Data Exchange)
-
Developed by the Linux Foundation.
-
Built with license compliance in mind.
-
Makes collecting and sharing package data easier
CycloneDX and SPDX meet the National Telecommunications and Information Administration’s minimum requirements for a Software Bill of Materials.
Why is a software bill of materials necessary?
An SBOM:
-
Provides a consistent, readable profile of an application's dependencies.
-
Provides a standard format that customers can easily understand
-
Can be automatically generated during a project's build step to ensure up-to-date dependency information.
-
Standardizes the way dependencies are listed.
-
Makes reviewing dependencies easy, regardless of the ecosystem.
-
Makes automation easier through standardization.
Why do creators need SBOMS?
-
Maintaining a software bill of materials helps track a project's dependencies.
-
A software bill of materials keeps track of package versions making finding vulnerable components easier.
-
Using a single standard for storing dependency info allows teams to improve consistency.
-
An SBOM helps reduce the burden of working across ecosystems.
Why do consumers need SBOMs?
-
Software bill of materials enables a more transparent way to operate.
-
Allows consumers to ensure a product meets their internal security and architectural requirements.
-
Third-party software with an SBOM is less risky than third-party software without one.
-
Consumers can use the SBOM to monitor their security.
-
Many SBOM software tools can scan an SBOM and generate a list of vulnerabilities.
When should an SBOM be made publicly available?
Discretion should always be exercised when deciding when and how an SBOM is shared. For projects where the source code is proprietary or private, making it available to existing customers and qualified leads is recommended.
When it comes to open source projects, there is little risk to incur from maintaining a publicly shared SBOM. Why? The dependency information is already publicly available.
A best practice is to create a public advisories page to call out false positives. Making this info publicly available provides additional transparency and gives users another way to monitor their safety.
How do I create a software bill of materials?
There are several different SBOM software tools available to generate a software bill of materials. Often these tools are very easy to use and will generate an SBOM in minutes.
For this example, we will outline how to generate a free sample SBOM report with Sonatype.
-
Choose your application.
-
Upload the application to scan for vulnerabilities.
-
Receive a software bill of materials with a complete view of vulnerabilities and open source risk.
How do I manage my SBOMs?
After you have created a software bill of materials for every application in your software portfolio, you will need a way to manage them. Filing your SBOMs away without continuous monitoring and management defeats their purpose.
While some software composition analysis (SCA) tools have an SBOM component, a more comprehensive SBOM software management tool is needed. Sonatype SBOM Manager is an enterprise-class SBOM software management solution that enables organizations to:
-
Audit SBOMs to simplify risk management and compliance.
-
Distribute SBOMs at scale in both CycloneDX and SPDX formats.
-
Monitor SBOMs continuously and identify new malware and vulnerabilities.
-
Comply with SBOM regulatory requirements.
By using an SBOM software management tool, you will be able to create, store, and monitor your SBOMs all in one place.