作者 | Sergio De Simone
译者 | 张卫滨
策划 | 丁晓昀
GitHub 宣布了一项新的 SBOM 导出特性，旨在作为安全合规工作流和工具的一部分。GitHub 声称，这项新特性能够让我们轻松导出符合 NTIA 标准的 SBOM。
用户可以通过一些不同的方式导出 SBOM，可以手动进行，也可以使用自动化的进程。要手动生成 SBOM，可以访问仓库的依赖关系图，然后点击新的 Export SBOM 按钮。这样会按照 SPDX 格式创建一个机器可读的 SBOM。
SPDX 是软件包数据交换（Software Package Data Exchange）的缩写，是一种专门用来描述软件物料清单（bill of materials）的开放格式，包括依赖关系、许可证、版权和安全引用。有许多工具（包括商业的和开源的）可以用来消费 SPDX 文件，以验证、分析或将其转换为其他格式。
除了使用 GitHub Web UI，还可以使用 GitHub CLI 的扩展或 GitHub Action 来导出 SBOM。
GitHub CLI 扩展可以通过运行 gh ext install advanced-security/gh-sbom 来安装。然后，通过 gh sbom -l 命令可以按照 SPDX 格式输出 SBOM，而 gh sbom -l -c 命令则会使用 CycloneDX 格式。
作为 GitHub CLI 的替代方案，我们还可以在构建时使用 GitHub Action 来输出 SBOM。GitHub 提供了自己的 GitHub Action，以便于从依赖关系图中导出 SBOM。如果愿意的话，还可以使用微软的 sbom-tool，或者基于 Syft 的 Anchore SBOM Action。
该公司说，未来还可以通过特定的 REST API 导出 SBOM。
GitHub 提供的另一种可能性是将现有的 SBOM 上传到一个仓库，以生成依赖关系图。这对于那些不愿意公开在软件中使用的所有依赖关系的组织来说是很有用的。生成了依赖关系图之后，就有可能收到 Dependabot 对仓库及其依赖关系发现的漏洞发出的告警。
很重要的一点需要注意，SBOM 虽然是许多行业和美国政府的要求，但它只是用来保护软件供应链的众多工具之一。它本身并不能解决依赖关系可能违规的问题，但它可以帮助你更好地衡量所选的实现方案所带来的安全风险，并且能够帮助你理解通过为系统引入给定的依赖都信任了哪些人。
查看英文原文：
GitHub Adds SBOM Export to Make it Easier to Comply with Security Requirements（https://www.infoq.com/news/2023/04/GitHub-sbom-export/）
声明：本文为 InfoQ 翻译，未经许可禁止转载。
今日好文推荐
裁员潮过去、削减中层管理潮又来了：升管理保饭碗，不灵了
如何防止架构师PM化
警方通报网传中电科加班事件调查结果；拼多多解散恶意功能团队；逼死程序员诈骗千万的“翟欣欣案”一审宣判 ｜ Q资讯
谷歌正式发布WebGPU！90多位贡献者研发6年，浏览器终于可以利用底层硬件了
