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
相关阅读:
Linux 基金会《软件材料清单(SBOM) 与网络安全准备度》报告深度解读 |InfoQ《极客有约》
评论