SLSA 1.2 实践指南如何证明软件制品来自可信构建专栏代码安全笔记 · 软件供应链安全进阶篇07关键词SLSA 1.2、Provenance、制品签名、构建可信、in-toto摘要安全测试通过的软件就一定是部署到生产环境的那个软件吗如果构建机或发布流程被篡改源代码审查和漏洞扫描的结论可能无法覆盖最终交付物。SLSASupply-chain Levels for Software Artifacts提供了一种渐进式提升供应链可信度的思路。本文围绕SLSA 1.2、构建来源证明Provenance、摘要与签名验证介绍落地路径。一、为什么“扫描过源码”还不够软件从仓库走向生产至少经历四次关键转换构建平台身份SHA256 摘要源码提交构建任务软件制品制品仓库生产部署来源证明发布校验策略攻击者并不一定需要修改 Git 仓库只要能够控制构建任务、注入依赖、替换构建产物或劫持发布凭据就有可能改变生产部署的软件。因此要同时回答谁构建了它、用什么源码和配置构建、产物摘要是什么、部署时是否验证这些信息二、SLSA 1.2 的定位截至 2026 年 10 月SLSA 官方网站将v1.2 列为正式版本。它通过不同轨道tracks和等级描述安全保障能力不等于某个统一颁发的企业资质证书。实践中需要区分Build provenance追踪构建产物与源码、构建平台、构建定义之间的关系Source provenance记录源码修订及其变更管理过程Attestation对声明及其被证明对象进行关联可配合签名、信任根和验证策略。SLSA 升级不是给流水线挂一个标签而是逐步强化构建平台隔离、来源证明与验证能力。不同轨道的具体等级要求应以对应版本规范为准。三、Provenance 应包含什么构建来源证明通常需要覆盖如下关键事实字段类别作用示例Subject被证明的制品OCI 镜像或二进制摘要Builder可信构建平台身份受控 CI 平台Build definition构建类型及输入参数构建工作流、参数Resolved dependencies已解析的源码及依赖Git commit、材料摘要Run details本次构建执行信息调用标识、元数据不要将手写 JSON 文件直接视为可信证据。真正的验证需要确认声明与产物摘要绑定、由预期平台生成、签名/证明身份可信并且构建参数满足发布策略。四、从零落地的四个步骤1. 固定构建输入# 记录当前 Git 提交gitrev-parse HEAD# 记录构建产物摘要示例sha256sum dist/app.tar.gz固定构建工具版本、依赖锁文件和构建镜像摘要尽量减少不可控网络下载。仅固定输入仍不足以证明构建环境可信。2. 使用受控、隔离的构建环境生产发布只允许从受保护分支或经过批准的标签触发开发者提交的工作流不能随意读取生产密钥构建执行器采用临时环境并进行权限隔离明确区分提交者、审批者、构建执行者和发布者。3. 生成并保存证明材料优先使用构建平台支持的 provenance/attestation 机制保存与发布产物一一对应的声明。可采用 in-toto 生态标准及受支持的签名工具但不要忽略平台身份和证据生命周期。4. 把验证作为部署门禁允许部署当且仅当 制品摘要匹配 AND 构建平台身份在允许名单 AND 来源仓库与提交满足策略 AND 构建工作流满足批准条件 AND 证明材料签名/身份验证通过没有验证门禁的来源证明容易退化成“收集了很多文件却没有阻止错误版本发布”。五、三个常见误区误区 1有 SHA-256 就证明制品安全。摘要只能帮助识别文件是否变化若攻击者替换文件并同步替换摘要单独的哈希不提供来源真实性。误区 2签名成功就说明代码无漏洞。签名证明的是某个身份对内容进行了签署不代表内容一定没有缺陷。误区 3使用 GitHub Actions 就自动达到某个 SLSA 等级。等级与具体流程、运行方式、证明生成及验证能力有关不能仅凭工具品牌判定。六、分阶段建设建议阶段目标建议验收证据第一阶段产物可定位Commit、版本、摘要可对应第二阶段构建可溯源来源证明、构建平台身份第三阶段发布可验证自动化部署门禁和拒绝记录第四阶段持续运营证明覆盖率、验证失败率、例外审批总结SLSA 的核心价值是把“我们相信构建流程没问题”变成“我们有可验证的构建事实和发布准入条件”。企业应先从关键生产服务试点建立制品摘要、构建来源证明与部署验证的闭环。