We are excited and proud to open source our software bill of materials (SBOM) generation tool. A key requirement of the Executive Order on Improving the Nation’s Cybersecurity, SBOMs are lists of ingredients that make up software components, providing software transparency so organizations have insight into their supply chain dependencies.
Our SBOM tool is a general purpose, enterprise-proven, build-time SBOM generator. It works across platforms including Windows, Linux, and Mac, and uses the standard Software Package Data Exchange (SPDX) format. (To see the previous announcement about our SBOM tool, please read Generating Software Bills of Materials (SBOMs) with SPDX at Microsoft.)
It can be easily integrated into and auto-detects NPM, NuGet, PyPI, CocoaPods, Maven, Golang, Rust Crates, RubyGems, Linux packages within containers, Gradle, Ivy, GitHub public repositories, and more. As we add more detectors to Component Detection, it will improve our SBOM tool as well.
SBOMs generated by our tool contain four main sections based on the SPDX specification:
- Document creation information: General information about the SBOM document, such as software name, SPDX license, SPDX version, who created the document, when it was created, etc.
- Files section: A list of files that compose the piece of software. Each file has some properties including the hashes of its content (SHA-1, SHA-256).
- Packages section: A list of packages used when building the software. Each package has additional properties such as name, version, supplier, hashes (SHA-1, SHA-256) and a Package URL (purl) software identifier.
- Relationships section: A list of relationships between the different elements of the SBOM, such as files and packages.
It can also reference other SBOM documents for capturing a full dependency tree. This is an important capability for including dependency references to SBOM documents, or SBOM documents from predecessor builds that are consumed into a subsequent build, shown below.
The resulting SBOM document references are added to the Document Creation Information section, with an example shown below.
"externalDocumentRefs": [ { "externalDocumentId": "DocumentRef-Demo-861-71558f43fca51a285338834fb9b3c7c14a78cd77", "spdxDocument": "https://sbom.microsoft/1:VF6zo7ndBEakT2mCbPwGug:j5h1PLm-TkijVnfDJD_CCA/7:861/MMerAxYfQkOTN4dWqqlV-A", "checksum": { "algorithm": "SHA1", "checksumValue": "71558f43fca51a285338834fb9b3c7c14a78cd77“ } },
Open sourcing our SBOM tool is an important step towards fostering collaboration and innovation within our community, and we believe this will enable more organizations to generate SBOMs as well as contribute to its development.
Ready to get started? Please read the guidelines to learn more about contributing and follow these instructions to generate an SBOM. If you want to share any feedback and/or report any bugs, please feel free to do so via discussions and issues. Your feedback will help shape the future of our SBOM tool and ensure supply chain security for all. If you find the tool useful, we’d love a star on the microsoft/sbom-tool GitHub repo.
https://devblogs.microsoft.com/devops/introducing-azure-devops-server-2022-rc1/#comment-3460
Excellent blog..! This is very informative and effective to understanding about the micro soft open source. Thanks for submission.
Hi Danesh, Adrian,
thanks for the info. Can you please briefly explain what is the difference of your SBOM generator compared to e.g. a SCA tools like Mends unified agent and ws_sbom_generator? It is not very clear how this tool will compete in the SCA tool landscape.
Markus Wild