云原生平台迁移时如何用 SLSA 级别整理构建证明材料

云原生平台迁移时，最容易漏掉的不是构建脚本，而是“这个制品到底由什么输入、什么平台、什么过程生成”的证明链。整理 SLSA 级别时，不要把一份 JSON 文件直接当成等级证明，而要把制品摘要、构建输入、平台身份、证明分发和下游验证一起放进验收表。官方规范入口：https://slsa.dev/spec/v1.2/build-requirements。

迁移验收可以先以 SLSA Build L1 建立可追溯证明，再根据制品风险逐步补齐 L2 的托管平台与真实性、L3 的抗伪造和构建隔离；级别是平台与验证能力的组合，不是文档名称。

适合阅读：负责 CI/CD、制品仓库、云原生平台迁移或发布门禁的工程师。本文只讨论证明材料和验收边界，不讨论绕过安全控制的方法。

先记住三件事：证明要绑定输出摘要；输入和构建平台要能被识别；证明生成、分发与验证必须能在发布链路中落档。

迁移验收先看哪一层

SLSA v1.2 把 Build Track 分成多个级别。L1 的核心是证明存在，要求构建过程生成能唯一识别输出制品的 provenance，并描述制品如何产生；它适合先解决“来源不清”和“发布拿错制品”的问题。L2 在此基础上要求托管构建平台生成并让下游验证证明的真实性，验收重点从“有没有文件”变为“文件能不能相信”。L3 再要求证明难以被租户伪造，并强化构建之间的隔离、临时环境和密钥边界。

迁移表可以这样写：L1 由发布团队确认证明字段齐全并随制品分发；L2 由平台团队证明构建运行在托管平台、证明具备可验证真实性；L3 还要由平台团队说明用户构建步骤不能取得签名材料、不能影响并行或后续构建。这样写的好处是责任边界清楚，避免让应用团队单独“补文档”去承担平台能力。

把证明材料接到发布门禁

迁移前先为每类制品建立一份最小证据卡。源代码修订记录实际采用的提交或版本；externalParameters 记录构建入口暴露给平台的外部输入；resolvedDependencies 记录能识别的依赖；buildDefinition 表示构建过程的定义；runDetails 记录构建平台和运行信息；subject 则绑定输出制品及其摘要。它们不是越多越好，而是要能回答“谁、用什么、从哪些输入、生成了哪个输出”。

发布门禁至少保留三类动作：第一，检查证明中的输出摘要是否等于待发布制品；第二，按组织预先定义的构建预期检查来源、构建类型和关键输入；第三，验证证明真实性，并把失败原因与制品版本关联。验证不通过时应阻断发布或转人工审批，不能只把失败日志丢在构建平台里。

平台迁移时的三种选型方式

先达成 L1：适合低风险内部工具或迁移初期。重点是统一构建入口、固定制品命名与摘要、生成 provenance 并把它和制品一起分发。它能减少误发布，但不等于能抵抗伪造。

直接选择 L2 能力的平台：适合对外发布的容器、SDK 和供应链依赖。除了证明字段，还要确认托管平台的身份、签名方式、验证入口和密钥保管责任。验收时要问清楚“谁生成证明、谁持有密钥、下游如何验签”，而不是只看平台宣传中的合规标签。

为高风险制品规划 L3：适合承载生产发布或高价值依赖的构建平台。重点转向不可伪造和隔离：用户定义的构建步骤不能访问证明签名材料，重叠构建不能互相影响，后续构建不能继承前一次的非预期状态，缓存也不能让一个构建污染另一个构建。若平台暂时做不到，应把 L3 缺口写成迁移后的平台改造项，不要把 L2 的签名材料包装成 L3。

迁移验收清单与边界

这里有一个常见边界：SLSA Build 级别描述的是构建证明的可信度和平台隔离能力，不会替你判断代码本身是否安全，也不会自动保证依赖没有漏洞。迁移项目应把漏洞扫描、许可证检查、发布审批等控制作为相邻门禁单独记录。

常见问题

只有 provenance 文件就能写成 SLSA L2 吗？

不能。L2 还需要托管构建平台生成的真实性证明，并让下游能够验证；文件存在只是 L1 的起点。

迁移时必须一次做到 L3 吗？

不必。可以按制品风险先落地 L1 或 L2，但要在清单中写明当前等级、缺口、责任方和升级条件，避免把阶段性结果误标成最终能力。

小结：用 SLSA 级别整理迁移材料，关键是把“等级”翻译成可核对的证据：L1 看证明存在，L2 看托管平台与真实性，L3 看抗伪造、隔离和密钥边界。只要每个输出制品都能沿着输入、构建平台、证明分发和下游验证回溯，迁移验收就有了可执行的落点。