了解 SLSA 网络安全框架

SLSA 如何帮助防御软件供应链攻击

SLSA 安全框架不仅仅是一组规则，它还是一个标准框架，可以潜在地增强软件工件组件的完整性。该端到端指南充当一组防御措施，逐步防止对构成软件产品的软件包进行篡改或任何类型的未经授权的修改。采用 SLSA 框架可以帮助保护您的软件免受常见威胁 供应链攻击 如下：

PHP 的恶意提交存储库攻击

2021 年 80 月，Nikita Popov 宣布，恶意行为者试图通过创建后门来攻击 PHP 源代码，该后门允许他们未经授权访问代码平台。如果成功，这次攻击将是毁灭性的，因为 PHP 为互联网上大约 XNUMX% 的网站提供支持。幸运的是，这次攻击被及时发现，但这一事件仍然说明了 SLSA 控制措施如何帮助防止未来发生类似的攻击。遵循 SLSA 协议（例如两人审核和两因素身份验证）可以保护源代码平台，并使其成为攻击者更难攻击的目标。

Apple 的恶意编译器漏洞

2015 年，为 Apple 产品构建应用程序的软件开发人员从未经验证的托管平台下载了 Xcode（一种用于 Apple 设备的代码编写工具）版本。名为 XcodeGhost 的 Xcode 版本已感染恶意代码，这些代码被秘密地转移到用它构建的应用程序中。它为多个应用程序创建了后门，逃避了苹果的代码审查流程和应用程序商店中提供的应用程序。 SLSA 框架包含与构建相关的安全协议，这些协议可以防止此类攻击或使其变得更加困难。其中一项措施是密封构建要求，这将迫使开发人员声明他们的所有来源，包括他们使用的构建工具。

上传的恶意工件

1 年 2021 月 XNUMX 日，Codecov 团队发现了影响其 Bash 上传器的攻击，其中包括 Codecov GitHub Action、Codecov CircleCI Orb 和 Codecov Bitrise Step。攻击者通过提取 HMAC 密钥来获得未经授权的访问，该密钥提供对 Codecov 公共自托管 Docker 映像之一的中间层的 Google Cloud Storage 服务帐户的访问权限。该密钥允许他们修改 Bash Uploader，将恶意代码直接上传给最终用户。 SLSA 框架会通过显示工件何时以不同于源存储库中预期形式的方式构建来捕获此操作。

事件流不良依赖性

2018 年，黑客向 npm 发布了恶意包 flatmap-stream，随后将其添加为该平台广泛使用的 event-stream 包的依赖项。添加依赖项后，攻击者通过恶意行为对其进行了更新。由于更新与提交给 GitHub 的代码不匹配，SLSA 框架会捕获攻击并阻止向量。跟踪恶意代码的来源会发现它不是来自 GitHub 或来自正确的构建者。不管怎样，这次袭击本来是可以避免的。

SLSA 网络安全框架的四个安全级别

SLSA 框架是一个增量且可操作的协议。它由四个级别组成，其中第 4 级代表安全系统的理想最终状态。最高级别的文物满足所有要求，让消费者相信它没有被以任何方式篡改，并且其所有组件都可以追溯到其来源。较低级别的工件也已经实现了增量里程碑，并根据其等级提供了特定的完整性保证。

第 1 级——奠定基础

您可以将 SLSA 框架的第 1 级视为创建安全软件的整个框架的基础。在此阶段，采用 SLSA 的开发人员或组织必须做两件事。首先，他们必须完全自动化构建过程。这可以通过不同的方式完成，但自动化构建的传统方法是使用 makefile。 GitHub Actions 也可用于实现相同的结果。

实现 SLSA 1 级的第二部分是生成完整的来源文档。这是显示软件工件是如何构建的元数据。它应该详细说明整个构建过程、所有依赖项以及构建过程中使用的顶级源。

以这种方式编写构建过程脚本并显示软件工件的出处，可以让消费者更轻松地就使用软件产品做出明智的决定。尽管拥有 SLSA 1 验证并不意味着软件得到了完全的防篡改保护，但它可以更轻松地识别软件的组件。这是管理漏洞的第一阶段。

