Software Bill of Materials Best Practices

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.

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.

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.

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.

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.