SBOM （软件物料清单）通过列出您的代码所依赖的软件包和供应商来帮助您了解您的软件供应链。SBOM 正迅速获得发展势头，作为在现实世界供应链受到重大攻击后帮助提高安全性的一种方式。
SBOM 的主要支持者之一是微软，该公司早在 2021 年 10 月就发布了针对他们这一代的方法。今年早些时候，该公司开源了其用于在 Windows、macOS 和 Linux 上生成 SBOM 的工具。
在本文中，您将学习如何开始使用该项目来索引代码的依赖项。它生成与 SPDX 兼容的文档，列出项目中的文件、包和关系。SPDX（软件包数据交换）是 ISO 接受的 SBOM 标准，因此您可以将生成的报告直接传递到其他生态系统工具。
微软最初以 Salus 的名义宣布了该项目。由于它与起源于 Coinbase的现有Salus 代码安全项目相冲突，因此从该术语中退出。SBOM 生成器现在简称为.sbom-tool
入门
您可以从 Microsoft 的GitHub 存储库下载 SBOM 工具。发布页面上提供了预编译的二进制文件。为您的系统选择正确的下载，然后制作二进制可执行文件并将其移动到您路径中的某个位置。
以下是 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
您应该能够运行sbom-tool以在终端窗口中显示帮助信息：
$ sbom-tool
No action was specified
The Sbom tool generates a SBOM for any build artifact.
Usage - Microsoft.Sbom.Tool <action> -options
生成 SBOM
generate通过运行该工具的子命令可以创建新的 SBOM 。需要提供一些参数：
- -b( BuildDropPath) – 将生成的 SPDX SBOM 清单保存到的文件夹。
- -bc( BuildComponentPath) – 将被扫描以查找项目中的依赖项的文件夹。
- -nsb( NamespaceUriBase) – 将用作 SBOM 清单的命名空间的基本路径。这应该是您的组织拥有的 URL，例如https://example.com/sbom.
SBOM Tool 还需要知道您的项目的名称和版本。它通常可以从存储库中已有的文件（例如package.json name和version字段）中推断出这一点，但在某些情况下，您可能需要手动提供信息或覆盖默认值。添加pn和pv标志来做到这一点：
- -pn( PackageName) – 您的项目或包的名称。
- -pv( PackageVersion) – 您正在扫描的项目版本。这应该与您的 SBOM 随附的发布版本相匹配，以便用户可以将依赖项列表与特定构建相关联。
这是为工作目录中的文件生成 SBOM 的示例。SBOM 将被放置到sbom-output子目录中。这需要在您运行该工具之前存在。
$ mkdir sbom-output
$ sbom-tool generate -b sbom-output -bc . -pn example -pv 1.0 -nsb https://example.com/sbom
扫描结果的概述将显示在您的终端中：
[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.
这个项目使用 npm 来管理它的依赖。package.json该工具在工作目录的文件中检测到 241 个包。
SBOM Tool 目前支持 19 种不同的编程语言和包格式。该列表包括npm、NuGet、PyPi、Maven、Rust Crates 和 Ruby gem，以及 Docker 映像中存在的 Linux 包。还支持对远程 GitHub 存储库的引用。
SBOM 内容
生成的 SBOM 将写入_manifest/spdx_2.2/manifest.spdx.json您指定的构建输出目录中。SBOM 是一个相当冗长的 JSON 文件，旨在供其他软件使用。
{
"files": [],
"packages": [
{
"name": "color-convert",
"SPDXID": "SPDXRef-Package-A72B0922E46D9828746F346D7FD11B7F81EDEB15B92BEEDAE087F5F7407FECDC",
...
}
报告中有四种主要类型的信息：
- 该files部分- 这列出了包含您在项目中编写的源代码的所有文件。SBOM 工具仅在扫描某些项目类型（例如 C# 解决方案）时才会填充此部分。
- 该packages部分- 项目中存在的所有第三方依赖项的完整目录，其中包含对其源包管理器的引用、使用的版本以及适用的许可证类型。
- 该relationships部分- 这详细说明了 SBOM 中列出的组件之间的所有关系。您将看到的最常见的关系是DEPENDS_ON，它将packages节中的一项声明为项目的依赖项之一。还存在几种其他类型的关系，例如CREATED_BY、DEPENDENCY_OF和PATCH_FOR。
- 报告元数据详细信息– 、 、等字段name，documentNamespace并spdxVersion标识creationInfoSBOM、用于创建它的工具以及适用的SPDX 清单修订。
现在您已经有了一个 SBOM，您可以开始将它与其他工具一起使用来进行漏洞扫描和管理许可证合规性。您可以考虑将 SBOM 与您的软件版本一起分发，以便消费者能够检查每个新版本的内容。SBOM 最好作为构建管道的一部分生成，以便它们保持最新状态。
当出现重大的新供应链问题时，访问 SBOM 是非常宝贵的。例如，使用 SBOM 的组织可以更好地响应 Log4j。他们可以检查他们的报告以根据易受攻击的库快速找到项目，而不是手动审核包列表。
扫描 Docker 图像
作为报告生成的一部分，SBOM 工具能够扫描现有的 Docker 映像。要使用此功能，您需要添加-di标志并指定要扫描的图像标签或摘要。其余的论点保持不变。
$ sbom-tool generate -di ubuntu:latest -b sbom-output -bc . -pn demo -pv 1.0 -nsb https://demo.com/demo
将分析 Docker 映像以识别它包含的包。它们将与源文件夹中的依赖项一起添加到 SBOM 报告中。您可以在单个操作中扫描多个 Docker 映像，方法是用逗号分隔它们的标签或摘要哈希。
概括
SBOM Tool 是 Microsoft 开发的一个年轻的开源 SBOM 生成实用程序。它支持几种领先的包格式并产生与 SPDX 兼容的输出。这意味着您可以将生成的 SBOM 直接输入到 Grype 等其他工具中，以自动查找安全漏洞和过时的依赖项。
SBOM 是提高软件供应链意识和发现潜在问题的有效方法。制作和分发 SBOM 有助于用户了解他们的项目中默默包含的内容。SBOM 工具是使用单个命令生成行业标准报告的一种方法，可以更轻松地为每个版本提供 SBOM。