Generate an SBOM with Microsoft’s open source tool


Shutterstock.com/Song_about_summer

A Software Bill of Materials (SBOM) helps you understand your software supply chain by listing the packages and vendors your code relies on. SBOMs are rapidly gaining traction as a way to help improve security in the wake of prominent real-world supply chain attacks.

A big proponent of SBOMs is Microsoft, which has published its approach to their generation back in October 2021. Earlier this year, the company its tool open source for producing SBOMs on Windows, macOS and Linux.

In this article, you’ll learn how to start using the project to index your code’s dependencies. It produces SPDX compliant documents that represent the files, packages, and relationships within your project. SPDX (Software Package Data Exchange) is the ISO accepted standard for SBOMs, allowing you to pass generated reports directly to other ecosystem tools.

Microsoft originally announced the project under the name Salus. It’s since withdrew from this term because it conflicts with the existing Salus code security project which originated at Coinbase. The SBOM generator is now simply called sbom tool.

To work

You can download SBOM Tool from Microsoft’s GitHub repository. Precompiled binaries are available on the release page. Select the appropriate download for your system, make the binary executable and move it to a location on your path.

Here’s an example for Linux:

$wget https://github.com/microsoft/sbom-tool/releases/download/v/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 display the help information in your terminal window:

$ sbom-tool No action was specified The Sbom tool generates an SBOM for each build artifact. Usage – Microsoft.Sbom.Tool -options

Generate an SBOM

New SBOMs are created by running the tool’s Generate subcommand. There are a few arguments to be made:

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

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 package.json name and version fields, but in some cases you may need to enter the information manually or override the default settings. To do this, add the pn and pv flags:

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

Here is an example of generating an SBOM for the files in your workbook. The SBOM is placed in the sbom-output subdirectory. This must exist before you run the utility.

$ 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 is shown in your terminal:

[INFO] Listing 3728 files and 607 folders 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 the dependencies. The tool has detected 241 packages in the package.json file of the working directory.

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

SBOM content

The generated SBOM is written to _manifest/spdx_2.2/manifest.spdx.json in the build output directory you specified. The SBOM is a fairly comprehensive JSON file intended to be used by other software.

{ “files”: []”packages”:[{“name”:”color-convert””SPDXID”:”SPDXRef-Package-A72B0922E46D9828746F346D7FD11B7F81EDEB15B92BEEDAE087F5F7407FECDC”…}

There are four main types of information in the report:

Files section – Displays all the files that contain the source code you’ve written in your project. SBOM Tool will only populate this section when scanning certain project types, 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. Relationships section – Describes all 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 others types of relationships 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 applicable SPDX manifest revision.

Now that you have an SBOM, you can start using it with other tools to run vulnerability scans and manage license compliance. You may want to consider distributing the SBOM with your software releases so that consumers can view the content 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 issues arise. For example, organizations using SBOMs were better placed to respond to Log4j. They could inspect their reports to quickly find projects that rely on the vulnerable library, instead of manually checking package lists.

Scan Docker images

SBOM Tool is able to scan existing Docker images as part of report generation. To use this feature, you need to add the -di flag and specify the image tag or summary you want to scan. The rest of the arguments remain the same.

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

The Docker image is analyzed to identify the packages it contains. They are added to the SBOM report next to the dependencies in your source folder. You can scan multiple Docker images at once by separating their tags or digesting hashes with commas.

Overview

SBOM Tool is a young open source tool for generating SBOM developed by Microsoft. It supports several leading package formats and produces SPDX compatible output. This means you can feed generated SBOMs directly into other tools like Grype to automatically find vulnerabilities and outdated dependencies.

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

Leave a Reply

Your email address will not be published.