目录导航
随着软件供应链攻击在SolarWinds和Codecov安全事件之后成为一个关注点，谷歌提出了一种解决方案，以确保软件包的完整性并防止未经授权的修改。
所谓的“供应链各级软件制品”（SLSA，发音为““salsa”），终端到终端的框架旨在确保软件开发和部署流水线-即源➞构建➞发布工作流程-和减轻威胁说由于在链中的每个环节篡改了源代码、构建平台和工件存储库。
谷歌表示，SLSA 的灵感来自公司自己的内部执行机制，称为Borg 的二进制授权，这是一套审计工具，用于验证代码出处并实施代码身份，以确定部署的生产软件是否经过适当审查和授权。
“在当前状态下，SLSA是业内人士的共识正在建立一套增量可采用安全准则，”谷歌开源安全团队的金莱万多夫斯基和二进制授权博格队的马克Lodato说。
SLSA 原则
SLSA 侧重于以下两个主要原则：
- 非单方面：任何人都不能修改软件供应链中任何地方的软件工件，除非经过至少一个其他“受信任的人”的明确审查和批准。[^1] 目的是预防、威慑和/或早期发现风险/坏的变化。
- 可审计：软件工件可以安全透明地追溯到原始的、人类可读的来源和依赖项。主要目的是自动分析来源和依赖关系，以及临时调查。
尽管并不完美，但这两个原则为广泛的篡改、混淆和其他供应链攻击提供了实质性的缓解。
为了根据上述两个原则衡量供应链的保护程度，我们提出了 SLSA 级别。更高的级别意味着它得到更好的保护。SLSA 4 是最终目标，但对于大型组织而言可能需要多年时间和大量投资。SLSA 1 到 SLSA 3 是识别有意义的进步的垫脚石。
SLSA 4 与简单的最佳实践的不同之处在于它对坚定的对手的弹性。也就是说，SLSA 是遵循这些实践的保证，但仍不能保证软件是“安全的”。
背景
为什么我们需要 SLSA？
SLSA 解决了三个问题：
- 软件生产商想要保护他们的供应链，但不知道具体如何。
- 软件消费者希望了解并限制他们遭受供应链攻击的风险，但没有办法这样做。
- 单独的工件签名只能防止我们关心的攻击的一个子集。
至少，SLSA 可以用作软件生产者和消费者的一套指导原则。更重要的是，SLSA 允许我们以通用语言谈论供应链风险和缓解措施。这使我们能够跨组织边界沟通和应对这些风险。
数字级别尤其有用，因为它们很简单。决策者在不了解任何细节的情况下很容易理解 SLSA 4 优于 SLSA 3。也就是说，我们不致力于数字级别，并且对其他选项持开放态度。
SLSA 完成后，它将提供从供应链可以实施的要求到他们可以防止的攻击的映射。软件生产者和消费者将能够查看软件工件的 SLSA 级别，并了解在其生产过程中防御了哪些攻击。
软件供应链威胁例子:
| 威胁 | 已知例子 | SLSA 如何提供帮助 | |
| A | 向源代码库提交错误代码 | Linux 伪君子提交：研究人员试图通过邮件列表上的补丁故意将漏洞引入 Linux 内核。 | 两人审查发现了大部分（但不是全部）漏洞。 |
| B | 妥协的源代码控制平台 | PHP：攻击者破坏了 PHP 的自托管 git 服务器并注入了两次恶意提交。 | 受到更好保护的源代码平台将成为攻击者更难的目标。 |
| C | 使用官方流程构建，但代码与源代码管理不匹配 | Webmin：攻击者修改了构建基础结构以使用与源代码控制不匹配的源文件。 | 符合 SLSA 的构建服务器会产生出处，识别使用的实际来源，允许消费者检测此类篡改。 |
| D | 妥协构建平台 | SolarWinds：攻击者破坏了构建平台并安装了一个植入程序，在每次构建期间注入恶意行为。 | 更高的 SLSA 级别需要对构建平台进行更强的安全控制，从而更难以妥协和获得持久性。 |
| E | 使用不良依赖（即 AH，递归） | event-stream：攻击者添加了一个无害的依赖项，然后更新该依赖项以添加恶意行为。更新与提交到 GitHub 的代码不匹配（即攻击 F）。 | 将 SLSA 递归应用于所有依赖项会阻止这个特定的向量，因为出处会表明它不是从合适的构建器构建的，或者源不是来自 GitHub。 |
| F | 上传不是由 CI/CD 系统构建的工件 | CodeCov：攻击者使用泄露的凭据将恶意工件上传到 GCS 存储桶，用户直接从中下载。 | GCS 存储桶中工件的出处表明该工件不是以预期的源存储库中的预期方式构建的。 |
| G | 妥协包存储库 | 对包镜像的攻击：研究人员为几个流行的包存储库运行镜像，这些库可能被用来为恶意包提供服务。 | 与上述 (F) 类似，恶意工件的出处表明它们不是按预期构建的，也不是从预期的源代码库构建的。 |
| H | 欺骗消费者使用坏包 | Browserify 域名抢注：攻击者上传了一个与原始名称相似的恶意包。 | SLSA 不直接解决此威胁，但源头链接回源控制可以启用和增强其他解决方案。 |
“在其最终形式中，SLSA 在其可执行性方面将不同于最佳实践列表：它将支持可审计元数据的自动创建，这些元数据可以输入到策略引擎中，从而为特定包或构建平台提供‘SLSA 认证’。”
SLSA 框架承诺端到端的软件供应链完整性，旨在实现增量和可操作性。它包括四个不同级别的渐进式软件安全复杂性，SLSA 4 提供了对软件没有被不当修改的高度信心。
- SLSA 1 — 要求构建过程完全脚本化/自动化并生成出处
- SLSA 2 — 需要使用版本控制和生成经过身份验证的出处的托管构建服务
- SLSA 3 — 要求源和构建平台满足特定标准，以保证源的可审计性和出处的完整性
- SLSA 4 — 需要两人对所有更改和密封、可重复的构建过程进行审查
“更高的 SLSA 级别需要对构建平台进行更强大的安全控制，这使得妥协和获得持久性变得更加困难，”Lewandowski 和 Lodato 指出。
虽然 SLA 4 代表了理想的最终状态，但较低级别提供增量完整性保证，同时使恶意行为者难以长时间隐藏在受破坏的开发人员环境中。
在宣布的同时，Google 还分享了有关需要满足的Source和Build要求的更多详细信息，并呼吁业界对系统进行标准化并定义威胁模型，详细说明 SLSA 希望长期解决的特定威胁.
该公司表示：“为大多数项目实现最高级别的 SLSA 可能很困难，但较低 SLSA 级别所认可的渐进式改进已经大大有助于提高开源生态系统的安全性。”
什么是 SLSA
在目前的状态下，SLSA 是一组由行业共识建立的渐进式可采用的安全指南。在其最终形式中，SLSA 在其可执行性方面将不同于最佳实践列表：它将支持可审计元数据的自动创建，这些元数据可以输入到策略引擎中，从而为特定包或构建平台提供“SLSA 认证”。SLSA 旨在增量和可操作，并在每一步提供安全优势。一旦工件达到最高级别的资格，消费者就可以确信它没有被篡改，并且可以安全地追溯到源头——这对于当今的大多数软件来说是困难的，如果不是不可能的。
SLSA 由四个级别组成，其中 SLSA 4 代表理想的最终状态。较低级别代表具有相应增量完整性保证的增量里程碑。这些要求目前定义如下。
SLSA 定义
提醒：以下定义尚未最终确定，可能会发生变化，尤其是 SLSA 3-4。
工件的SLSA 级别描述了其直接供应链的完整性强度，即其直接来源和构建步骤。要验证工件是否满足此级别，需要出处。这可作为已满足级别要求的证据。
等级说明
本节是非规范的。
有四个 SLSA 级别。SLSA 4 是当前的最高级别，代表了理想的最终状态。SLSA 1-3 提供较低的安全保证，但更容易满足。根据我们的经验，实现 SLSA 4 可能需要很多年和大量的努力，因此中间里程碑很重要。
SLSA 1要求构建过程完全脚本化/自动化并生成出处。来源是关于如何构建工件的元数据，包括构建过程、顶级源和依赖项。了解来源允许软件消费者做出基于风险的安全决策。虽然 SLSA 1 的出处不能防止篡改，但它提供了基本级别的代码源识别，并可能有助于漏洞管理。
SLSA 2 需要使用版本控制和生成经过身份验证的出处的托管构建服务。这些附加要求使消费者对软件的来源更有信心。在这个级别上，出处可以在构建服务可信的范围内防止篡改。SLSA 2 还提供了到 SLSA 3 的简单升级路径。
SLSA 3进一步要求源和构建平台满足特定标准，以分别保证源的可审计性和出处的完整性。我们设想了一个认证流程，审核员可以通过该流程证明平台符合要求，消费者可以信赖这些要求。SLSA 3 通过防止特定类别的威胁（例如交叉构建污染）提供比早期级别更强大的防篡改保护。
SLSA 4是目前最高级别，需要两个人审查所有更改和密封、可重复的构建过程。两人审核是发现错误和阻止不良行为的行业最佳实践。Hermetic 构建保证出处的依赖项列表是完整的。可重现的构建虽然不是严格要求的，但提供了许多可审计性和可靠性的好处。总体而言，SLSA 4 使消费者高度确信该软件未被篡改。
| 等级 | 意义 |
|---|---|
| SLSA 4 | “可审计且非单方面的。” 高度自信 (1) 可以正确且轻松地追溯到原始源代码、其更改历史记录和所有依赖项，以及 (2) 没有任何人有权在未经审查的情况下对软件进行有意义的更改。 |
| SLSA 3 | “可审计。” 对可以追溯到原始源代码并更改历史记录的信心中等。但是，受信任的人仍然可以进行单方面更改，并且依赖列表可能不完整。 |
| SLSA 2 | 迈向更高层次的垫脚石。中等可信度，可以确定谁授权了该工件或哪个系统生成了该工件。构建后防止篡改。 |
| SLSA 1 | 进入 SLSA 的入口点。出处表明工件的来源，没有任何完整性保证。 |
SLSA等级要求
| 在下列的需求 | |||||
|---|---|---|---|---|---|
| 要求 | SLSA 1 | SLSA 2 | SLSA 3 | SLSA 4 | |
| 来源 | 版本控制 | ✓ | ✓ | ✓ | |
| 验证历史 | ✓ | ✓ | |||
| 无限期保留 | 18 个月 | ✓ | |||
| 两人审阅 | ✓ | ||||
| 建造 | 脚本化 | ✓ | ✓ | ✓ | ✓ |
| 构建服务 | ✓ | ✓ | ✓ | ||
| 临时环境 | ✓ | ✓ | |||
| 隔离 | ✓ | ✓ | |||
| 无参数 | ✓ | ||||
| 密闭 | ✓ | ||||
| 可重现 | ○ | ||||
| 出处 | 可用的 | ✓ | ✓ | ✓ | ✓ |
| 已认证 | ✓ | ✓ | ✓ | ||
| 服务产生 | ✓ | ✓ | ✓ | ||
| 不可证伪 | ✓ | ✓ | |||
| 依赖完成 | ✓ | ||||
| 常见的 | 安全 | ✓ | |||
| 访问 | ✓ | ||||
| 超级用户 | ✓ | ||||
○ = 需要，除非有正当理由
以下是总结。有关详细信息，请参阅相应的 Source、Build/Provenance和Common 文档。
[Source]工件顶级源的要求，即包含构建脚本的源：
- [版本控制]在版本控制系统中跟踪对源的每个更改，该系统标识更改的人员、更改内容以及更改发生的时间。
- [已验证历史] 历史中的每个更改都至少有一个经过强认证的演员身份（作者、上传者、评论者等）和时间戳。
- [无限期保留]工件及其更改历史无限期保留，无法删除。
- 【两人回顾】历史上的每一次变化，至少有两个可信赖的人同意。
[构建]工件构建过程的要求：
- [脚本化]所有构建步骤都在某种“构建脚本”中完全定义。唯一的手动命令（如果有的话）是调用构建脚本。
- [构建服务]所有构建步骤都使用某些构建服务（例如持续集成 (CI) 平台）运行，而不是在开发人员的工作站上运行。
- [临时环境]构建步骤在临时环境（例如容器或 VM）中运行，仅为此构建配置，而不是从先前构建中重用。
- [隔离]构建步骤在一个独立的环境中运行，不受其他构建实例的影响，无论是先前的还是并发的。构建缓存（如果使用）纯粹是内容可寻址的，以防止篡改。
- [无参数]构建输出不受构建入口点和顶级源位置以外的用户参数影响。
- [Hermetic]所有构建步骤、源代码和依赖项都预先使用不可变引用完全声明，并且构建步骤在没有网络访问的情况下运行。所有依赖项都由构建服务控制平面获取并检查完整性。
- [可重现]使用相同的输入工件重新运行构建步骤会导致逐位相同的输出。（无法满足此要求的构建必须提供理由。）
【出处】工件出处要求：
- [可用]来源对工件的消费者或验证策略的任何人可用，并且它至少标识工件、执行构建的系统和顶级源。所有工件引用都是不可变的，例如通过加密哈希。
- [已认证]可以验证出处的真实性和完整性，例如通过数字签名。
- [服务生成] Provenance 由构建服务本身生成，而不是由用户提供的工具在服务之上运行。
- [不可篡改]出处不能被构建服务的用户篡改。
- [Dependencies Complete] Provenance 记录了所有构建依赖项，这意味着构建脚本可用的每个工件。这包括构建工作者的机器、VM 或容器的初始状态。
[通用]供应链（来源、构建、分发等）中涉及的每个可信系统的通用要求：
- [安全]系统满足一些待定的基线安全标准，以防止妥协。（修补、漏洞扫描、用户隔离、传输安全、安全启动、机器身份等。也许是 NIST 800-53 或其子集。）
- [访问]所有物理和远程访问都必须在多方批准后进行罕见、记录和门控。
- [超级用户]只有少数平台管理员可以覆盖此处列出的保证。这样做必须需要第二个平台管理员的批准。
slsa项目地址
GitHub:https://github.com/slsa-framework/slsa
slsa下载地址:
slsa-framework/v2021-04-21.zip
总结
SLSA 是一种用于端到端软件供应链完整性的实用框架，它基于在世界上最大的软件工程组织之一中被证明可以大规模工作的模型。为大多数项目实现最高级别的 SLSA 可能很困难，但较低 SLSA 级别所认可的渐进式改进已经对提高开源生态系统的安全性大有帮助。
当我们开始在我们自己的开源项目中采用 SLSA 时，我们期待与社区合作改进级别。如果你是一个项目的维护者和兴趣尝试采用和SLSA提供反馈，请伸出或前来捧场的讨论发生在OpenSSF数字身份认证工作组。