供应链安全SLSA

本文目录导读：

1. 为什么需要 SLSA？
2. SLSA 的四个等级
3. 如何实施 SLSA？

SLSA 的全称是 Supply-chain Levels for Software Artifacts，中文常译为软件制品的供应链安全等级。

它是由 Google 联合开源安全基金会（OpenSSF）等社区共同发起的一套安全框架和可操作的标准，其核心目标是防止软件供应链遭到篡改，并建立对软件源头和构建过程的信任。

SLSA 就像软件供应链的“安全等级认证”，类似于 LEED（能源与环境设计先锋）认证对建筑环保水平的评级，它定义了从低到高的四个等级，等级越高，防篡改能力越强。

为什么需要 SLSA？

近年来,像 SolarWinds 攻击 和 Codecov 事件 等重大安全事件表明，攻击者不再直接攻击最终用户，而是通过入侵软件的开源代码库、CI/CD（持续集成/持续交付）构建系统或包管理器，在源头植入恶意代码，SLSA 就是为了应对这类供应链投毒风险而设计的。

SLSA 的四个等级

SLSA 定义了 4 个等级（L0 - L4），每个等级都增加了一组严格的安全要求。

• L0（最低）：无防护

  • 描述：这是大多数软件的现状，没有任何自动化防护措施，用户只能盲目信任软件来源。
  • 风险：高度依赖手动操作，极易被篡改。

• L1（基础）：构建过程可追溯

  • 要求：
    • 脚本化构建：所有构建步骤都必须通过自动化脚本完成（CI/CD 工具），不能靠人工手动操作编译。
    • 生成出处信息：系统自动生成一个简单的“构建出处”元数据，记录“这个东西是谁、在什么时候、用什么方式构建的”。
  • 价值：解决了“这件事不是我做的”的问题，如果某人声称发布了某个版本，但你没有相应的出处记录，就无法证明其真实性。

• L2（较高）：防篡改的出处 + 托管构建

  • 要求：
    • 在 L1 的基础上，出处信息必须经过数字签名，并且由专有的、可审计的构建平台（如 Google Cloud Build、GitHub Actions、Self-hosted runner 等）生成，而不是在个人电脑上生成。
    • 出处信息不可伪造：攻击者即使入侵了源代码仓库，也无法伪造来自信任构建平台的签名。
    • 构建平台隔离：构建环境是隔离的，每个构建任务互不干扰。
  • 价值：极大地提升了出处的可信度，即使源代码被攻破，攻击者也无法通过构建环境伪造出具有正确签名的构建产物。

• L3（最高）：强抗篡改 + 审计隔离 + 防依赖性混淆

  • 要求：
    • 出处信息不可伪造 (再次强化)：要求使用更严格的身份验证和密钥管理。
    • 可重现构建：对于同一份源代码和构建环境，两次构建的结果应该完全一致（或者可验证一致）。
    • 无权限泄漏：构建过程中使用的密钥、令牌等凭据不能泄漏给构建任务本身。
    • 依赖项的可追溯性：不仅构建产物需要出处，其使用的所有依赖项（包括传递依赖） 也需要有完整的、经过验证的出处信息。
  • 价值：实现了完全的可审计性和依赖性验证，你可以像证明“这个面包是用这个配方、这个烤箱、这个批次的面粉烤出来的”一样证明软件的可信性。

如何实施 SLSA？

1. 评估现状：使用 SLSA 框架评估你当前软件的生产流程，确定初始等级。
2. 自动化构建：将所有构建步骤迁移到 CI/CD 系统中。
3. 集成生成出处信息：使用工具（如 slsa-framework/slsa-github-generator 或 in-toto/attestation）在构建过程中自动生成并签名出处元数据。
4. 部署验证机制：在消费者端（在下载或安装软件时）使用工具验证出处信息的签名和完整性。
5. 逐步提升等级：根据业务需求和风险承受能力，逐步实现 L2 和 L3 的要求。

• SLSA 是一个安全等级框架，不是单一的安全方案。
• 核心是“出处”：它通过可验证的、防篡改的构建出处信息，让你能信任一个软件制品的来源和构建过程。
• 等级越高，越安全：L1 解决“是不是你做的”，L2 解决“是不是你做的且无法抵赖”，L3 解决“是不是完全透明可审计”。
• 当前主流支持程度：L1 和 L2 已经比较成熟，很多 CI/CD 平台（如 GitHub Actions、GitLab CI）都有相应的支持工具，L3 要求较高，目前仅在关键基础设施或高安全场景中普及。

对于大多数组织,实现 SLSA L2 是一个现实且高价值的目标，能显著提升供应链安全，如果你刚开始接触，建议从 L1 开始，逐步向 L2 迈进。