Software Bill of Materials
A Software Bill of Materials (SBOM) goes into producing a piece of software. For a .NET project this will be the framework version and exact versions of all NuGet packages used to produce the build. For a firmware image of an embedded system, an SBOM consist of bootloader, libraries, executables and file that make up the image.
SBOMs can have various uses.
- Identify vulnerabilities in components
- Track compromised dependencies
- Ensure license compliance (MIT, GPL, Apache etc.)
- Component transparency
identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products;
Source ANNEX I
If the manufacturer decides to make available the software bill of materials to the user, information on where the software bill of materials can be accessed.
Source ANNEX II.
The manufacturer is not required to make the SBOM public. But they might need to make it available to authorities upon request.
CycloneDX vs SPDX
The two commonly used formats for machine-readable SBOM are CycloneDX (ECMA-424) and SPDX (ISO/IEC 5962:2021).
Generating SBOMs
Most tools for generating SBOM will include transient dependencies in addition to top-level dependencies. Though including transient dependencies is not required, the inclusion increases the usefulness of the SBOM, as it allows scanning all dependencies against databases of known vulnerabilities.
SBOM shall be generated for all releases. It is common to set up SBOM generation as part of CI/CD pipeline. Here is a list of SBOM generation tools for some popular technologies.
NPM
Python
.NET
Java
Rust
Containers
- Syft (CycloneDX+SPDX)
- Often used in combination with Grype for vulnerability scanning.
- Trivy
- Docker Scout
- Docker Buildkit
Various
For more SBOM related tools, see CycloneDX Tool Center.