共计 3186 个字符，预计需要花费 8 分钟才能阅读完成。
作者：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。
携手单干
随着 SLSA 和 SBOM 被更宽泛地采纳，它们面临着许多雷同的挑战：扩展性、跨多个生态系统能够被宽泛采纳的工具，以及如何恪守行政命令的要求。SLSA 和 SBOM 社区该当联手应答这些独特的挑战，节俭反复的精力和工夫。只有通过共享这些资源和想法能力为两个社区带来更好的解决方案。
SLSA 和 SBOM——无论是社区还是平安概念，相比于独自应用任何一种解决形式或通过繁多社区，协同工作将会更加弱小。咱们很期待看到这两个社区携手单干，以实现更好的破绽治理，为所有软件用户提供更平安的软件供应链。
原文链接：
https://slsa.dev/blog/2022/05…