SLSA: 成功 SBOM 的促进剂

最新推荐文章于 2024-10-29 09:57:15 发布

Sectrend安势信息

最新推荐文章于 2024-10-29 09:57:15 发布

阅读量418

点赞数

分类专栏：势说新语文章标签：大数据

原文链接：https://slsa.dev/blog/2022/05/slsa-sbom

版权

势说新语专栏收录该内容

20 篇文章 2 订阅

订阅专栏

作者：Brandon Lum, Isaac Hepworth, Meder Kydyraliev

翻译：王峰

校对：孙文龙

SBOM 的全称是 Software Bill of Materials，中文译为软件物料清单，它不是一种特定的文件格式。SBOM 有不同的格式，但是其实质都是对于组件、依赖、漏洞、许可证、版权等信息的展示。

SLSA 的全称是 Supply-chain Levels for Software Artifacts, 中文译为供应链级别的软件制品，它是一个创建“安全软件供应链”的框架。

SBOM 和 SLSA 可以相互补充，遵循相关 SLSA 原则可以更容易地生成 SBOM。由于 SBOM 取决于准确性、完整性和可信度，因此拥有软件制品的 SLSA 源头数据可以提高 SBOM 的质量和完整性。

如果您正尝试构建和运行安全的软件，您可能听说过 SBOM，或称为软件物料清单。作为软件的“成分”标签，SBOM 是提供软件中所包含的软件包和组件的嵌套列表的文档。SBOM 作为安全的软件供应链中的一部分，得到了白宫发布的“关于提升网络信息安全 2021 年行政令”的支持。

SBOM 可以很好地帮助消费者更好地管理他们使用的软件带来的（潜在）风险，并能更轻松地应对漏洞。为了让 SBOM（在各种组织中）被更广泛地采纳，目前需要在 SBOM 的相关领域投入大量工作。但是，就像其他同等规模的行业变革一样，这其中有很多亟待解决的问题。例如：SBOM 目前没有包括或要求足够的信息来帮助用户响应构建篡改和攻击，例如 Solarwinds 和 Codecov；分发和验证 SBOM 文档的生态系统尚不完善；生成 SBOM 最常见的方式为写好代码之后使用代码审计工具进行扫描，但是这可能导致 SBOM 的准确性降低。

我们相信，SLSA（供应链级别的软件制品）作为一种创建安全软件供应链的框架，当它与 SBOM 结合使用时，可以解决这些潜在的问题。本篇文章阐释了 SBOM 和 SLSA 的优势以及它们之间的根本区别，并展示了 SLSA 原则如何既可以支持生成高质量的 SBOM 又可以帮助消费者应对供应链攻击。

SLSA vs. SBOM

如果 SBOM 就像食物的配料表，那么 SLSA 可以被认为是使配料表可信的食品安全处理指南。从清洁工厂环境的标准，确保污染物不会进入包装工厂，到超市货架上食品包装防止内容物被掉包的密封条，这一整套确保食品安全的框架保证了消费者可以确信他们买到的食品与包装上的食品配料表是一致的。

同样，通过为软件生产过程的每个步骤中提供指导和依据，SLSA 框架确保了它的可信度，其目的是使最终产生的软件包的 SBOM 是可信的。作为一个框架，SLSA 给出了一些具体的实践和指南，以帮助您安全地构建软件并验证其完整性。这些指南有助于降低如下风险：

代码被修改（通过在源代码控制后向代码添加防篡改“封条”）；
上传的软件制品不是由 CI/CD 系统构建的（通过使用工厂“标签”来标记软件制品，以验证它是由哪个构建服务创建的）；
对构建系统的威胁（通过为构建系统服务提供“制造设施”的最佳实践）。

SBOM 和 SLSA 在不同情况下都（对构建安全的软件供应链）有很大帮助。就像如果发生产品召回，成分列表很有用，以便受影响的商品可以从超市货架上撤下。同样的，SBOM 可以帮助回答这个问题：“我是否受到 Log4j（或下一个重大漏洞）的影响？”

