How to generate an SBOM with Microsoft’s Open Source tool

Shutterstock.com/Song_about_summer

An SBOM (Software Bill of Materials) helps you understand your software supply chain by listing the packages and vendors your code is based on. SBOMs are rapidly gaining momentum as a way to help improve security in the wake of major supply chain attacks in the real world.

One of the main supporters of SBOMs is Microsoft, which released its approach to their generation in October 2021. Earlier this year the company opened its tool for producing SBOMs on Windows, macOS and Linux. .

In this article, you will learn how to get started using the project to index your code dependencies. Produces SPDX compliant documents that list files, packages, and relationships within the project. SPDX (Software Package Data Exchange) is the ISO accepted standard for SBOM, so you can pass the generated reports directly to other tools in the ecosystem.

Microsoft originally announced the project under the name Salus. It has since withdrawn from this term because it conflicts with the existing Salus code security project that originated on Coinbase. The SBOM generator is now referred to simply as sbom-tool.

To start

You can download the SBOM tool from Microsoft’s GitHub repository. The precompiled binaries are available on the releases page. Select the right download for your system, then make the binary executable and move it to a location in your path.

Here is an example for Linux:

$ wget https://github.com/microsoft/sbom-tool/releases/download/v<VERSION>/sbom-tool-linux-x64
$ chmod +x sbom-tool-linux-x64
$ mv sbom-tool-linux-x64 /usr/local/bin/sbom-tool

You should be able to run sbom-tool to view help information in the terminal window:

$ sbom-tool
No action was specified

The Sbom tool generates a SBOM for any build artifact.

Usage - Microsoft.Sbom.Tool <action> -options

Generate in SBOM

New SBOMs are created by running the tool generate subcommand. Some arguments need to be provided:

  • -b (BuildDropPath) – The folder in which to save the generated SPDX SBOM manifests.
  • -bc (BuildComponentPath) – The folder that will be scanned to find dependencies in your project.
  • -nsb (NamespaceUriBase) – The base path that will be used as the namespace of the SBOM manifest. This should be a URL owned by your organization, for example https://example.com/sbom.

The SBOM tool also needs to know the name and version of your project. It can often infer this from files already in your repository, such as the package.json name Other version fields, but you may need to provide the information manually or override the default settings in some cases. Add the pn Other pv flag to do this:

  • -pn (PackageName) – The name of your project or package.
  • -pv (PackageVersion) – The version of the project you are scanning. This should match the release version that comes with your SBOM so that users can correlate dependency lists with specific builds.

Here is an example of generating an SBOM for files in the working directory. The SBOM will be included in the sbom-output subdirectories. This must exist before running the tool.

$ mkdir sbom-output
$ sbom-tool generate -b sbom-output -bc . -pn example -pv 1.0 -nsb https://example.com/sbom

An overview of the scan results will be shown on your terminal:

[INFO] Enumerated 3728 files and 607 directories in 00:00:00.5938034 

[INFO] |Component Detector Id         |Detection Time                |# Components Found            |# Explicitly Referenced                 | 
...
[INFO] |Npm                           |0.63 seconds                  |241                           |0                                       | 
...
[INFO] |Total                         |0.64 seconds                  |241                           |0                                       | 

[INFO] Detection time: 0.6374678 seconds.

This project uses npm to manage its dependencies. The tool found 241 packages within the working directory package.json file.

SBOM Tool currently supports 19 different programming languages ​​and package formats. The list includes npm, NuGet, PyPi, Maven, Rust Crates, and Ruby gems, as well as Linux packages found in Docker images. References to remote GitHub repositories are also supported.

SBOM summary

The generated SBOM will be written _manifest/spdx_2.2/manifest.spdx.json within the specified build output directory. SBOM is a fairly detailed JSON file intended for use by other software.

{"File": []"package": [
    {
      "name": "color-convert",
      "SPDXID": "SPDXRef-Package-A72B0922E46D9828746F346D7FD11B7F81EDEB15B92BEEDAE087F5F7407FECDC",
      ...
    }

There are four main types of information within the report:

  • The files section – This lists all the files containing source code you’ve written in your project. SBOM Tool will only populate this section when certain project types are scanned, such as C# solutions.
  • The packages section – A complete catalog of all the third-party dependencies present in your project, with references to their source package manager, the version used, and the type of license that applies.
  • The relationships section – This details all the relationships between the components listed in the SBOM. The most common relationship you’ll see is DEPENDS_ON, which declares an item in the packages section as one of your project’s dependencies. Several other kinds of relationship also exist, such as CREATED_BY, DEPENDENCY_OF, and PATCH_FOR.
  • Report metadata details – Fields such as name, documentNamespace, spdxVersion, and creationInfo identify the SBOM, the tool used to create it, and the SPDX manifest revision that applies.

Now you’ve got an SBOM you can start using it with other tools to conduct vulnerability scans and manage license compliance. You can consider distributing the SBOM with your software releases so consumers are able to inspect the contents of each new version. SBOMs are best generated as part of your build pipeline so they stay up to date.

Having access to an SBOM is invaluable when major new supply chain problems appear. Organizations using SBOMs were better placed to respond to Log4j, for example. They could inspect their reports to quickly find projects depending on the vulnerable library, instead of auditing package lists by hand.

Scanning Docker Images

SBOM Tool is capable of scanning existing Docker images as part of a report generation. To use this capability, you need to add the -di flag and specify the image tag or digest that you want to scan. The rest of the arguments stay the same.

$ sbom-tool generate -di ubuntu:latest -b sbom-output -bc . -pn demo -pv 1.0 -nsb https://demo.com/demo

The Docker image will be analyzed to identify the packages it includes. They’ll be added to the SBOM report alongside the dependencies found in your source folder. You can scan multiple Docker images in a single operation by separating their tags or digest hashes with commas.

Summary

SBOM Tool is a young open-source SBOM generation utility developed at Microsoft. It supports several leading package formats and produces SPDX-compatible output. This means you can feed generated SBOMs straight into other tools like Grype to automatically find security vulnerabilities and outdated dependencies.

SBOMs are an effective way to increase awareness of software supply chains and uncover lurking issues. Producing and distributing an SBOM helps users understand what’s being silently included in their project. SBOM Tool is one way to generate industry-standard reports with a single command, making it easier to offer an SBOM with each of your releases.