01 · SLSA的起源与治理结构
SLSA（发音“salsa”，Supply-chain Levels for Software Artifacts）是OpenSSF主导的构建完整性分级框架，其思想源头是Google内部的Binary Authorization for Borg（BAB）——Google自2013年起要求内部生产二进制必须携带可验证的构建来源证明方可部署。SLSA于2021年10月以v0.1公开（由Google与OpenSSF共同推动），2023年4月发布v1.0，将框架收敛为两大轨道：Build Track（构建轨道，L0—L3）与Source Track（源码轨道，SLSA 1于2024年9月发布），并明确provenance（来源证明）作为贯穿各级别的核心制品。
| 要素 | 内容 |
|---|---|
| 治理方 | OpenSSF（Linux基金会旗下开源安全基金会）SLSA项目社区，规范文本以slsa.dev官方Git仓库为准 |
| 证明格式 | 采用in-toto attestation框架（由纽约大学 Secure Systems Lab等学术力量主导设计），JSON格式、可嵌入签名 |
| 核心承诺 | “验证而非信任”：消费方/部署方对制品的构建来源进行密码学验证，而非依赖对构建方的身份信任 |
| 与相邻框架 | 与NIST SSDF（开发过程）、SPDX/CycloneDX（成分）、sigstore（签名基础设施）互补，共同构成“透明—证明—验证”闭环 |
02 · 构建轨道分级要求详解（Build Track）
| 级别 | 关键要求 | 威胁缓解 | 典型实现路径 |
|---|---|---|---|
| L1 | 构建生成provenance，记录构建定义、输入（源码/依赖的digest）、构建器ID、构建参数 | 事后归因、影响面定位；防止“说不清从哪来” | 任意CI中生成in-toto provenance JSON并随制品归档 |
| L2 | provenance由构建平台密钥签名，验证方可核验签名链 | 防止攻击者伪造provenance声称可信来源（含内部攻击者） | GitHub Actions OIDC工作负载身份 + Sigstore签名；Tekton Chains |
| L3 | 构建在隔离、临时、无外部参数注入的受控构建器中执行；构建定义来源可信（如SLSA 1源码级验证） | 抵御构建服务器持久化驻留（SolarWinds形态）、跨任务污染、构建脚本注入 | 托管构建服务（GitHub-hosted runners隔离性）、KMS保护的签名密钥、策略化构建器白名单 |
2.1 Source Track（源码轨道）
SLSA v1.0预留了源码轨道，SLSA Source Level 1于2024年9月发布：要求版本控制系统对每次变更做可验证的溯源（提交与分支保护规则绑定、变更历史不可静默改写），防止“强推覆盖历史”掩盖恶意提交。源码轨道与构建轨道叠加，才能覆盖“恶意提交进入代码库→合法构建正常执行”的XZ式场景——构建过程完全可信，但输入本身就是恶意的。
03 · Provenance的结构与验证
3.1 证明内容（SLSA Provenance v1.0字段概要）
- buildDefinition：构建器ID、构建类型、外部输入（源码仓库+digest、依赖清单digest、构建参数）；
- runDetails：构建开始时间、构建器版本、环境标识；
- subject：被证明制品的digest集合（镜像/包与sha256绑定）。
3.2 验证逻辑（消费侧三问）
| 验证问题 | 校验内容 | 失败处置 |
|---|---|---|
| ① 证明是真的吗？ | 验证provenance签名链（构建平台证书→Sigstore信任根） | 拒绝制品；告警构建平台信任链异常 |
| ② 制品是这份证明的制品吗？ | 制品digest与subject字段逐一比对 | 拒绝；可能遭遇“证明与制品调换”攻击 |
| ③ 来源是预期的吗？ | 仓库、分支、构建器ID、参数是否匹配组织策略白名单 | 拒绝或转入人工审批；策略例外留痕（第5—6页准入落地） |
3.3 复现构建：L3之上的增强验证
可复现构建（reproducible build）要求独立重建产出与发布digest一致的制品，是发现“同一源码两次构建结果不同”的最强手段（暗含构建环境被污染的检测）。Bazel、ko等工具链对可复现性有良好支持；Google与学术界（如“reproducible builds”社区）长期推动发行版级复现实践。组织可将其作为关键制品（基础镜像、安全组件）的年度审计项，而非全部制品的日常门槛。
04 · 可信构建平台基线要求
| 基线维度 | 要求 | 反模式（对应事件） |
|---|---|---|
| 隔离性 | 每个构建任务在独立、干净的环境中执行；禁止复用可写工作区 | 构建机长期驻留→持久化后门（SolarWinds构建系统被驻留的公开调查结果） |
| 临时性 | 构建环境用完即毁，凭证按任务签发、任务结束即失效 | 长期凭证写在构建机磁盘（Codecov导出凭证事件的同类风险） |
| 参数受控 | 构建参数由声明式构建定义生成，禁止流水线内任意注入外部输入 | PR标题/描述注入脚本执行（PPE，见第7页） |
| 密钥保护 | 签名密钥存于KMS/HSM，构建器仅获得短时签名授权 | 密钥明文入仓库/流水线变量（GitHub Secret Scanning高频告警类型） |
| 可观测 | 构建日志、provenance、Rekor条目三联存证，保留期满足合规要求 | 日志留存不足导致事后无法取证 |
05 · 落地工具链对照
| 工具/项目 | 生态归属 | 对应级别支持 | 说明 |
|---|---|---|---|
| slsa-github-generator | OpenSSF官方 | Build L2—L3（GitHub Actions场景） | 官方复用工作流，基于OIDC工作负载身份生成并签名provenance |
| Tekton Chains | CD Foundation/CDF | Build L1—L3 | Kubernetes原生流水线中自动生成并签名taskrun provenance |
| ko | Google（开源） | 集成provenance生成 | Go应用极简容器构建，默认产出SBOM并支持cosign签名联动 |
| Bazel | 社区/Google | 可复现构建支持 | 声明式构建+远程执行沙箱，作为L3之上的复现性增强底座 |
| in-toto | 学术社区（NYU SSL等） | 证明框架本身 | SLSA provenance的承载格式，支持多步骤供应链布局证明（layout） |
| GitHub Artifact Attestations | GitHub | Build L2级provenance SaaS化 | 2024年5月公测：托管式provenance生成、签名与Rekor存储 |
# 验证示例：校验镜像是否携带SLSA provenance并匹配digest（cosign verify-attestation） cosign verify-attestation --type slsaprovenance --certificate-oidc-issuer https://token.actions.githubusercontent.com --certificate-identity-regexp https://github.com/your-org/your-repo registry.example.com/app@sha256:<digest>
注：命令行示例基于cosign官方文档的slsaprovenance验证模式，参数名随版本演进可能调整，以所使用版本官方文档为准。
06 · 与NIST SSDF的映射衔接
SLSA解决“构建与来源可证明”，NIST SSDF（SP 800-218，2022年2月）解决“开发过程可管理”。组织落地时建议按下表衔接：
| SSDF实践（PO/PS/RV） | 本子课题对应控制 |
|---|---|
| PO.1 安全开发政策 / PO.3 工具链 | 构建平台基线（第4节）、第三方Action准入（第7页） |
| PS.1 保护软件与组件 | SBOM成分管理（第3页）、签名分发（第5页）、私有仓库准入（第6页） |
| PS.2 保护开发环境 | 构建隔离/临时性基线、凭证短期化（第7页OIDC） |
| RV.1 风险评估 / RV.2 漏洞响应 | VEX研判（第3页）、依赖更新策略（第8页成熟度L3指标） |
本节参考来源（第4页）
SLSA v1.0官方规范（Build Track与级别定义）：slsa.dev/spec/v1.0；SLSA项目仓库：github.com/slsa-framework/slsa。
SLSA Source Track（SLSA 1，2024年9月）官方页面：slsa.dev/spec。
in-toto框架（attestation与layout）：in-toto.io。
slsa-github-generator官方仓库（OpenSSF）：github.com/slsa-framework/slsa-github-generator。
NIST SP 800-218 SSDF v1.1（2022年2月）：csrc.nist.gov/pubs/sp/800/218/final。
GitHub Artifact Attestations官方文档（2024年发布）：docs.github.com。
Tekton Chains、ko、Bazel官方文档：tekton.dev、ko.build、bazel.build。
Binary Authorization for Borg相关公开论文（BAB学术溯源）：cloud.google.com/binary-authorization（BAB工程实践说明）。