技术深度解析
SLSA并非单一工具，而是一套规范，定义了一个安全级别的阶梯，每一级都建立在前一级之上。其架构设计简洁优雅：聚焦于三大核心支柱——源代码、构建和来源证明。
- 源代码（L1-L4）： 在L1级别，源代码必须受版本控制（例如Git）。L2要求所有变更需经两人审查。L3要求源代码托管在具有强访问控制和可验证历史的平台上。L4则要求“可验证历史”具有密码学可审计性，意味着每次提交都必须签名并与已知身份关联。
- 构建（L1-L4）： L1要求存在构建脚本。L2要求构建在专用、临时的环境中运行。L3引入了“密封构建”——构建过程不得依赖任何外部网络资源，以确保可复现性。L4要求“隔离构建”，即构建环境完全气隙隔离，且构建过程完全确定。
- 来源证明（L1-L4）： 这是最关键的组件。来源证明是一份经过加密签名的证明，描述了制品的构建方式及其来源。L1要求一份简单的来源证明文档。L2要求来源证明由构建平台本身生成（而非开发者）。L3要求不可伪造的来源证明——签名密钥必须存储在硬件安全模块（HSM）或等效设备中。L4要求来源证明包含“可复现构建”验证，即任何人都可以重新构建该制品并获得相同的哈希值。
SLSA的工程基础是in-toto证明框架。in-toto提供了一种标准化格式（ITTE），用于描述软件供应链中的各个步骤。Sigstore项目则提供了密码学基础设施——通过OIDC实现的无密钥签名、透明度日志（Rekor）和证书颁发机构（Fulcio）。它们共同构成了常被称为“SLSA技术栈”的体系。
面向实践者的关键GitHub仓库：
- slsa-framework/slsa (⭐1868)：规范本身，包含详细的威胁模型和实施指南。
- slsa-framework/slsa-github-generator (⭐1.5k+)：一个GitHub Actions工作流，可为Go、Node.js等语言生成符合SLSA标准的来源证明。它利用Sigstore自动创建签名证明。
- in-toto/in-toto (⭐1.8k+)：in-toto框架的参考实现。它提供了用于创建和验证证明的Python库。
- sigstore/cosign (⭐4.5k+)：用于对容器镜像和二进制文件进行签名和验证的命令行工具，在SLSA工作流中广泛使用。
- sigstore/rekor (⭐1.2k+)：记录所有签名事件的透明度日志，提供不可篡改的审计追踪。
基准数据：SLSA实施复杂度
| SLSA级别 | 关键要求 | 典型实施时间 | 所需基础设施变更 | 验证开销（每次构建） |
|---|---|---|---|---|
| L1 | 版本控制 + 构建脚本 | 1-2天 | 无 | <1秒 |
| L2 | 临时构建 + 签名来源证明 | 1-2周 | CI/CD流水线修改（例如GitHub Actions） | 1-5秒 |
| L3 | 密封构建 + 不可伪造来源证明 | 1-3个月 | HSM集成、构建网络隔离 | 5-15秒 |
| L4 | 隔离构建 + 可复现构建 | 6-12个月以上 | 完全气隙构建农场、确定性构建工具链 | 30秒以上 |
数据要点： 从L2到L3的跃升，意味着实施时间和基础设施复杂度增加了10倍。大多数组织可以在数周内实现L2，但L3需要一个专门的安全工程团队，并在硬件支持的签名基础设施上进行重大投资。
关键参与方与案例研究
SLSA生态系统并非由单一供应商主导，而是由开源项目、云服务提供商和安全初创公司组成的联盟。
Google 仍然是SLSA背后的主要智力驱动者。该框架最初由Google安全团队开发，由Kim Lewandowski和Mark Lodato等研究人员领导。Google已在其内部关键基础设施（包括Kubernetes发布流程）中实施了SLSA L4。Kubernetes项目本身就是一个旗舰案例：其发布制品现在使用Sigstore签名，并对照SLSA L3来源证明进行验证，为其他大型开源项目提供了典范。
GitHub 是CI/CD平台中最积极的采用者。由SLSA社区维护但深度集成GitHub OIDC提供商的`slsa-github-generator`操作，使得任何仓库都能轻松实现SLSA L2。GitHub于2024年推出的自有制品证明功能，正是基于SLSA原则构建的。
GitLab 也已将SLSA集成到其CI/CD流水线中，提供对使用其自有密钥管理系统生成签名来源证明的原生支持。
云原生计算基金会（CNCF） 的项目正越来越多地采用SLSA标准。