SLSA框架与软件供应链安全防护教学文档

SLSA框架与软件供应链安全防护教学文档 1. SLSA框架概述 SLSA (Supply-chain Levels for Software Artifacts，软件构件的供应链级别)是Google提出的一个端到端框架，旨在确保软件开发和部署过程的安全性，专注于缓解由于篡改源代码、构建平台或构件仓库而产生的威胁。 1.1 背景 随着软件供应链攻击日益增多，Google发布了一系列指南来确保软件包的完整性 框架源于Google的BAB (Binary Authorization for Borg)系统，该系统已使用8年多 对所有Google生产工作负载都是强制性的 1.2 核心原则 非单边原则 ：未经至少一个其他"受信任的人"的明确审查和批准，任何人都无法修改软件供应链中任何地方的软件工件 目的：预防或尽早发现风险 可审计原则 ：软件构件足够安全透明，来源与依赖项可溯源 目的：支持自动分析来源和依赖关系以及特定调查 2. 软件供应链流程 软件供应链是创建和发布软件构件的一系列步骤，主要包含以下流程关系： 源代码 ：软件开发的起点 构建 ：将源代码转换为可执行构件的过程 依赖项 ：软件所依赖的外部库和组件 包 ：最终发布的软件产品 每个环节都可以托管在特定平台上： 源代码管理(SCM)平台 持续集成/持续部署(CI/CD)平台 3. SLSA安全级别 SLSA定义了4个递增的安全级别，级别越高，安全控制越强，攻击者越难破坏代码： 3.1 SLSA 1 要求构建过程完全脚本化/自动化 生成出处(provenance)信息 3.2 SLSA 2 要求使用版本控制 使用托管生成服务 生成经过身份验证的出处 3.3 SLSA 3 要求源代码和构建平台符合特定标准 保证源代码的可审计性 确保来源的完整性 3.4 SLSA 4 要求对所有更改进行两人审查 采用封闭的、可重现的构建过程 最高级别的安全保障 4. 软件供应链风险分析 根据CI/CD流程，风险可分为三个阶段： 4.1 代码阶段风险 提交恶意代码 ：将易受攻击的代码上传到公司的源代码管理系统 攻陷源代码管理系统 ：可能导致代码、机密和用户信息泄露 使用恶意依赖项 ：可能导致未经授权访问管道或代码泄露 4.2 构建阶段风险 使用恶意代码 ：在流程外注入错误代码并触发构建 攻陷构建平台 ：操纵构建过程及其输出 已泄露的依赖项 ：利用漏洞获取访问权限或操作构建服务器 4.3 分发阶段风险 绕过CI/CD ：将恶意构件直接上传到Artifactory 使用恶意包 ：改变系统流程，上传/替换/窃取构件 5. 保护软件供应链的策略 5.1 全面安全策略 考虑工具、源代码、流程、构建和分发各阶段的风险 实施强大的安全防护策略强化流水线安全状况 使攻击者难以破坏基础架构、流程或代码 5.2 历史教训 微软、Rapid7、Monday.com、Codecov、SolarWinds等知名企业曾遭受供应链攻击 这些攻击大多源于CI/CD流水线上薄弱的安全措施 5.3 关键措施 对开发环境实施更严格的安全防护 采用SLSA框架下的全面安全策略 提供对CI/CD流水线的端到端可见性和控制 将安全措施作为流水线的一部分进行集成 6. 实施建议 评估当前状态 ：确定组织当前的SLSA级别 制定升级计划 ：规划如何逐步提升安全级别 自动化构建 ：实现完全脚本化/自动化的构建过程 出处生成 ：建立出处生成和验证机制 双人审查 ：对关键更改实施双人审查制度 封闭构建 ：实现可重现的封闭构建环境 持续监控 ：建立供应链活动的持续监控机制 通过实施SLSA框架，组织可以显著提高软件供应链的安全性，降低遭受供应链攻击的风险。