MGI 谷歌开发者介绍 “SLSA” （软件工件的供应链级别），其目的是照顾 保护发展基础设施 在产品的编码、测试、构建和分发阶段进行的攻击。
开发者 提到开发过程越来越复杂并且依赖于第三方工具，这为促进与识别和利用最终产品中的漏洞相关的攻击创造了有利条件，但与开发过程本身的承诺有关。
关于SLSA
提到SLSA关注以下两个基本原则：
不是单方面的——任何人都不得在软件供应链的任何地方修改软件工件，除非得到至少一个其他“受信任的人”的明确审查和批准。 [^ 1] 目的是预防、威慑或及早发现风险/不良变化。
可审计 - 软件工件可以安全透明地追溯到原始的、人类可读的来源和依赖项。 主要目的是自动化源和依赖性分析，以及临时调查。
要阻止标记的威胁， SLSA 提供了一组指南和工具来自动创建元数据以进行审计. SLSA 总结了常见的攻击方法并引入了保护层的概念。
每一层都有特定的基础设施要求，以确保开发中使用的工件的完整性，即， 支持的 SLSA 级别越高，实施的防御就越多 基础设施将得到更好的保护，免受典型攻击。
SLSA 级别 1
在这个层面上 要求构建过程完全自动化并生成元数据 （“来源”）关于如何收集工件，包括源、依赖项和构建过程信息（为 GitHub 操作提供了用于审计的示例元数据生成器）。 SLSA 1 不包括防止恶意更改的元素它仅以最简单的方式识别代码，并为漏洞管理和风险分析提供元数据。
SLSA 级别 2
在这里，第一层通过要求使用源控制系统并构建生成经过身份验证的元数据的服务进行了扩展。 指某东西的用途 SLSA 2 允许您跟踪代码的来源并防止未经授权的更改 在您的代码中，在使用可靠组装服务的情况下。
SLSA 级别 3
从这点来说或确认源代码和构建平台符合标准要求 以确保可以审核代码并保证所提供元数据的完整性。 审核员应该能够证明平台符合标准的要求。
SLSA 级别 4
这是最高级别，它也通过添加更严格的要求来补充之前的级别，其中要求由两个不同的开发人员强制审查所有更改，以及所有编译步骤、代码和依赖项。它们必须是完全声明，所有依赖项必须单独检出和检查，构建过程必须离线完成。
使用可重复的编译过程还提供了重复编译过程并确保从提供的源编译可执行文件的能力。
除了它 该框架考虑了 8 种攻击类型 与产品代码开发、编译、测试和分发阶段恶意更改的威胁有关。
考虑的攻击类型 分别是：
1.- 包含导致漏洞的后门或潜在错误的更改包含在源代码中。
2.- 对源代码控制平台的承诺。
3.- 在代码传输阶段对编译或持续集成系统进行更改（收集与存储库代码不对应的代码）。
4.- 建设平台的承诺
5.- 通过低质量的依赖来推广恶意代码。
6.- 加载未在 CI/CD 系统中生成的工件。
7.- 包存储库的妥协。
8.- 用户混淆安装错误的包。
最后 如果您想了解更多，您可以查看详细信息 在下面的链接中。