SLSA （Supply-chain Levels for Software Artifacts，软件工件的供应链级别）是一套可逐步采用的供应链安全指南，由行业共识制定。SLSA 制定的规范对软件生产商和消费者都有用：生产商可以遵循 SLSA 的指南来提高其软件供应链的安全性，消费者可以使用 SLSA 来决定是否信任软件包。
当前版本为1.0，由Linux基金会维护，网址：https://slsa.dev/
本文共分三部分，包括供应链安全威胁全景图，威胁用例及消减方法，安全级别定义。
供应链威胁全景图
所有的安全分析都从威胁开始。SASL定义的威胁全景如图一
图一
这个图缺少运行态的内容，Google在这个基础上有增加，如图二
图二
其中，数字的标识，是SASL不包含的。
在Google图的基础上，我做了一个翻译版，如图三，如果需要可编辑版请私信。
图三
SASL威胁用例及消减方法
SASL的用例及消减方法（注，编号以图一为准）
编号 | 威胁内容 | 已知例子 | SLSA 消减方法 |
A | 提交未经授权的变更（至源代码库） | SushiSwap：拥有存储库访问权限的承包商推送了恶意提交，将加密货币重定向到他们自己。 | 两人的审查就能发现未经授权的更改。 |
B | 入侵源代码仓库 | PHP：攻击者入侵了 PHP 自托管的 git 服务器并注入了两个恶意提交。 | 受到更好保护的源代码平台对于攻击者来说将是一个更难攻击的目标。 |
C | 从修改后的源构建（不匹配源代码库） | Webmin：攻击者修改了构建基础结构以使用与源代码控制不匹配的源文件。 | 符合 SLSA 的构建服务器将生成可识别实际使用来源的出处，从而让消费者能够检测到此类篡改。 |
D | 使用被破坏的依赖关系（即 AH，递归） | event-stream：攻击者添加了一个无害的依赖项，然后稍后更新该依赖项以添加恶意行为。该更新与提交到 GitHub 的代码不匹配（即攻击 F）。 | 将 SLSA 递归应用于所有依赖项将会阻止这个特定的向量，因为出处会表明它不是由适当的构建器构建的，或者源不是来自 GitHub。 |
E | 破坏构建过程 | SolarWinds：攻击者破坏了构建平台并安装了植入物，该植入物会在每次构建期间注入恶意行为。 | 更高的 SLSA 级别需要对构建平台进行更强的安全控制，从而更难以受到攻击并获得持久性。 |
F | 上传修改后的包（与构建过程不匹配） | CodeCov：攻击者使用泄露的凭证将恶意文件上传到 GCS 存储桶，用户直接从中下载。 | GCS 存储桶中的工件出处表明该工件不是按照预期的方式从预期的源存储库构建的。 |
G | 破坏软件包注册表 | 对软件包镜像的攻击：研究人员运行了几个流行软件包注册中心的镜像，这些镜像可能被用来提供恶意软件包。 | 与上述（F）类似，恶意工件的来源表明它们不是按照预期构建的，也不是来自预期的源代码库。 |
H | 使用受损的软件包 | Browserify 域名抢注：攻击者上传了一个与原始名称相似的恶意软件包。 | SLSA 并不直接解决这一威胁，但追溯回源代码控制的出处可以启用和增强其他解决方案。 |
SLSA的级别定义
SLSA 要求分为四个级别，有助于供应链安全。这些级别可帮助您定义要实现的安全态势。没有保证的系统被视为 0 级：
级别 1：构建流程文档——构建工件的所有流程都必须完整记录，并包括详细说明来源和依赖关系（出处）的元数据。消费者使用这些信息来评估安全风险并做出决策。
级别 2：防篡改— 需要版本控制和托管构建服务来生成出处，让消费者对软件来源更有信心。构建服务的信任级别决定了篡改预防。
级别 3：针对某些威胁的额外保护— 构建和源平台符合标准，可进行审计并确保来源完整性。消费者可以信赖审计员的认证。
级别 4：实现最高的信任和信心级别 —需要两个人审查所有更改。构建过程必须安全（密封）且可重现，确保依赖项列表完整。
END
参考链接：
https://cloud.google.com/software-supply-chain-security/docs/attack-vectors?hl=zh-cn
