“发布前要接入 Sigstore 签名”，这项需求现在能定范围吗？
买方只说“发布前接入 Sigstore 签名”时，先收齐制品、身份、集成、验证、门槛五项字段，再把请求分流到四条实施路径，之后才承诺范围。
买方说“发布前要接入 Sigstore 签名”时，定范围还太早，但已经可以进入澄清阶段。这句话没有指明制品、身份提供方、签名环境、验证策略、发布门槛、验收方式和负责人——每个空缺都对应一条成本线。先收齐五项边界信息，再把请求分流到签名集成、身份配置、验证策略或发布流水线验收，之后才谈日期和报价。
先定义几个术语。Sigstore 是一套软件签名系统，围绕短期证书、基于身份的签名和透明日志构建（Sigstore Docs，Overview，2026 年 8 月 3 日访问），由三个组件构成：Fulcio 负责签发证书，Rekor 负责透明日志，Cosign 负责签名与验证。Cosign 可以为容器镜像、blob（任意二进制数据块）和其他制品签名。OpenID Connect（OIDC）是免密钥（keyless）签名流程使用的身份协议，它把短期证书绑定到身份提供方（如 GitHub）给出的身份。制品摘要（artifact digest）是制品内容的加密校验和，验证默认会检查它。签名者（signer）是产生签名的人或服务；验证方（verifier）是按信任策略核对签名的一方。
对商务拓展负责人来说，这些术语不是技术背景，而是报价结构：制品对应集成工作量，身份提供方对应身份配置，验证方对应策略工作，门槛负责人对应验收测试。
定范围前，先收齐五项字段
把下面五项做成一张实施卡，按顺序收集：
1. 制品与摘要。 要签的是哪个镜像、blob 或文件？精确引用里是否带摘要？没有具名制品，“签名”就没有对象，也不可能有集成估算。
2. 身份提供方与签名者。 谁签名，背后是什么身份？免密钥流程用 OIDC；自管密钥和密钥管理系统会把密钥托管工作完全改掉。
3. 构建或发布集成。 签名发生在哪一步——构建步骤、发布步骤，还是独立服务？这决定集成路径。
4. 验证方与信任策略。 谁验证签名，按什么验证？官方文档的基于身份验证示例要求同时给出证书身份和 OpenID Connect 签发方（Sigstore Docs，Verifying signatures with Cosign，2026 年 8 月 3 日访问）。验证方、受信身份或密钥、策略位置都是答案的一部分。
5. 发布门槛与验收负责人。 哪个发布步骤会因验证失败而阻断，谁具名负责验收测试？没有负责人，就没有“完成”的定义。
同一模式也出现在关于 SLSA 来源证明接入需求的简析里：听起来像合规要求的请求，只有在制品及其链路被具名之后才能定范围。
把请求分流到四条路径
字段收齐后，按最早缺失的字段把请求分流到四条路径之一：签名集成、身份配置、验证策略工作或发布流水线验收。
| 路径 | 触发条件 | 主要工作 | 先补哪个字段 |
|---|---|---|---|
| 签名集成 | 制品、摘要和构建环境已具名 | 在构建或发布中加入 Cosign 签名步骤 | 制品与摘要 |
| 身份配置 | 签名路径已定，身份未确认 | OIDC 签发方配置、身份策略、密钥托管 | 身份提供方与签名者 |
| 验证策略工作 | 验证方一侧已具名 | 信任策略、允许的身份、策略位置、摘要检查 | 验证方与信任策略 |
| 发布流水线验收 | 发布门槛已定义 | 把验收测试接入发布流水线 | 发布门槛与验收负责人 |
规则很简单：路由到最早缺失的字段——没有制品，就没有集成估算，也没有报价。
关键事实：这些日期说明了什么
下面的日期都是文档访问日期，不是买方意图的证据；它们只界定这些能力描述在什么时间点仍然成立。
- 截至 2026 年 8 月 3 日访问，Sigstore Docs 概览（链接）把 Sigstore 描述为围绕短期证书、基于身份的签名和透明日志构建的系统，包含三个具名组件：Fulcio（证书签发）、Rekor（透明日志）和 Cosign（签名与验证）。
- 截至 2026 年 8 月 3 日访问，Sigstore Docs 的 Cosign 签名概览（链接）列出三条签名路径：免密钥身份流程、自管密钥和密钥管理系统。
- 截至 2026 年 8 月 3 日访问，Sigstore Docs 的 Cosign 验证指南（链接）说明其基于身份的示例需要两个值——证书身份和 OpenID Connect 签发方——且验证默认检查制品摘要。
- 截至 2026 年 8 月 3 日访问，Telegram 隐私政策（链接）说明机器人是独立的第三方服务，加入群组的机器人可以在有或没有消息访问权限的情况下运行。
这些事实界定了签名范围能诚实包含什么：没有 OIDC 签发方，官方文档的基于身份验证路径就不可用；买方对透明日志没有意愿，说明“Sigstore”实际比买方以为的包含更多。
工作示例：一条典型的合成需求
示意性合成消息——并非真实客户对话。 供应商协调群（合成）：“我们下次发布窗口前需要 Sigstore 签名。周五前能给我们时间表和预算吗？”
套用实施卡，五个字段全空。“我们的下次发布”没有指名任何镜像、二进制或策略包；身份提供方、集成点、验证方和门槛负责人全部未具名。这类需求常在专业社区里形成，措辞会在多个群之间流传；网络安全需求如何在专业社区中形成分析了这个动态。
精简版回复：“定范围之前需要两个答案：哪个制品和摘要，由哪个身份提供方签名？然后是流水线里的哪一步，验收测试由谁具名负责。”
仍未知：验证方环境、策略位置、具名门槛负责人。谁必须验证：买方的发布工程师、安全团队和发布经理，各管各的领域。
为什么这关系到你的报价
对服务商负责人，每个空缺字段都是返工风险。验证指南说明了原因：基于身份的检查需要证书身份和 OIDC 签发方两个值，缺一个，检查就会在门槛处失败。如果你的范围覆盖签名，而买方的验收测试覆盖验证，交付就会在你从未定价的步骤失败。澄清比变更单便宜，五项实施卡让这个过程可重复。
FAQ
“Sigstore 签名”一定意味着免密钥签名吗？
不是。Cosign 签名概览（Sigstore Docs，2026 年 8 月 3 日访问）列出三条路径：免密钥身份流程、自管密钥和密钥管理系统。免密钥只是其中之一；买方的身份提供方和密钥托管偏好决定适用哪条。
买方说出制品之后，就能定范围吗？
还不能。验证仍然需要受信身份或密钥、策略位置和验证方，发布门槛也需要负责人。制品是第一项字段，不是整张卡。
发布门槛的验收测试该由谁负责？
买方一侧的具名人员——通常是控制那个阻断发布步骤的发布工程师或发布经理。门槛负责人未具名，验收测试就没有问责方。
一个务实的下一步
把五项实施卡发回去，看哪些字段带着答案回来；空缺告诉你工作会走哪条路径。一个操作层面的提醒：当只有一半信息的签名请求不断出现在 Telegram 群里时，追踪这个模式本身就是工作的一部分。TOP Prospect 就是为此设计的工具：它只处理你主动连接且有权访问的 Telegram 群，处理结果保留来源证据，输出的是供人核验的候选项或评分，而不是事实认证，最终决定由人做出，它也不会自动联系群成员。如果你连接的群里出现了这个模式，Telegram 商业信号情报页面是下一步的自然阅读。
常见问题
“Sigstore 签名”一定意味着免密钥签名吗？
不是。Cosign 签名概览（Sigstore Docs，2026 年 8 月 3 日访问）列出三条路径：免密钥身份流程、自管密钥和密钥管理系统。免密钥只是其中之一；买方的身份提供方和密钥托管偏好决定适用哪条。
买方说出制品之后，就能定范围吗？
还不能。验证仍然需要受信身份或密钥、策略位置和验证方，发布门槛也需要负责人。制品是第一项字段，不是整张卡。
发布门槛的验收测试该由谁负责？
买方一侧的具名人员——通常是控制那个阻断发布步骤的发布工程师或发布经理。门槛负责人未具名，验收测试就没有问责方。
