技能介绍

要解决的具体问题

在现代 CI/CD 流水线中，代码从提交到产物生成的过程往往不透明。攻击者可能通过篡改构建配置、替换依赖或劫持构建节点，注入恶意代码而不改变源代码仓库的可见内容。结果就是：你拿到的二进制文件、容器镜像或 npm 包，名义上来自 main 分支，实际上构建路径已被污染。团队缺少一种轻量、可自动化的方式，去证明"这个产物确实由预期的源代码、在可信的构建环境中、按照声明的方式生成"。

技能如何工作

这个技能基于 SLSA 框架的官方验证器，直接处理构建溯源证明（build provenance attestation）。它不重新构建软件，而是读取构建者生成的签名元数据，并执行一系列确定性检查：

来源一致性：将溯源声明中的源码仓库、分支或 commit 哈希与预期值比对，确保代码没有被中途替换。
构建者身份：验证构建是由哪个具体构建器（builder）执行的，并核对该构建器是否在允许的白名单内。
完整性校验：确认产物中的文件哈希、构建参数等细节与证明中记录的值一致，任何篡改都会破坏签名或哈希匹配。

典型流程是：在流水线中生成产物的同时，产出符合 SLSA 规范的溯源文件；下游环节（如发布、部署）调用该技能对产物及其证明进行验证，通过后才继续推进。整个过程不需要修改现有构建脚本，只需要将验证器嵌入到发布或审批门禁中。

适用边界与注意点

该技能只负责验证溯源证明，不会扫描代码漏洞，也不替代运行时防护。它假设构建者本身生成的证明是完整的、签名未被窃取——这属于信任根问题，需要与身份管理、密钥保护配合。对于 npm 包，它明确要求构建链必须使用 SLSA3 Node.js builder，并且 source-branch 参数目前只支持 main、dev 等常规分支，某些 GitHub Actions 触发场景（如 PR 触发）可能无法正确填充溯源字段。此外，验证器不会自动证明构建环境本身是隔离且无后门的，它只确认构建记录未被篡改。适合用在已经有 SLSA 兼容构建器、并希望将溯源验证纳入发布流程的团队，不适用于纯离线、未采用 SLSA 工作流的项目。