另一方面，SLSA 回答了更广泛的问题：“我是否可以信任这个软件在生产过程的每个步骤中都使用了安全开发最佳实践？” 更为重要的是，SLSA 还可以回答以下问题：“我的软件是否满足安全软件开发框架的要求？”

SLSA 和 SBOM

SBOM 和 SLSA 可以相互补充，遵循相关 SLSA 原则可以更容易地生成 SBOM。特别是，SLSA 的一个主要原则是需要生成防篡改的源头数据，即证明谁执行了软件制品的发布过程、生产环节中使用的材料以及软件制品是否受到防篡改保护的这些元数据。由于 SBOM 取决于准确性、完整性和可信度，因此拥有软件制品的 SLSA 源头数据可以提高 SBOM 的质量和完整性。

准确性和完整性

当前，许多工具创建 SBOM 的方法依赖于推测，或者使用来自最终软件产品的信息生成成分列表。但是，这种方法有其缺点，因为如果您尝试通过扫描已编译的软件制品来生成 SBOM，可能会漏掉那些诸如不包含其依赖元数据的静态链接的二进制文件之类的信息。同样，通过基于文件哈希来生成 SBOM 可能会误报一些实际上并未受到影响的漏洞，从而降低对整个漏洞响应过程的信任。

另一方面，在 SLSA 认证信息的帮助下会生成更准确的 SBOM。通过使用构建过程中生成的 SLSA 来源信息和元数据，您可以获得有关软件制品内容的高保真信息，包括更精确的依赖信息，这样您就不必在之后需要通过推测得到。

绿色显示传统的 SBOM 信息来源；使用 SLSA 可以在 SBOM 中包含构建信息。（红色三角形标记了 SLSA 可以解决的对软件供应链造成的威胁。）

SLSA 准确的构建元数据还有助于提供有关软件构建方式的有形信息：构建元数据会写明输入的物料和生产制品的工厂信息。如果有缺陷的商品是由质量控制不佳或机器（例如受损的构建系统或编译器等工具中的错误）引起的，那么包含这些额外数据的 SBOM 将更加完整，并帮助用户应对供应链受损的问题。

可信度

从 SLSA 源头数据生成的 SBOM 增强了用户对 SBOM 准确性的信心，因为用户知道它是根据有高保真度的构建元数据来创建的：成分列表是通过观察产品制造时添加的内容物生成的。SLSA 源头数据还告诉用户元数据来自可验证的构建，并且出处数据本身已被捕获并以安全的方式签名。在 SBOM 中引用这些源头数据文档为生产软件的安全过程提供了额外的保障。

SLSA 社区在创建这种完整性方面的经验对 SPDX（软件包数据交换）格式很有用，SPDX 是一种表示 SBOM 的开放标准。SPDX SBOM 社区目前正在共同确定 SBOM 数据的完整性和签名流程。除此之外，它还启动了其规范化委员会，为 SPDX 3.0 数据编写规范化的序列化格式，这对于阐明如何验证签名文档非常重要。CycloneDX 是另一个 SBOM 的标准，它也在通过其真实性和源头相关用例的特性来解决这个问题。我们相信 SBOM 社区将受益于使用与 SLSA 来源相同的工具和实践：Sigstore（用于基于 OIDC 的临时签名和透明度日志）和 in-toto（用于元数据格式）。这些工具有助于解决存储和分发需要伴随制品元数据文档的问题，并有助于建立用户对 SBOM 的信任。

简洁性

采用 SLSA 理念还可以简化生成 SBOM 所需的工具方面的更新。为所有正在开发的软件启用 SBOM 是一个难题，因为它需要与所有开发软件的工具集成，例如编译器、打包器和构建器。其中许多工具由开源社区中的志愿者维护，他们需要更新工具，不仅要在 SBOM 中描述整个过程，还要检索和传递他们所有输入物料的 SBOM。

然而，使用 SLSA 的方式来跟踪构建元数据意味着工具只需要生成部分 SBOM 来描述它自己的软件开发过程。对于任何特定软件，可以使用 SLSA 构建元数据作为“粘合剂”，将适当部分的 SBOM（“可组合”SBOM）组合成完整且准确的 SBOM。这将减轻构建工具实施者的巨大负担，推动更快地采用 SBOM。