买方索要 SLSA 来源证明，究竟需要哪种服务？
买方在准入时索要 SLSA 来源证明，却未说明制品、构建平台、目标等级、验证方与验收方式——用五字段记录把请求分流到四条服务路线，避免承诺错服务。
买方在准入时索要 SLSA 来源证明，通常是在说出一个合规目标，而不是一份交付物。同样一句话可能对应四条互不相同的服务路线：来源证明生成、构建系统加固、验证策略实施与证据复核。只有把制品与摘要（artifact 及其内容指纹 digest）、构建平台、目标等级、签名方或验证方、验收方式这五个字段问清楚，请求才能落到正确的服务上。
Supply-chain Levels for Software Artifacts（SLSA，软件制品供应链级别）v1.2 是 SLSA 项目发布的规范（2026 年 8 月 3 日访问，slsa.dev/spec/v1.2/），以轨道和等级组织逐级增强的软件供应链安全保证。来源证明（provenance）在 v1.2 中定义为可验证的信息，追踪制品在供应链中于何处、何时、如何被生产（SLSA 项目来源证明页，2026 年 8 月 3 日访问）；证明（attestation）则是承载这些信息的签名声明，SLSA 推荐包括 provenance 在内的证明格式。对软件供应链安全服务销售负责人来说，这个区别决定报价方向：买方点名 SLSA，是点名了一个目标标准，而不是一项服务；同一句话可以引出四份不同的工作说明书。
先把请求分流：五字段记录缺了什么
分流依据是请求缺了什么：
- 制品、摘要与构建平台都已点名，但没有任何东西证明这次构建确实发生 → 来源证明生成。
- 构建平台无法诚实记录输入、命令与输出 → 先做构建系统加固，之后任何证明才谈得上诚实。
- 已有证明存在，但没有验证规则对应买方的验收测试 → 验证策略实施。
- 证明已提交且被拒 → 证据复核。
- 两个及以上字段未知 → 先发一份澄清记录，再分流。
v1.2 里锚定对话的三个事实
v1.2 构建来源证明 schema（SLSA 项目发布，2026 年 8 月 3 日访问，slsa.dev/spec/v1.2/build-provenance）对 Build Level 1 要求两个顶层字段：buildDefinition 与 runDetails，而 runDetails 又要求 builder。具体地说：
- buildDefinition 描述构建了什么、如何构建，包括构建启动时的外部参数。
- runDetails 记录构建如何运行，并点名 builder——即产出制品的系统身份。
- schema 还把制品主体（产物及其摘要）、调用元数据与验证规则作为相互独立的部分。
关键在于：产出带这些字段的文档并不会授予 SLSA 等级——字段是格式要求，内容是否可信取决于构建平台与 builder 身份背后的签名方。这也解释了五字段记录为何能分流：生成填字段，加固让平台能诚实填字段，验证策略定验证规则，证据复核查已有产出。
四条服务路线，同一张记录
用同一张五字段记录比较四条服务路线，逐项对齐：
| 服务 | 制品与摘要 | 构建平台 | 目标等级 | 签名方与构建方或验证方 | 买方验收方式 |
|---|---|---|---|---|---|
| 来源证明生成 | 作为证明主体，前置必需 | 假设平台能记录构建 | 决定证明携带哪些字段 | 你以构建方身份签名 | 产出验收测试可接受的证据 |
| 构建系统加固 | 先产出可复现的制品与摘要 | 工作对象本身 | 决定平台必须新增哪些构建保证 | 你改变构建方运行的环境 | 让可接受证据成为可能 |
| 验证策略实施 | 需要一份可核验主体的证明 | 仅在策略引用处相关 | 决定适用哪些验证规则 | 你配置验证方 | 定义测试如何被评估 |
| 证据复核 | 复核现有证明中的摘要 | 从既有记录读取 | 对照买方声称的等级比较 | 你复核，不签名 | 把被拒证据对应到测试 |
决策矩阵
| 如果请求…… | ……并且 | 分流 |
|---|---|---|
| 点明了制品、摘要和平台 | 没有任何证明 | 来源证明生成 |
| 点明平台无法诚实记录的等级 | 买方期待真实字段 | 构建系统加固 |
| 引用了已有证明 | 没有对应验收测试的验证规则 | 验证策略实施 |
| 报告被拒的证明 | 没说哪个字段失败 | 证据复核 |
| 多数字段空缺 | 今天就想要服务名 | 先发澄清记录 |
当买方的验收方式读起来像一份 SOC 2 证据请求——点名了证据类型却没有更多细节——我们在《SOC 2 准入证据请求》中梳理过的模式仍然适用：请求点名的是证据类型，而不是评估它所需的字段。
复合示例：一条准入消息
下面是一条复合示例消息（仅为示意，非客户记录；不存在真实买方、报价或截止时间）：
“为完成准入，我们需要你们所交付制品的 SLSA 来源证明。我们的安全团队会在批准供应商之前，按我们的验收标准对其进行验证。请确认你们能否提供这项服务？”
逐项过五字段：
- 制品与摘要：未点名。
- 构建平台：未点名。
- 目标等级：未点名。
- 签名方与构建方或验证方：买方团队”会验证”，暗示你会作为签名构建方——这是推断，不是陈述的事实。
- 买方验收方式：只说”验收标准”，没有任何内容。
两个以上字段缺失，今天正确的回应是澄清记录，而不是服务承诺：请买方给出制品与摘要、构建平台、目标等级、任何现有证明，以及确切的验收测试——谁验证、用什么规则、对照哪个等级。
复合后续（仍为示意）：若买方随后点明容器镜像及其摘要、托管 CI 平台、目标 Build Level 1，且没有现有证明，分流结果就是来源证明生成；若买方点明目标等级但确认平台无法记录构建输入，分流结果就是加固。方法本身不消除歧义，买方的回答才消除。
为什么这很重要：承诺错服务，浪费的是买方的准入周期和你的信誉。报价来源证明生成，而真正的障碍是平台无法记录构建，交付物到达时就已经失败。五字段记录还给了你站得住的提问理由：你在补全买方自己的验收测试将要依赖的记录，而不是拖延。
什么仍然未知、由谁验证：目标等级与验收方式属于买方安全团队；平台能否记录构建，必须由你的工程团队核实，而不是从产品页假设；是否存在既有证明，要对照制品注册表核查。仅凭一条准入消息，这三项都无法确认。
如果买方渠道本身是受关注的 Telegram 群，我们在《Telegram 信息处理供应商 DPA 核查》中讨论的纪律同样适用：渠道显示说过什么，并不认证它。Telegram 自己的隐私政策（当前政策页，2026 年 8 月 3 日访问）声明，机器人是独立的第三方服务，消息访问可选且界面会显示适用模式，第三方机器人开发者应在访问数据前征得许可。TOP Prospect 在实践中遵循这一边界：它只处理用户主动连接且有权访问的 Telegram 群，把消息连同来源证据一起保留，输出供人工审核的候选项——候选项或评分不是事实认证——最终决定由人做出，并且不会自动联系群成员。关于渠道复核如何与制品证据分离，见 Telegram 商业信号情报支柱。
关键事实：日期、数字与它们不能证明什么
- SLSA v1.2 规范——SLSA 项目发布，2026 年 8 月 3 日访问（slsa.dev/spec/v1.2/）；SHA-256 46edf6…e7e3ae。以轨道与等级组织逐级增强的供应链安全保证，推荐包括来源证明在内的证明格式。
- 来源证明 v1.2——2026 年 8 月 3 日访问（slsa.dev/spec/v1.2/provenance）；SHA-256 9a176a…0e51e44。可验证的信息，追踪制品到其于何处、何时、如何被生产；构建来源证明把构建输出追溯到源代码，源代码来源证明追溯源修订与变更管理过程。
- 构建来源证明 v1.2——2026 年 8 月 3 日访问（slsa.dev/spec/v1.2/build-provenance）；SHA-256 04a97c…170f647。Build Level 1 要求 buildDefinition 与 runDetails；runDetails 要求 builder。
- Telegram 隐私政策——当前政策页，2026 年 8 月 3 日访问（telegram.org/privacy）；SHA-256 9ae1e9…253786b。机器人是独立第三方服务；消息访问可选且在界面中显示；第三方机器人开发者应征得许可。
测量语境：SHA-256 值是内容指纹，用于确认引用的页面与访问日期检索到的版本一致。版本与日期锚定证据；它们不度量买方意图，访问日期也不是买方侧的合规截止日。
FAQ
买方点名 SLSA，就意味着需要来源证明生成吗？
不是。点名 SLSA 是点名目标标准，来源证明生成只是四条路线之一。按五字段记录分流——制品与摘要、构建平台、目标等级、签名方或验证方、验收方式——多数字段缺失时先发澄清记录。
单凭一份文档就能获得 SLSA 等级吗？
不能。v1.2 构建来源证明 schema 为 Build Level 1 要求 buildDefinition 与 runDetails（含 builder），但这些字段是格式要求；内容可信度取决于构建平台与 builder 身份背后的签名方。文档描述一个等级，并不授予它。
承诺服务之前，我应该先发回什么？
一份简短澄清记录，列出五个字段：制品与摘要、构建平台、目标 SLSA 等级、任何现有证明，以及确切的验收测试——谁验证、用什么规则、对照哪个等级。
本周值得做的下一步：把五字段记录做成单页模板，附一段可复制粘贴的澄清消息。这样下一条点名 SLSA 的准入请求，一次往来就能完成分流，而不是来回三次。
常见问题
买方点名 SLSA，就意味着需要来源证明生成吗？
不是。点名 SLSA 是点名目标标准，来源证明生成只是四条路线之一。按五字段记录分流——制品与摘要、构建平台、目标等级、签名方或验证方、验收方式——多数字段缺失时先发澄清记录。
单凭一份文档就能获得 SLSA 等级吗？
不能。v1.2 构建来源证明 schema 为 Build Level 1 要求 buildDefinition 与 runDetails（含 builder），但这些字段是格式要求；内容可信度取决于构建平台与 builder 身份背后的签名方。文档描述一个等级，并不授予它。
承诺服务之前，我应该先发回什么？
一份简短澄清记录，列出五个字段：制品与摘要、构建平台、目标 SLSA 等级、任何现有证明，以及确切的验收测试——谁验证、用什么规则、对照哪个等级。 本周值得做的下一步：把五字段记录做成单页模板，附一段可复制粘贴的澄清消息。这样下一条点名 SLSA 的准入请求，一次往来就能完成分流，而不是来回三次。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
