存在性证明对比 Sigstore：两者都需要吗？

Sigstore 和存在性证明其实并不是竞争对手。Sigstore 回答的是 这个软件构件由谁签名？签名事件是否记录在公开日志里？ Label 309 回答的则是 这些确切的字节是否在某个公开时间之前就已存在？这一点能否在不信任任何单一服务的前提下被证明？ 对大多数软件团队来说，最稳妥的做法是两者并用：用 Sigstore 为发布做签名并记录日志，再用 Label 309 把发布证据锚定到链上。

Sigstore 是一套软件签名与透明性生态。Label 309 则把内容哈希、清单、封存文件或一个 Merkle 根锚定到 Cardano 上，任何人日后都能验证这份确切的数据在某个具体区块时间之前就已存在——只需用到那笔交易和一个公开的区块浏览器，整个过程中无需任何签发方服务器参与。

什么是 Sigstore？

Sigstore 是一套开源生态，用于为软件供应链构件签名，并把签名事件记录到公开日志中。

它常用的无密钥流程会用到一个 OpenID Connect（OIDC）身份、一张由 Fulcio 签发的短期证书、一个在客户端生成的签名，以及一条写入 Rekor 透明性日志的记录。它的目的，是在保留「谁为哪些内容签了名」这份可审计公开记录的同时，让构件签名变得更简单。

Sigstore 非常适合用于：

容器镜像
二进制文件与软件包
软件物料清单（SBOM）
来源溯源证明
CI/CD 与发布签名流程
验证某个构件是否由预期身份签名

它就是为软件供应链信任而生的。

什么是 Label 309？

Label 309 是一个开放、厂商中立的标准，用于在 Cardano 上记录存在性证明。该提案已提交至 Cardano 的 CIP 流程，目前正由 CIP 编辑审阅；其链上标识符是元数据 label 309。

一条 Label 309 记录可以承诺一个或多个内容哈希、一个覆盖多个文件的 Merkle 根、可选的记录级签名、指向接收方密钥的封存载荷，以及内容寻址存储的 URI。其核心证明仅凭那笔 Cardano 交易和被核对的字节即可独立验证——无需账户、无需登录，也不依赖任何单一提供方。

对软件团队而言，这让它非常适合用来锚定发布证据：

构件摘要
Sigstore 包
SLSA 来源溯源与 in-toto 声明
SBOM
发布清单
构建日志与测试结果
事件证据

它是一层公开、带时间戳的承诺。

真正的区别在哪？

Sigstore 回答的是软件的身份与签名问题。Label 309 回答的是任意字节的存在与时间问题。

Sigstore 能帮你回答：

这个容器镜像签名了吗？
是哪个 OIDC 身份绑定到了签名证书上？
签名事件是否记录在透明性日志里？
这个构件的签名能否被验证？
它是否符合我对可信签名者的策略？

Label 309 能帮你回答：

这个构件摘要是否在这个 Cardano 区块时间之前就已存在？
这份 SBOM 是否属于已承诺的发布证据？
这份发布清单是否在某次事件之前就已存在？
是否有某个已知的项目身份为这条记录签名（可选）？
某个接收方日后能否解密一份封存的证据包？

这两组问题是相互补充的，而非彼此重叠。

Rekor 不是已经做了这件事吗？

如果你在用 Sigstore，那就用 Rekor——它是干这件事的正确工具。

Rekor 是一套用于签名与软件元数据的透明性日志，旨在让签名事件可被发现、可被审计。Sigstore 的文档把它描述为一份只可追加、抗篡改的账本，审计方可以监控其一致性——其设计目标，是让任何试图篡改或删除记录的行为都能被察觉，而不是悄无声息地发生。

Label 309 并不取代 Rekor。它提供的是另一种锚：

一个植根于 Cardano 共识、而非某个服务自营日志的公开时间戳
一套在元数据 label 309 之下定义的记录结构
对敏感证据的可选封存保存
向特定接收方的投递
面向大型证据集的 Merkle 批处理
不依赖任何特定提供方保持在线的验证

如果一次发布已经有了 Sigstore 证据，那就把这份证据锚定下来，别把它扔掉。

组合起来的工作流是什么样的？

一条 CI/CD 流水线可以先组装出一个发布证据文件夹，再把它承诺下来。

