Microsoft’s SBOM has been creating component manifests for its applications using a custom tool with custom report formats. By participating in the SPDX standards process, Microsoft improved its own tool to support this alternative format, implementing it throughout its own development and building pipelines.
These kinds of tools must be widely accessible, simple to use, and compatible with all the platforms that you’re likely to utilize for your code. To make sure that information about code is recorded where it is produced and compiled, they must plug into standard development tools or CI/CD pipelines.
Table of Contents
Why Have An SBOM?
A software bill of materials (SBOM) is useful to producers and consumers of software, as it provides software transparency, software integrity, and software identity benefits. Here is a bit about each:
Vulnerability detection and SBOMs
For the automation of software supply chain security, deep visibility into COTS applications is necessary. To properly understand the organization’s security risks, this necessitates having access to a BOM as well as thorough vulnerability information.
Software transparency
SBOMs offer a list of the components, open source software, parts, and sometimes even build tools that went into making a particular piece of software. Producers and consumers may better inventory, assess license and vulnerability risks, and plan accordingly.
Reducing risk
The information generated by an SBOM can be put to use in a number of different ways once a vulnerability has been found. Start by evaluating the results in terms of likelihood and impact. Probability is the assessment of the possibility that an attack will be successful using the identified vulnerability.
Software dependability
SBOMs provide package and file checksums to allow consumers to validate the hashes, which might be beneficial in situations where signatures are absent. Code signing is still the industry standard for ensuring the authenticity of software.
Getting Started
SBOM Tool is available for download from Microsoft’s GitHub page. On the releases page, precompiled binaries are accessible. Make the binary executable, then move it to a spot in your path after choosing the appropriate download for your system.
Generating an SBOM
We can generate new SBOMs by using the tool’s “generate” subcommand. There are a few arguments that must be made:
- -b (BuildDropPath) – The location where the created SPDX SBOM manifests should be saved.
- -bc (BuildComponentPath) – The location of the folder that will be searched for project dependencies.
- -nsb (NamespaceUriBase) – The base route that will serve as the namespace for the SBOM manifest. This should be a domain that belongs to your company, such as https://example.com/sbom.
The SBOM tool also requires the project’s name and version. Frequently, you may derive this information from files that are already present in your repository, like the package. Although there are JSON name and version fields, there may be times when you need to manually enter the information or change the defaults. In order to do this, include the pn and pv flags:
- -pn (PackageName) – The name of your project or package.
- -pv (PackageVersion) – The version of the project you are looking at. This should correspond to the release version that your SBOM supports so that users can connect dependency lists to particular builds.
SBOM Contents
The report contains four different sorts of information in general:
The files section
The files section contains a list of every file you’ve written with source code for your project. This part will only be filled out by the SBOM Tool when specific project types.
The packages section
The packages section contains a comprehensive list of all third-party dependencies utilized by your project, together with information about their source package manager, the current version, and the applicable licensing type.
Reporting metadata details
Reporting metadata information Fields like name, documentNamespace, spdxVersion, and creationInfo are used to identify SBOMs. These fields also reveal the tool used to build the SBOM and the applicable SPDX manifest revision.
The relationships section
The relationships section explains each connection between each item listed in the SBOM. The most frequent relationship you’ll encounter is DEPENDS ON, which identifies a package in the packages section as a dependency of your project. There are a number of other relationship types, including CREATED BY, DEPENDENCY OF, and PATCH FOR.
Summary
The Microsoft SBOM tool generates the output that is SPDX-compatible and supports a number of popular package formats. This implies that you can directly feed created SBOMs into other tools like Grype to discover security flaws and out-of-date dependencies. SBOMs are a useful tool for bringing software supply chains to people’s attention and exposing hidden problems. Users can better understand what is being discreetly incorporated in their project by creating and disseminating an SBOM.