SLSA Provenance：软件产物的“出生证明”

SLSA Provenance：软件产物的“出生证明”

我们通常能看到一个安装包，却不一定知道它由哪份源码、哪台构建平台、哪些依赖和哪些参数生成。SLSA Provenance 可以理解为软件产物的构建来源证明，记录软件在哪里、何时、用什么构建定义产生，并让消费者有机会验证这些信息。

来源证明记录什么

它不是一段“本项目很安全”的宣传语，而是一组结构化声明。里面可以包含构建平台、输入来源、构建步骤、依赖和输出之间的关系。消费者可以根据自己的策略检查：这个产物是否来自预期仓库，是否由预期构建系统生成，是否使用了允许的构建参数。

这和普通日志不同。日志主要帮助开发者排查过程，来源证明则面向后续验证和供应链审计。它不一定记录每一秒发生了什么，但要提供足够的信息来确认产物的来源和生成条件。

AI 编程为什么需要出生证明

AI Agent 可能在本机、云端任务环境、CI Runner 或第三方平台中修改代码并构建软件。如果只保留最终二进制，之后很难回答“这是哪个提交生成的”“模型改过哪些文件”“构建时是否拉取了额外依赖”。

来源证明不能直接回答模型是否聪明，却可以把软件交付从“相信某个总结”变成“核对一份记录”。它尤其适合高风险项目：部署前检查产物是否由隔离环境生成，是否对应已审查的提交，是否与 SBOM 和签名关联。

SLSA 不等于绝对安全

记录来源并不自动保证来源可信。如果构建平台本身被攻破，或者验证方没有正确检查证明，攻击仍然可能发生。SLSA 更像一套逐步提高供应链完整性的语言和规范，需要与签名、权限、可复现构建和依赖审查结合。

普通项目需要做到哪一步

先把源码提交、构建环境、产物摘要和依赖清单关联起来，再逐步加入签名与验证。对个人项目而言，哪怕只是保存“哪个提交生成哪个发布包”，也比只上传一个无法追溯的压缩包更可靠。

SLSA 对构建来源证明的定义见 SLSA Provenance 规范。