Software Bill of Materials Best Practices

A software bill of materials (SBOM) is a list of all packages and libraries included in your application. It’s the digital equivalent of a manufacturing bill of materials. Just as a bill of materials includes all sub-assemblies, the SBOM also includes transitive dependencies or your components’ dependencies. And like a traditional BOM, the SBOM makes it easy to see if any risky packages are included in an application.

Generate and store an SBOM for every application

Generate an SBOM for every application during the build process

A Software Bill of Materials is the first step to managing your software supply chain. Releasing high-quality, risk-free software requires that you understand what components you're using so you can identify vulnerabilities in your application. SBOMs store this information and tie the components in your software to a specific time or version of your application. This lets you check which components are in your application whenever the need arises.
SBOMs create an audit trail for your applications. They tell you what components are in a specific version of your application. This is useful when new vulnerabilities are discovered in older components. If you have customers using older versions of your application, you can scan the SBOMs to determine which versions of your application are vulnerable.
Automate the SBOM creation process to ensure every build has a corresponding SBOM for compliance purposes.
Sonatype Lifecycle can often give better scan results when an SBOM is included in the scanned files.

Store the SBOMs in your Sonatype SBOM Manager

This can be done automatically alongside your build process. Storing these files in SBOM Manager provides centralized storage for your SBOMs and your third-party applications.

Beware of the risks in sharing your SBOMs with the general public

Your application composition can contain sensitive information. SBOMs can be run through Software composition analysis tools to create a list of vulnerabilities. Making your SBOMs publicly available makes it trivial for anyone to identify possible vulnerabilities in your application. If you're actively managing these risks, publicly disclosing an SBOM might be beneficial.
You should only share your SBOM for compliance purposes or with trusted third parties.

Include the SBOM in your Lifecycle scans

Include scan results as a link in your SBOM or with your SBOM

An SBOM is only the first step to managing your Open Source risk. The next step is to identify potential vulnerabilities based on the Open Source Software you're using. CycloneDX supports linking to a Vulnerability Exploitability Exchange formatted document to record the vulnerabilities at the time of the scan.

Vulnerability data stored in an SBOM should not be used for long-term risk assessment

SBOMs are point-in-time documents that are not meant to change. Though your software's dependencies will not change, the vulnerabilities associated with those components can change frequently. As software ages, more exploitable risks are likely to be found in the code.