SCITT 能记录声明，但不能批准发布

摘要

RFC 9943 允许一项有限而可检验的结论：某透明度服务依照某版本政策登记了一份已签名声明，并出具了可验证数据结构的收据。这是对登记事实的证明，不是对软件发布的批准。
选择信任哪个发行者、接受哪类收据、怎样应用本地规则、由谁准许或叫停发布，仍由能够承担损失并实施纠正的组织负责。

一条可核验记录，仍然只是一条记录

2026 年 6 月发布的 IETF Standards Track RFC 9943 为软件供应链的已签名声明设计了透明度架构。声明可以是 SBOM、背书、漏洞说明、生命周期说明，或关于某个制品的其他可序列化内容。发行者先签名；透明度服务（Transparency Service，TS）再决定是否登记。登记的定义并不含糊：服务对提交的声明应用自己的登记政策，将其加入可验证数据结构（VDS），随后产出一份收据。

这条链能够解决真实问题。收据可携带包含证明；某些结构还可提供一致性等证明。审计者因而不必只相信一页随时可改的网站，而可以检查一份声明是否出现在指定服务维护的、可验证的历史之中。透明度令已发生的主张更难被无声改写，也为事后审查留下对象。

不过，收据的对象是声明被登记这一事实。它并未判断声明是否完整、制品是否安全、依赖关系是否可接受、许可证是否适用、客户环境是否兼容，或风险负责人是否同意上线。日志不会值班，也不会在故障后撤回发布；它不应被描述成作了这些决定。

四个命题不能相互借权

第一，某发行者签署了一份声明。有效签名把内容与一个密钥及相关元数据绑定，但不自动证明该发行者就是依赖方要信任的主体，也不自动证明其有权对这一类制品作出断言，更不保证断言真实。

第二，某个 TS 登记了它。RFC 9943 所称的 Registration Policy 是登记前提，依据是 COSE 封装中非不透明的头部和元数据。政策可以严格，也可以只检查有限条件。因此登记结果只能说明该服务在当时依该政策做过哪些核验，不能替下游使用者完成所有业务、合规、安全或运行判断。

第三，依赖方验证了它认为可接受的收据。RFC 要求依赖方信任至少一个收据发行者的验证密钥或证书及相关身份。依赖方可以只验证一份满足自身条件的收据，之后也可以应用任意本地验证政策。这里不存在嵌在收据里的全球准入规则；服务、密钥、发行者、证明类型、有效期和语境，都要由实际使用者选择。

第四，拥有相应授权的人或机构作出了运行决定。发布负责人可以放行，安全团队可以暂缓，采购部门可以在特定合同范围内接受，运营方可以维持正在运行的版本而拒绝下一版本。它们的权限、损失分配和纠错手段各不相同。一份格式正确的收据不会替任何一个角色行使授权。

四个事件可以依次发生，却不能被合并为一个结论。已登记的声明可能来自本地并不信任的发行者。收据可能通过密码学验证，但某组织仍因新暴露面、兼容性问题或即将到期的例外而拒绝部署。紧急变更也可能先采用一项狭窄例外、后补完审查；这并非免除证据义务，而恰恰要求例外的授权、期限和复核独立留档。

政策和时间必须一起保存

RFC 9943 不把政策当作永恒背景。TS 运营者可以更新登记政策或信任锚；同时必须提供足够材料，使审计者能够重现登记时该政策要求的核验。因此，面对收据，正确的问题不只是“签名是否有效”，还包括“是哪一个服务、哪一版政策、哪把密钥、针对哪份声明、在什么时候得出了这一结果”。

这不反对政策演进。密钥需要轮换，规则可以收紧，新的收据配置也可能合理。边界在于：今天的政策不能悄悄改写过去一次登记的含义；过去的一张收据也不能被伪装成今天一家机构的发布政策。

序列也有边界。VDS 可以给登记声明提供追加式顺序，但 RFC 9943 明说，除非登记政策明确公告，依赖方不能假定日志中的顺序就是声明实际签发的顺序。一个日志位置不足以证明补丁先于公告、负责人先看到证据再作决定，或决定和登记处于同一时间窗。这些关系需要自己的时间戳和责任保管者。

标准对准确性同样克制。发行者可能有意或无意作出错误声明；同一制品可以有后续修订，也可能出现多个发行者相互矛盾的声明。透明度把这种分歧暴露给依赖方，并不任命一个自动裁判来裁定真伪。

真正缺失的往往是决定记录

许多组织已经保存制品摘要、签名证明、收据和一个政策名称，却把最关键的“为什么放行”留在聊天记录、控制台按钮或无从追溯的紧急许可里。出事之后，人们能够证明某项声明进入了日志，却无法复原谁基于什么依据让软件通过了门槛。

需要补充的不是另一枚签名，而是一份与 SCITT 分离的发布决定收据。对每次有实质影响的放行、暂缓、拒绝或例外，它应把不可变制品版本、声明及发行者、TS 身份、登记政策版本和登记时间、收据验证结果与复核时间、本地政策或例外、作决定的授权主体、结果、下次复核或到期触发器，以及纠正、回滚或申诉路径关联起来。

这不是 RFC 9943 新增的强制项。恰因为不是，才不会把 IETF 标准伪装成企业发布委员会。测试细节、客户身份、可被利用的信息和完整威胁模型可以继续受保护；但有权审计、纠正或挑战结果的人，应能看见证据如何进入了真正的决定。

自动化没有改变该责任链。流水线可以自动验证收据并执行既定规则，记录仍应写明执行的是哪一版规则、谁通过了这条规则、它评估了什么输入、产生了何种结果。“日志允许了它”掩盖了事实：先前有人或某机构选择了让自动化执行的规则。

标准提供证据，不接管风险授权

RFC 9943 明确把声明管理与存储、参与者发现及变更通知留在范围之外。这种克制是优势。生产商、医院、政府采购方与志愿维护者可以验证同一份收据，却不必假装共享同一风险授权。

问题只在技术事实被拿来洗白制度决定时出现。采购方说“登记过”便等于尽调完毕；交付团队说“包含证明”便等于风险负责人批准；运营者说发行者签名便等于在新漏洞出现后仍可运行。每种说法都从有限而真实的事实跨越到没有被记录的权力。

更稳健的顺序是：按证明所能证明的范围验证它；保存赋予它意义的政策和时间；然后记录谁决定怎样使用这份证据。这样，密码学故障和治理故障才可以各自被定位，而不是互相遮蔽。

SCITT 能记录一份声明，却不能批准一次发布

为何重要

摘要

一条可核验记录，仍然只是一条记录

四个命题不能相互借权

政策和时间必须一起保存

真正缺失的往往是决定记录

标准提供证据，不接管风险授权

来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报