技术文章

如果您搜索“如何自动创建 SBOM”，您会发现大量结果。作为一名软件工程师，我个人几乎立刻就对这些结果感到沮丧。他们中的大多数人并没有告诉我如何自动创建 SBOM，而是用了一半的篇幅告诉我为什么应该自动创建 SBOM。然后本文可能会以我工作时要考虑的一些精选示例或概念作为结尾。我将跳过大部分内容，因为我知道您可以很容易地找到它。我确实在这里找到了一篇很好的文章，但我想做一些不同的事情，只关注您现在可以在 CI 管道中实际免费使用的工具。

在本文中，我们将介绍五种不同的现实世界工具，您可以随时下载并试用它们。使用其中的哪一个并不重要，只要您使用某些东西即可。不要再拖延了……只需选择一个，打开文档，然后开始！

这些工具生成一种或两种常见的 SBOM 格式：SPDX 和 CycloneDX。您需要考虑哪种最适合您的使用。在以后的文章中，我将向您展示如何在两者之间进行转换，所以当您今天设置工具时，不要觉得您是在结合两者。

1. CycloneDX Maven 插件

“CycloneDX Maven 插件生成 CycloneDX 软件材料清单 (SBOM)，其中包含项目的所有直接和传递依赖项的聚合。CycloneDX 是一种轻量级软件物料清单 (SBOM) 标准，旨在用于应用程序安全环境和供应链组件分析。” - 
https://github.com/CycloneDX/cyclonedx-maven-plugin

仅限 Java。该插件可以为模块、包创建 SBOMS，或者针对项目的根运行以为其找到的所有内容创建物料清单。该文档组织良好，可让您在几秒钟内入门。

奖励： 如果您要推送到Maven Central，您可以将您的 SBOM 与 Sonatype 在您的公共页面上提供的依赖性分析进行比较。还有一个Sonatype Safety Rating将帮助您分流下一步以保护您的 Java 项目的供应链。

2. Kubernetes 组件

“bom 是一个实用程序，可让您创建、查看和转换软件物料清单 (SBOM)。bom 是作为项目的一部分创建的，用于为 Kubernetes 项目创建 SBOM。它使软件作者能够以简单而强大的方式为他们的项目生成 SBOM。”  
- https://github.com/kubernetes-sigs/bom

也适用于容器镜像依赖项！最适合 Go 应用程序。如果您的本地存储库有许可证，它们也会被处理成 SPDX。如果你的项目是用 Go 构建的，那么依赖项将被处理。

奖励：Cilium 构建管道包括一个在其自动化中签署 SBOM 图像的示例，您绝对应该考虑这样做。

3.微软的SBOM工具

“SBOM 工具是一种高度可扩展且企业就绪的工具，可为各种工件创建 SPDX 2.2 兼容的 SBOM。”
- https://github.com/microsoft/sbom-tool

是的，它适用于 Linux 和 Mac，而不仅仅是 Windows。随附一个 Dockerfile，供您维护自己的映像。附带 GitHub Actions 和 Azure DevOps Pipelines 的快速入门指南！

4.SPDX SBOM生成器

“spdx-sbom-generatortool 帮助社区中那些想要使用当前包管理器生成 SPDX 软件物料清单 (SBOM) 的人。它有一个命令行界面 (CLI)，可让您使用 SPDX v2.2 规范生成 SBOM 信息，包括软件的组件、许可证、版权和安全参考，并与 NTIA 当前已知的最少元素保持一致。它会自动确定软件实际使用了哪些包管理器或构建系统。”
- https://github.com/opensbom-generator/spdx-sbom-generator

适用于多种语言（请参阅他们的文档）。可以通过拉取源代码并直接执行它来运行，或者通过运行他们的 Docker 镜像（更适合 CI 目的）来运行。

5.赛夫特

“用于从容器映像和文件系统生成软件物料清单 (SBOM) 的 CLI 工具和 Go 库。”
- https://github.com/anchore/syft

提供您对 SPDX 或 CycloneDX 的选择。适用于多种语言（请参阅文档以获取完整列表）。如果您选择 CI/CD 平台，可以使用 GitHub Action 来简化流程。

奖励：您应该始终将所有依赖项固定到一个散列，而不是仅仅固定一个版本号。哈希永远不会改变，而版本指针可以修改以指向代码历史中的不同点。查看Kube VIP在使用 Syft GitHub Action 自动创建 SBOM 时如何在他们的管道中做到这一点。

最终奖金主题：SBOM 分析

由于我们已经在谈论自动化您的 SBOM 创建，我认为您可能想要实际使用该 SBOM 来做某事。当我编写软件时（或者至少当我负责编写软件时），我需要了解我的依赖项，以及它们的依赖项，等等。了解我的直接和传递依赖项将是一个梦想，但这样做所需的工作一直是一场噩梦。如果您从事应用程序安全，您实际上可能不得不多次经历这种噩梦。幸运的是，变革之风正在向我们袭来。

去年，当 Sonatype 动员其安全研究人员和机器学习技术创建2022 年软件供应链状况报告时，我们意识到这方面存在巨大差距。当然，工具是存在的……但即使使用市场上的工具，噩梦仍然存在。为了帮助提高整个软件行业的安全标准，Sonatype 创建了BOM Doctor，这是一款免费工具，可帮助可视化 SBOM 中列出的依赖项（目前仅限 Java……）。只需将您的文件放入，或将其指向带有 SBOM 的存储库，它就会创建一个可视化图表，它可以做一些有用的事情，比如突出显示每个传递链中最薄弱的环节。

如果您不在 Java 中工作并且还不能利用 BOM Doctor，您仍然可以从该方法中学习。SBOM 是 AppDev 和 AppSec 的一个很好的工具，如果您使用它来做出明智的决定，包括哪些依赖项以及何时升级（或删除）它们。您关于“不要只是创建 SBOM……实际使用它！”的讲座到此结束。 

您现在剩下的借口为零！设置您的管道以生成软件物料清单，然后使用您获得的数据开始改善您的安全状况。