随着软件供应链攻打浪潮愈演愈烈，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 流水线流程
软件供应链是创立和公布软件构件的一系列步骤。上图展现了源代码、构建、依赖项和包的流程关系。而每个源代码、构建和软件包都能够托管在一个平台上，例如源代码治理（Source Code Management）或继续集成 / 继续部署（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-frame…