云原生供应链安全项目如何分工

云原生供应链安全项目看起来名称相近，实际分工并不重叠：有的负责描述“怎么构建”，有的负责证明“是谁签的”，有的负责回答“它和哪些依赖有关”，还有的负责决定“能不能进入集群”。把它们当成一套万能扫描器，通常会得到很多孤立的报告；按证据类型拆层，才容易落地。

最实用的分工是：用 SLSA 与 in-toto 描述和记录构建过程，用 Sigstore 完成制品签发与透明记录，用 GUAC 汇总 SBOM 和证明形成关系查询，最后交给 OPA、Kyverno 等策略组件执行准入。Tekton Chains 或同类流水线观察器负责把证明自动产出。

官方入口：https://www.cncf.io/projects/in-toto/；https://docs.sigstore.dev/；https://docs.guac.sh/

先按证据类型分层，项目就不会互相抢职责

可以把一条发布链路拆成四种证据。第一种是来源与构建证据，回答源代码、构建平台、构建步骤和产物之间的关系；第二种是身份与完整性证据，回答制品是否由预期身份签发、记录是否可追溯；第三种是组成关系证据，回答一个镜像包含哪些包、某个依赖影响了哪些制品；第四种是策略结果，回答这些证据是否满足组织规则。

这四层对应的项目可以协作，但不能互相替代。SLSA 更像逐步提高构建保证的框架，in-toto 更强调把供应链步骤、参与者、材料和产物写进可验证的布局与链接元数据。它们解决“过程是否按约定发生”，不是直接替代镜像签名服务。

构建证明：SLSA 和 in-toto 负责把过程说清楚

如果团队只保存最终镜像摘要，出了问题时仍然不知道它由哪个提交、哪个流水线、哪个构建环境生成。SLSA 的价值在于把构建来源和保证等级作为逐步改善的目标；in-toto 则提供更细的角色与步骤模型。其 layout 由项目所有者定义，functionary 执行步骤并生成 link metadata，客户端再验证布局、签名、材料和产物。

工程上可以先落一个最小范围：固定受保护分支、记录提交摘要、绑定构建工作流身份、产出可验证的 provenance。不要一开始就把所有人工操作都建模，否则证明文件很多，关键事实反而难以复查。

签发与透明：Sigstore 解决“谁签了、何时签的”

Sigstore 的组件边界比较清晰。Cosign 是面向容器和其他制品的客户端；Fulcio 为经过 OIDC 身份确认的签发过程提供短期证书；Rekor 记录签名事件的透明日志；TUF 分发和更新验证这些服务所需的信任根。它们组合后，验证者不必把一把长期私钥散落在流水线机器上，也能检查签名、身份和日志证据是否匹配。

这里有一个容易忽略的边界：签名只证明某个制品与某个身份之间存在可验证关系，不自动证明构建过程安全，也不等于漏洞已经清零。生产环境还要约束允许签发的工作流身份，并监控透明日志中的异常事件。

关系查询：GUAC 把零散元数据变成可追问的图

SBOM、漏洞声明和签名证明分别存放时，安全团队很难回答“这个基础镜像被哪些服务间接使用”。GUAC 的职责是摄取 SBOM 等软件安全元数据，把软件、包、制品和证明之间的关系组织成可查询图谱。它更适合做影响面分析、依赖版本蔓延检查和变更后的回溯，不应被误解为新的签名根或构建系统。

因此，GUAC 的输入质量决定查询价值。没有稳定的制品标识、SBOM 和 provenance，图中只能看到碎片。先统一制品摘要、仓库坐标和生成来源，再接入图谱，排查结果才有办法回到原始证据。

一条发布链路的最小闭环

最小组合不需要一次部署所有项目。流水线先生成构建 provenance 和 SBOM，再由 Sigstore 对制品及相关证明进行签发和记录；GUAC 摄取这些材料并提供跨制品查询；部署侧用 OPA、Kyverno 或等价策略检查签发身份、来源条件和漏洞门槛。Tekton Chains 这类流水线观察器的价值，是把证明生成和流水线事件连接起来，减少人工补录。

建议用一条低风险服务做验证，并按下面四项逐一复查：

1. 能否从镜像摘要追到源码提交和构建工作流，而不是只追到仓库名称；
2. 签名证书中的身份是否限制到预期仓库、分支或工作流；
3. 出现依赖漏洞时，GUAC 或同类关系查询能否列出受影响服务；
4. 不满足策略时，准入控制是否拒绝部署并保留可定位的证据。

按风险逐层增加，而不是堆项目

如果当前只有镜像仓库，第一步是稳定摘要、SBOM 和签名；如果已经能签名，下一步补 provenance 与构建身份约束；当依赖规模扩大，再引入关系图谱；最后才把关键规则放进集群准入。每增加一层，都要能回答一个此前回答不了的问题。

判断项目分工时，记住一句话：SLSA/in-toto 管过程证据，Sigstore 管签发与透明，GUAC 管关系查询，策略控制器管是否放行，流水线集成负责自动产生材料。这样的边界比“选一个最强工具”更能支撑长期维护。

相关问答

Sigstore 能替代 SLSA 吗？不能。Sigstore 解决签发、验证和透明记录，SLSA 关注构建保证与 provenance；两者可以协作。

GUAC 能直接阻止有风险的镜像部署吗？GUAC 的重点是汇总和查询关系，是否阻止部署应由策略控制器读取验证结果后执行。

in-toto 和 Sigstore 是竞争关系吗？不是。in-toto 描述供应链步骤和证明语义，Sigstore 提供其中可使用的签发与透明基础设施。

参考资料：https://tag-security.cncf.io/community/publications/supply-chain-security-tools/securing-deployments/；https://docs.sigstore.dev/about/tooling/；https://github.com/in-toto/specification/blob/master/in-toto-spec.md；https://docs.guac.sh/guac/