这个文件夹里可能包含发布清单、构件摘要、Cosign 签名或包、Rekor 记录引用、SLSA 来源溯源、in-toto 证明、SBOM、构建日志、测试报告和部署清单。

流水线会对每个文件计算哈希，构建一棵 Merkle 树，然后发布一条携带 Merkle 根的 Label 309 记录。由于根是单个 32 字节的值，一笔交易就能代表一个任意大的证据集；日后只需一份包含证明，就能表明其中某个特定文件确实属于那个根。这条记录还可以携带一个来自项目或公司身份的可选签名。关于如何把众多文件折叠进一个根的具体机制，参见用一条记录覆盖成千上万个文件；关于端到端的流水线模式，参见锚定 CI/CD 构建证据。

之后，审计方会独立验证两件事：

Sigstore——谁为哪些内容签了名，在哪个身份和透明性日志的上下文之下
Label 309——哪个证据集在某个公开的 Cardano 时间之前就已存在

Label 309 会验证软件签名吗？

不会。Label 309 并不知道某个 Cosign 签名是否有效、某个 OIDC 身份是否可信、某条策略是否满足，也不知道某次构建是否达到了 SLSA 的预期。

它能证明的，是那个签名文件、包、证明、SBOM 或发布清单 在某个公开时间之前就已存在。这些格式本身，仍然由软件供应链工具按各自的规则去验证。

这种分工是健康的。一份存在性证明不应假装自己是一台软件签名策略引擎。

Sigstore 会保存你的整套证据集吗？

它本身不会。Sigstore 聚焦于软件构件的签名与透明性。而一个真实的发布流程，往往还需要保存构建日志、SBOM、测试报告、部署清单、事件时间线和私密证据包。

Label 309 可以把这些材料作为一个整体承诺下来。如果其中某些材料是敏感的，它们可以保持私密，通过一个 Merkle 根来承诺，而不公开其内容——或者将其封存，让密文存放在内容寻址存储中，只有持有密钥的人才能解密。一条封存记录能确保明文只对目标接收方可读；但它本身并不保证匿名性，接收方在解密之后仍然可能泄露明文。

这让 Label 309 在审计、事件响应、采购、客户安全审查以及长期发布证据等场景中都很有用。

你什么时候该用 Sigstore？

当你需要软件构件签名和基于身份的验证时，就用 Sigstore。它非常适合为容器镜像、二进制文件和软件包签名；适合公开的开源发布流程；适合用 OIDC 身份做无密钥签名；适合供应链透明性；适合基于预期签名者的验证策略；也适合与现有分发工具集成。

对现代软件签名而言，Sigstore 是一个稳妥的默认选择。

你什么时候该用 Label 309？

当你需要围绕证据建立一层公开、带时间戳的承诺时，就用 Label 309——比如锚定发布清单、证明某份 SBOM 在漏洞披露之前就已存在、用一个 Merkle 根承诺整个发布证据集、保存封存的事件材料、证明交付给客户的那套构件，或者保留一份不依赖任何 CI 提供方或构件仓库面板保持在线的证明。

Label 309 并不是签名的替代品。它是一个时间锚，也是一种证据承诺格式。开源的 cardanowall CLI 正是为这类自动化而生的：它与网关无关、以原始种子为先，因此可以嵌入流水线，整个过程无需任何网站参与。完整流程参见在自动化中使用 CLI。

这两套系统都证明不了什么？

两套系统都证明不了软件是安全的。

一个已签名的构件，仍然可能含有漏洞。一份带时间戳的 SBOM，可能并不完整。一份构建日志，记录的可能是一条配置错误的流水线。一次发布，文档可以做得很完善，却依然不安全。

Sigstore 和 Label 309 帮你证明的是完整性、身份、透明性、时间，以及证据的连续性。而安全本身，仍然取决于源码审查、构建隔离、依赖管理、测试、漏洞响应和运营控制。关于一份证明究竟能与不能确立什么的一般边界，参见一份证明证明不了什么。

一句话总结

用 Sigstore 为软件签名，并让签名事件保持透明。用 Label 309 把发布证据——清单、日志和证明——锚定到一个任何厂商都无法悄悄挪动的公开 Cardano 时间上。两者配合，日后验证这整套软件的来龙去脉会变得容易得多。