Skip to main content

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 Nexus Repository (or other package managers)

  • This can be done automatically alongside your build process. Storing these files in NXRM, another artifact manager, or a source control repository gives you centralized storage for your SBOMs and standardizes the way these are stored across the organization.

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

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.