随着软件供应链攻击浪潮愈演愈烈，Google 发布了一系列指南来确保软件包的完整性，旨在防止影响软件供应链的未经授权的代码修改。新的 Google SLSA 框架（Supply-chain Levels for Software Artifacts 软件构件的供应链级别）通过识别 CI/CD 流水线中的问题并减小影响，为企业实现更安全的软件开发和部署流程提供建议。
Google 的 SLSA 框架
SLSA 是一个端到端框架，旨在确保软件开发和部署过程的安全性，专注于缓解由于篡改源代码、构建平台或构件仓库而产生的威胁。这些要求源于 Google 的 BAB （Binary Authorization for Borg），该授权已经使用了 8 年多，并且对于 Google 的所有生产工作负载都是强制性的。
SLSA 侧重于以下两个主要原则，即所有软件工件都应当：
-
非单边： 未经至少一个其他“受信任的人”的明确审查和批准，任何人都无法修改软件供应链中任何地方的软件工件。目的是预防或尽早发现风险。
-
可审计： 软件构件足够安全透明，来源与依赖项可溯源。主要目的是自动分析来源和依赖关系以及一些特定调查。
虽然无法做到万无一失，但这两个原则可以帮助企业有效避免和缓解各种篡改和其他供应链攻击带来的风险和影响。
CI/CD 流水线流程
SLSA 框架下的 4 个安全级别
安全级别越高，实施的安全控制越强，攻击者越难破坏代码：
-
SLSA 1： 要求构建过程完全脚本化/自动化并生成出处
-
SLSA 2： 要求使用版本控制和托管生成服务来生成身份验证的出处
-
SLSA 3： 要求源和构建平台符合特定标准，以保证源的可审计性和来源的完整性
-
SLSA 4： 要求对所有更改进行两人审查，并采用封闭的、可重现的构建过程
将供应链保护提升到新的水平
Google 的 SLSA 框架是朝着提高认识和建立标准的正确方向迈出的一步，这些标准将帮助企业控制供应链风险。根据 CI/CD 流程（上图）和 SLSA 建议，我们可以将风险定义为以下三个阶段：
代码阶段风险：
-
提交恶意代码 – 将易受攻击的代码上传到公司的源代码管理系统，其中可能包含漏洞或受损的代码包。
-
攻陷源代码管理系统 – 源代码管理系统中的错误配置或漏洞，可能导致代码、机密和用户信息泄露和被盗。
-
使用恶意依赖项 – 可能允许未经授权访问管道或导致暴露/泄漏代码。
构建阶段风险：
-
使用恶意代码 – 注入错误代码，并在设定流水线流程之外，未经适当的审查和批准而出发的构建过程。
-
攻陷构建平台 – 利用漏洞或错误的配置来获得对构建服务器的访问权，并操纵构建过程及其输出。
-
已泄露的依赖项 – 利用已泄露或易受攻击的依赖项来获取访问权限或操作构建服务器。
分发阶段风险：
-
绕过 CI/CD – 将恶意构件上传到 Artifactory，绕过 CI/CD 流程，使客户暴露于恶意软件包内。
-
使用恶意包 – 改变系统流程，获得对构件的访问权，以便上传、替换或窃取构件。
保护软件供应链
保护软件开发等复杂和动态的过程免受供应链攻击，需要全面的安全解决策略，该策略需要考虑到在工具，源代码和流程，构建和分发阶段中面临的各种风险。正如 SLSA 指南所强调，实施强大的安全防护策略可强化流水线安全状况，使攻击者难以破坏基础架构、流程或代码。
在过去，我们看到了各类 DevOps 环境中的源代码泄漏，资产受损和漏洞，这是 CI/CD 流水线上薄弱的安全措施导致的直接结果。微软、Rapid7、Monday.com、Codecov、SolarWinds 等知名企业成为针对软件供应链攻击的受害者，在业内和社会引起高度关注。
随着恶意攻击者发现开发环境可以作为一种简单且高度可利用的攻击媒介，企业必须对其开发环境给予更严格的安全防护措施，来阻止恶意的软件供应链攻击。在 SLSA 框架下采用全面的安全策略，提供对 CI/CD 流水线的端到端可见性和控制，并将此作为流水线的一部分进行集成，来实现全方位安全保护。
参考链接：
Supply-chain Levels for Software Artifacts
https://github.com/slsa-framework/slsa
