SLSA软件供应链完整性框架

SLSA：Supply-chain Levels for Software Artifacts （软件产品的供应链级别）是一个端到端的框架，用于确保整个软件供应链中的软件工件的完整性。这些框架的灵感来自于 Google 内部的 "Binary Authorization for Borg"，Google 在过去 8 年多的时间里一直在使用，并且是 Google 所有生产工作负载的强制性检查器。

重要提示：SLSA 是一个不断发展的规范，我们正在通过 GitHub issues、电子邮件或反馈表寻找广泛的反馈。

概述

SLSA 包括：

1. 标准：（本文档）业界对“安全”软件供应链定义的共识。可能有多种标准来表示安全的多个方面。
2. 认证：组织证明符合这些标准的过程。
3. 技术控制：记录出处并检测或防止违规。

最终，软件消费者决定信任谁以及执行什么标准。有鉴于此，认证是一种跨组织边界传递信任的手段。例如，一家公司可能会在内部“认可”其内部源和构建系统，同时依靠 OpenSSF 来认可第三方。其他组织可能信任其他认证机构。

本文件只讨论第一部分，标准。我们希望随着时间的推移制定认证流程和技术控制。在此期间，这些级别可以作为指导如何保护软件供应链提供价值。

原则

SLSA 侧重于以下两个主要原则：

• 非单方面：任何人都不能修改软件供应链中任何地方的软件工件，除非经过至少一个其他“受信任的人”的明确审查和批准。目的是预防、威慑和/或早期发现风险的变化。

• 可审计：软件工件可以安全透明地追溯来源和依赖项。主要目的是自动分析来源和依赖关系，以及临时调查。

尽管并不完美，但这两个原则为广泛的篡改、混淆和其他供应链攻击提供了实质性的缓解。

为了根据上述两个原则衡量供应链的保护程度，我们提出了 SLSA 级别。更高的级别意味着它得到更好的保护。SLSA 4 是最终目标，但对于大型组织而言可能需要多年时间和大量投资。