谷歌推出了 SLSA（软件工件供应链级别）框架，该框架总结了保护开发基础设施免受编写代码、测试、组装和分发产品阶段进行的攻击的现有经验。
开发过程变得越来越复杂并依赖于第三方工具，这为攻击的进展创造了有利条件，这些攻击不是与识别和利用最终产品中的漏洞相关，而是与损害开发过程本身有关（供应链攻击，通常针对在编写代码的过程中引入恶意更改、分布式组件和依赖项的替换）。
该框架考虑了与在产品的代码开发、组装、测试和分发阶段进行恶意更改的威胁相关的 8 种攻击类型。
- A. 包括对源代码的更改，这些更改包含后门或导致漏洞的隐藏错误。
攻击示例：“Hypocrite Commits”——尝试将带有漏洞的补丁推广到 Linux 内核中。
建议的安全方法：由两名开发人员对每个更改进行独立审查。
- B. 源代码控制平台的妥协。
攻击示例：在开发人员密码泄露后，将带有后门的恶意提交注入到 PHP 项目的 Git 存储库中。
建议的保护方法：提高代码管理平台的安全性（以 PHP 为例，攻击是通过很少使用的 HTTPS 接口进行的，该接口允许在使用密码登录时发送更改，而无需检查 SSH 密钥，尽管事实上，不可靠的 MD5 用于散列密码）。
- C. 在将代码传输到构建或持续集成系统的阶段进行更改（构建与存储库中的代码不匹配的代码）。
攻击示例：通过更改构建基础架构将后门注入 Webmin，导致使用与存储库中的文件不同的代码文件。
建议的保护方法：检查完整性并识别汇编服务器上代码的来源。
- D. 组装平台的妥协。
攻击示例：SolarWinds 攻击，在该攻击期间，确保在组装阶段将后门安装到 SolarWinds Orion 产品中。
建议的保护方法：对装配平台实施先进的安全措施。
- E. 通过低质量依赖项推广恶意代码。
攻击示例：通过添加无害的依赖项，然后在该依赖项的更新之一中包含恶意代码，将后门引入流行的事件流库中（恶意更改并未反映在 git 存储库中，但仅存在于完成的 MNP 包中）。
建议的保护方法：将 SLSA 要求递归地应用于所有依赖项（在事件流的情况下，检查将显示与主 Git 存储库的内容不对应的代码汇编）。
- F. 上传不是在 CI/CD 系统中创建的工件。
攻击示例：在 CodeCov 脚本中添加恶意代码，使攻击者能够提取存储在客户持续集成系统环境中的信息。
建议的保护方法：控制工件的来源和完整性（就 CodeCov 而言，可能会发现从 codecov.io 网站发送的 Bash Uploader 脚本与项目存储库中的代码不对应）。
- G. 软件包存储库受到损害。
攻击示例：研究人员能够部署一些流行软件包存储库的镜像，以便通过它们分发恶意软件包。
建议的保护方法：验证分布式工件是否是根据声明的源代码编译的。
- H. 迷惑用户安装错误的软件包。
攻击示例：使用拼写错误（NPM、RubyGems、PyPI）将包放置在与流行应用程序编写类似的存储库中（例如，coffe-script 而不是 Coffee-script）。
为了阻止标记的威胁，SLSA 提供了一组建议以及用于自动创建审核元数据的工具。 SLSA总结了常见的攻击方法并引入了安全层的概念。 每个级别都有一定的基础设施要求，以确保开发中使用的工件的完整性。 支持的 SLSA 级别越高，实施的保护越多，基础设施免受常见攻击的保护也越好。
- SLSA 1 要求构建过程完全自动化，并生成有关如何构建工件的元数据（“来源”），包括有关源、依赖项和构建过程的信息（为 GitHub Actions 提供了用于审核的示例元数据生成器）。 SLSA 1 不包括防止恶意修改的元素，而只是识别代码并提供用于漏洞管理和风险分析的元数据。
- SLSA 2 - 通过要求使用生成经过身份验证的元数据的版本控制和组装服务来扩展第一级。 使用 SLSA 2 可以让您追踪代码的来源，并在可信构建服务的情况下防止对代码进行未经授权的更改。
- SLSA 3 - 确认源代码和构建平台满足标准要求，保证审计代码的能力并确保所提供元数据的完整性。 假设审核员可以根据标准的要求对平台进行认证。
- SLSA 4 是最高级别，对之前的级别进行了以下要求的补充：
- 由两个不同的开发人员强制审查所有更改。
- 所有构建步骤、代码和依赖项都必须完整声明，所有依赖项必须单独提取和验证，并且构建过程必须离线执行。
- 使用可重复的构建过程允许您自己重复构建过程，并确保可执行文件是根据提供的源代码构建的。
来源： opennet.ru