Apache Log4j 和 Log4Shell 两大事件的发生，将软件物料清单（Software Bill of Materials, SBOM）推向安全防护前沿，成为企业保护其软件供应链的方式之一。今年 5 月，美国总统拜登发布行政命令，要求 IT 供应商必须提供 SBOM 才能够与美国政府进行合作。受此影响，越来越多的企业也开始将 SBOM 集成到其 DevSecOps 流程中。

那么 SBOM 是什么呢？我们通常将 SBOM 笼统地描述为成分列表，就好比食物成分表会罗列使用到的材料，我们可以通过 SBOM 去了解应用程序、服务、包等。严格来说，SBOM 并不是解决软件供应链安全问题的完整解决方案，但它是保护软件供应链的关键部分。

SBOM 在未来将作为软件开发框架（Software Development Framework, SDF）的主要组件。SBOM 通过包含软件组件和依赖项列表来增加软件交付的透明度，如果没有 SBOM，软件依赖项、开源或商业许可问题、已知漏洞或其他潜在恶意成分的可见性就会降低。如果企业使用不含 SBOM 的软件，且不进行额外的软件尽调分析，可能需要承担一定的安全风险。

虽然采用 SBOM 对提高安全性产生积极作用，但在 SBOM 真正发挥作用前，企业需要进行大量准备工作。这样看来，虽然 SBOM 能够在一定程度上保障企业的软件供应链安全，但实践起来还是存在一定的阻碍和困难。

选择 SBOM 提供商需要注意什么？

企业在选择 SBOM 提供商时要注意的主要事项包括：

• 理想情况下，供应商应当提供其交付的每一个软件的 SBOM。而软件用户将使用软件成分分析（SCA）生成新的 SBOM 以用于提供给客户。软件供应链中最终交付时的 SBOM 应当包含一份全面、准确的清单，并列出所涉及的组件和版本。这就意味着供应链中每个环节的软件供应商都需要提供全面的 SBOM，否则最终的 SBOM 将会不准确或不完整。

• SBOM 存在多个标准，包括 CycloneDx、SPDX 和 SWID Tag。大多数企业都希望 SBOM 包含依赖关系、列表、已知漏洞（CVE-ID）和软件许可证信息，但不同的 SBOM 标准对应的格式也不同，其包含的信息也会有所差异，这也使得 SBOM 不容易成为一个通用的解决方案。

• DevSecOps 团队需要认识到 SBOM 本身也是一个需要保护的数字文档。SBOM 和 组织都需要确保 SBOM 不会受到损害。企业需要通过集成检查和数字签名来防止篡改，确保 SBOM 的完整性和真实性。许多企业在收集或维护 SBOM 方面仅仅停留在表面而未进行深入研究。虽然 SBOM 可以增加软件供应链的可见性和透明度，但与此同时也给企业带来额外挑战，因为企业需要使用新的工具和实施新的流程。

考虑到这些注意事项后，如果企业没实施适当的 DevSecOps 流程，即使是最好的 SBOM 提供商也无济于事。通过 SBOM 来发现软件供应链中的新漏洞对企业来说十分有价值，但如果企业并没有制定和执行相应的 SBOM 使用流程，那 SBOM 中的信息就只是目录中的文件毫无意义。

SLSA 与 SBOM 的关联

当然，SBOM 也不是“灵丹妙药”，它无法涵盖软件供应链的所有领域。因此，实施跨 CI/CD 流水线的安全监控和程序检查并在部署后阶段覆盖运行时，使用 SLSA 补充 SBOM 是必要且明智的。SLSA 为企业提供了框架和指南，以便更好地实施 SBOM 和其他安全措施。

但企业需要明白的是，SBOM 和 SLSA 的目标是保障软件供应链安全，它们是保护软件供应链的两个组成部分而非完整的软件供应链安全解决方案。SLSA 和 SBOM 针对的领域和问题都不同，企业不能只是简单的将其采购回来，就指望所有的安全问题都被完美解决。

SBOM 和 SLSA 的采用虽然尚未成为主流，但仍然是保障软件供应链安全的一个良好开端。SBOM 提供明细，SLSA 详细说明了如何以安全的方式生成这些信息。软件公司可以利用 SBOM 与 SLSA 作为竞争优势，也作为软件安全生产的保证。