The SBOM tool is a highly scalable and enterprise ready tool to create SPDX 2.2 compatible SBOMs for any variety of artifacts. The tool uses the Component Detection libraries to detect components and the ClearlyDefined API to populate license information for these components.

• Download and Installation
• Run the tool
• Integrating SBOM tool to your CI/CD pipelines
• Telemetry
• Contributing
• Security
• Trademarks

We distribute executables and SBOM files of the tool in GitHub Releases page. You can go and download binaries manually or use commands below to get the latest version of the tool for your platform.

Please check the CLI Reference document for additional help regarding the CLI tool.

winget install Microsoft.SbomTool

brew install sbom-tool

Invoke-WebRequest -Uri "https://github.com/microsoft/sbom-tool/releases/latest/download/sbom-tool-win-x64.exe" -OutFile "sbom-tool.exe"

curl -Lo sbom-tool https://github.com/microsoft/sbom-tool/releases/latest/download/sbom-tool-linux-x64
chmod +x sbom-tool

curl -Lo sbom-tool https://github.com/microsoft/sbom-tool/releases/latest/download/sbom-tool-osx-x64
chmod +x sbom-tool

Clone this repo and build the docker image.

git clone https://github.com/microsoft/sbom-tool
cd sbom-tool
docker build . -t ms_sbom_tool

You can then use the tool normally, by mounting the directories to be scanned using docker bind mounts.

The sbom-tool can also be installed as a .NET tool using the following command:

dotnet tool install --global Microsoft.Sbom.DotNetTool

Please add and authenticate the Microsoft GitHub NuGet package registry to your nuget.config. Then install the Microsoft.Sbom.Api package to your project using these instructions

Please check the API Reference document for addditional help regarding the SBOM tool C# Api.

Once you have installed the command line tool for your OS, run the tool using this command:

sbom-tool generate -b <drop path> -bc <build components path> -pn <package name> -pv <package version> -ps <package supplier> -nsb <namespace uri base>

The drop path is the folder where all the files to be shipped are located. All these files will be hashed and added to the files section of the SBOM. The build components path is usually your source folder, tool will scan this folder to search for project files like *.csproj or package.json to see what components were used to build the package. Tool uses component-detection to scan for components and dependencies, visit its Github page to get more information about supported components. The package name and version represent the package the SBOM is describing.

Each SBOM has a unique namespace that uniquely identifies the SBOM, we generate a unique identifier for the namespace field inside the SBOM, however we need a base URI that would be common for your entire organization. For example, a sample value for the -nsb parameter could be https://companyName.com/teamName, then the generator will create the namespace that would look like https://companyName.com/teamName/<packageName>/<packageVersion>/<new-guid>. Read more about the document namespace field here.

A more detailed list of available CLI arguments for the tool can be found here

With an SBOM file in hand, use the tool to validate the output file with the command:

sbom-tool validate -b <drop path> -o <output path> -mi SPDX:2.2

This sample command provides the minimum mandatory arguments required to validate an SBOM: -b should be the path same path used to generate the SBOM file. In this scenario, the tool will default to searching for an SBOM at the <drop path>\_manifest\spdx_2.2\manifest.spdx.json path. -o is the output path where the tool should write the results to. -mi is the ManifestInfo, which provides the user's desired name and version of the manifest format.

Currently only SPDX2.2 is supported.

You can follow these guides to integrate the SBOM tool into your CI/CD pipelines

• Setting up GitHub Actions to use the SBOM tool.
• Setting up Azure DevOps Pipelines to use the SBOM tool.

By default, telemetry will output to your output file path and will be a JSON blob. No data is submitted to Microsoft.

Please follow the steps here to clone and build this repository from source.

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include Microsoft, Azure, DotNet, AspNet, Xamarin, and our GitHub organizations.

If you believe you have found a security vulnerability in any Microsoft-owned repository that meets Microsoft's definition of a security vulnerability, please report it to us as described in the Security.md.

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.