自我们在 2021 年首次提到 软件物料清单（SBOM） 以来，其生成已经从新兴实践转变为我们项目中的默认选项。SBOM 生态系统显著成熟，提供了强大的工具支持，并实现了与 CI/CD 系统的无缝集成。工具如 Syft、Trivy 和 Snyk 能够从源代码到容器镜像生成全面的 SBOM，同时支持漏洞扫描。FOSSA 和 Chainloop 等平台通过与开发工作流集成以及实施安全策略，进一步提升了安全风险管理能力。尽管统一的 SBOM 标准仍在演化，但对 SPDX 和 CycloneDX 的广泛支持已显著降低了采用门槛。同时，AI 系统也需要 SBOM 的支持。英国政府的 AI 网络安全行为准则 和 CISA 的 AI 网络安全协作手册 就证明了这一点。我们将继续关注该领域的发展动态。
在保障系统安全性的压力不变且总体安全威胁不减的情况下，一个机器可读的 软件物料清单 （SBOM）可以帮助团队掌握他们所依赖的库中的安全问题。随着美国总统令的发布，业界对 SBOM 的概念和如何创建 SBOM 都有了清晰的认识，例如国家标准与技术研究院（NIST）也针对如何执行总统令提出了更详细的建议。现在我们已经具备了在项目中使用 SBOM 的生产经验，项目范围从小型企业到大型跨国公司，甚至是政府部门，而且我们确信它能为我们提供益处。更多的机构和政府部门应当考虑索取正在使用的软件的 SBOM。随着 Firebase Android BOM 等可以自动罗列应用软件 BOM 中依赖库的新工具的不断出现，这项技术也将持续强化。
2021年5月，美国白宫发布了《关于改善国家网络安全的行政命令》。该文件提出了一些与我们在过去的技术雷达中展示的项目相关的技术要求，例如零信任架构以及使用安全策略即代码的自动合规性扫描。该文档的大部分内容都致力于提高软件供应链的安全性。特别引起我们注意的一项是要求政府软件应包含机器可读的软件物料清单 (SBOM)，它被定义为“包含构建软件使用的各种组件的详细信息和供应链关系的正式记录”。换句话说，它不仅应该详细说明交付的组件，还应该详细说明用于交付软件的工具和框架。这一秩序有可能开启软件开发透明和开放的新时代。这无疑会对以软件为生的我们产生影响。即使不是全部，今天生产的绝大部分软件产品都包含或在构建过程中使用了开源组件。通常，消费者无法得知哪个版本的软件包可能会影响其产品的安全性。于是他们不得不依赖零售供应商提供的安全警报和补丁。该行政命令确保向消费者提供所有组件的明确描述，使他们能够实施自己的安全控制方案。由于 SBOM 是机器可读的，这些控制可以自动化。从这一举措我们感受到了向拥抱开源软件的转变，在享受开源的同时我们也会实际解决它带来的安全风险。