2 级——确保您的构建过程是防篡改的

SLSA 框架的第 2 级是您开始采取措施以确保构建过程尽可能防篡改的地方。达到 SLSA 框架的 2 级还可以让消费者对软件的起源更有信心。

同样，这分两步完成，第一步是使用版本控制，第二步涉及使用托管构建服务来验证来源。第一步，使用 GitHub、GitLab 或任何其他类似服务来存储代码并记录对其所做的任何更改。通过这种方式跟踪任何版本更改可以更轻松地理解在构建工件的过程中对工件执行的任何更改。

尽管级别 2 与级别 1 一样需要出处文档，但此处的区别在于软件工件必须由托管构建服务进行身份验证。托管服务充当受信任的第三方，可以确认初始来源文档中详细说明的构建过程是准确的。 GitHub Actions 是一种可以提供经过身份验证的来源的托管服务。

 第 3 级 — SLSA 的安全控制

第 3 级是您开始实施 SLSA 框架中突出显示的特定安全控制的地方。要达到此级别，软件工件的源和构建平台必须满足特定标准，以保证源是可审计的并且代码的出处是可信的。 SLSA 3 级提供了更强有力的保证，可以很好地保护工件免受篡改和特定类别的威胁。

3 级的一些具体要求包括：

•     源代码经过验证的历史记录和保留- 源代码验证历史记录可确保对软件源代码所做的任何更改都附有进行更改的作者、审阅者或上传者的经过身份验证的身份以及更改的特定时间戳。此更改历史记录还必须保存至少 18 个月。
•   短暂环境中的隔离构建- 为了满足此要求，软件构建必须在完全独立于任何其他构建实例的临时环境中实现。您可以使用 GitHub Actions 等服务来实现这一目标，该服务使用虚拟构建机来按需生成构建。
•     构建为代码—这些标准要求您像对待代码一样对待构建文件。这意味着它们将存储在版本控制系统中，以便在必要时重新创建构建过程。
•     不可证伪的出处—此要求的目的是防止用户篡改构建服务生成的出处文档。

4 级——消费者信心

SLSA 框架的第 4 级旨在确保软件不被以任何方式篡改。只有满足以下要求的软件工件才能达到该框架的第 4 级：

两人审查所有变更

该标准要求组织指派两名合格的审核员来彻底审核对软件代码和组件提出的任何更改。这种两人审核流程确保只有受信任且经过身份验证的开发人员才能对软件工件进行更改。

密封且可重复的构建过程

当所有输入都在构建过程之外预先指定时，构建过程被称为密封过程。此规则适用于源代码以及构建中使用的所有编译器、库和工具。这有助于保证所有第三方进口的完整性。可重复构建标准不是强制性要求，但也是推荐性要求。该标准要求构建过程无论何时何地运行都产生相同的输出。

满足 SLSA 级别的技术要求

SLSA框架对于不同级别都有特定的技术要求。这些要求分为五个主要类别：源要求、构建过程要求、通用要求、出处内容要求和出处生成要求。下面突出显示了每个要求类别。

来源要求

这是指旨在确保源代码完整性的要求。遵循这些协议集可以防止对您的代码进行篡改和恶意更改。它还确保任何邪恶行为都不会被忽视。下表列出了源要求。

构建要求

SLSA 框架强调了构建要求，旨在提高构建平台的安全性并保持构建过程的完整性。

出处生成要求

这些要求旨在验证软件资产所有组件的来源。下表突出显示了出处生成要求。

出处内容要求

出处内容要求验证构建过程中使用的所有工件、依赖项和构建限制的身份和来源。它们在下表中突出显示。

共同要求

通用要求适用于 SLSA 4 级的软件工件。每个受信任的工件都应满足这些要求。它们包括基线安全要求和详细说明所有物理和远程访问的日志。通用要求还规定了少数平台管理员可以覆盖 SLSA 文档中的规定。