供应商说遵循 NIST SSDF：四组证据该怎么核对
把供应商的 NIST SSDF 说法落到具体版本、实践、制品、负责人和采购节点，分别核对组织准备、软件保护、安全生产与漏洞响应证据。
重点监测信号
- 供应商说自己遵循 NIST SSDF，却没有指出具体产品版本、实践编号或可复核制品
- 采购决定已有日期，产品安全和研发团队却说不清谁负责提供证据
- 买方要求一个成熟度分数，但 SP 800-218 给出的是基于结果的实践，不是认证等级
供应商说“我们遵循 NIST SSDF”，只能算一条待核实的声明。真正能支持采购复核的记录，应写明软件和版本、对应的 NIST SP 800-218 实践、支撑制品及负责人，并说明这份制品要支持哪一次采购、上线或验收决定。
**安全软件开发框架（Secure Software Development Framework，SSDF）**是美国国家标准与技术研究院（NIST）发布的一组基于风险的安全开发实践。1.1 版把实践分成准备组织、保护软件、生产安全软件和响应漏洞四组。NIST 没有把 SSDF 定义成供应商认证，也没有给出一个适用于所有组织的统一成熟度分数。
先钉住产品版本，框架声明才有审查价值
软件供应链安全咨询业务负责人可能在已授权的采购、产品安全和研发 Telegram 群里看到供应商答复。真正容易错过的不是“SSDF”三个字，而是采购委员会已经把一条没有证据的回答用于某个版本的准入决定。
下面是一组说明判断方法的复合片段，不是真实客户消息或商业结果：
“问卷写着符合 SSDF。”
“安全团队周四前要证据，研发现在只有上次构建的链接。”
这两句话没有产品、版本、实践编号、合同要求、制品负责人和验收门槛。供应商可能已经做得很好，只是问卷没有附件；也可能确实缺少证据。第一轮应问：这份材料支持哪个版本、哪一项 SSDF 任务？
这个问题能把框架从模糊标签变成有限工作范围。咨询方需要复原当前采购决定所需证据，而不是凭一段群聊给供应商整个研发组织打分。
四组实践先分负责人，再谈完整程度
NIST SP 800-218于 2022 年 2 月发布，列出了实践、任务和示例实施方式。四组实践背后往往是不同负责人和不同证据。
| 实践组 | 解决什么问题 | 可作为起点的制品 | 单份制品不能证明什么 |
|---|---|---|---|
| Prepare the Organization（PO，准备组织） | 建立岗位、要求与支持流程 | 安全要求、岗位分工、开发环境政策、培训记录 | 某个版本是否真的执行了控制 |
| Protect the Software（PS，保护软件） | 防止代码和制品被篡改或越权访问 | 代码库权限、签名配置、制品完整性记录、归档政策 | 交付制品是否就是审核过的制品 |
| Produce Well-Secured Software（PW，生产安全软件） | 把安全纳入设计、编码、审查、测试和发布 | 威胁模型、代码审查、测试结果、依赖记录、发布批准 | 后续变更是否使结果失效 |
| Respond to Vulnerabilities（RV，响应漏洞） | 发现、评估、修复并披露漏洞 | 接收政策、分诊记录、修复工单、安全公告、复盘记录 | 是否发现并修复了所有相关漏洞 |
这张表不是新合规清单。它只是根据 SSDF 四组实践拆分证据责任。代码库设置主要回答软件保护；威胁模型和测试主要回答安全生产；漏洞披露政策主要回答漏洞响应。采购需要看到它们如何连接，不能只收一组没有上下文的截图。
站内的安全软件确认表证据请求讲的是特定美国联邦确认场景。SSDF 的使用范围更广，不能把所有私营采购问卷都当成 CISA 联邦确认表。
六栏版本证据单让另一名审核者能复现结论
每一条重要声明单独占一行：
- **产品与版本：**产品、组件、版本、构建号或服务修订号。
- **SSDF 对应项：**供应商采用的实践与任务编号，以及它自己的原话。
- **制品：**稳定文档、系统记录或导出文件；只有文件名、没有来源位置还不够。
- **负责人和日期：**责任人或团队、创建日期、最近一次实质更新日期。
- **范围和限制：**材料证明什么，排除了哪个系统、环境或时间段。
- **买方事件：**问卷截止、合同关口、版本验收或风险审查及其日期。
例如，签名后的构建来源记录可以把制品连接到构建流程，却不能证明威胁建模已完成、每个依赖都经过审查或漏洞响应有效。SLSA 来源证明接入需求解决的是这个更窄的问题。它可进入某一栏，不能替代整张 SSDF 图。
供应商回答最常断在四个地方
第一处是对象不明：“平台”可能指托管服务、移动应用、命令行软件或一个组件。第二处是时间不明：本月更新的政策不一定能说明去年交付版本。第三处是证据替换：政策写“应该怎样做”，版本记录写“某次实际做了什么”，两者回答不同问题。
第四处是自造分数。买方可能要求“SSDF 三级”，但 SP 800-218 1.1 版没有定义通用供应商等级。组织可以建立自己的 profile（实践组合）或评分方法，但必须公开口径、标准与证据窗口，不能把内部结果写成 NIST 认证。
公开确认、问卷回答和合同陈述还可能带来不同责任。技术审核者可以整理制品，采购、安全和法务负责人必须根据真实合同决定剩余不确定性是否可接受。
群消息只能保住时间，不能证明供应商符合 SSDF
TOP Prospect 可在用户主动连接且有权访问的 Telegram 群中发现、合并和排序相关片段，保留原文、来源与时间供人复核。当前生产版的新匹配目标只能保存配置，尚不会自动生成新候选。
产品不能查看供应商代码库、认证制品、颁发 SSDF 证书、联系发言者或决定合同验收。人工审核者仍需取得材料、验证来源并填写版本证据单。Telegram 商业 Signal 工作流说明了产品整理与人工判断的分界。
关键事实
- NIST 于 2022 年 2 月发布 SP 800-218，也就是 SSDF 1.1 版。
- 四组实践分别是 PO、PS、PW 和 RV，每组再列实践与任务。
- SSDF 是基于风险的指导，不是 NIST 供应商认证或通用成熟度总分。
- 版本证据单至少要保留产品、实践、制品、负责人、日期、范围和买方事件。
- 政策、过程记录和版本制品互相补充，单份材料通常不能证明广泛实施。
常见问题
NIST 会按 SSDF 给供应商发认证吗？
不会。NIST SP 800-218 提供一组基于风险的安全软件开发实践，不是 NIST 供应商认证，也没有通用合规总分。
SSDF 的四组实践是什么？
分别是 Prepare the Organization（准备组织）、Protect the Software（保护软件）、Produce Well-Secured Software（生产安全软件）和 Respond to Vulnerabilities（响应漏洞）。1.1 版在每组下列出实践和任务。
买方第一轮应该索取什么证据？
先确认产品与版本、供应商声称对应的 SSDF 实践或任务、支撑制品、责任人、制品日期，以及这些材料要支持的采购决定。
一份制品能否证明完整实施 SSDF？
通常不能。构建记录、威胁模型或漏洞政策只能支持有边界的说法；更广泛的实施需要结合供应商真实研发环境核对多组实践。
TOP Prospect 编辑团队于 2026 年 8 月 19 日复核。SSDF 名称和四组实践依据 NIST SP 800-218 1.1 版。供应商实施、合同范围与验收仍由相关负责人根据实际材料决定。
常见问题
NIST 会按 SSDF 给供应商发认证吗？
不会。NIST SP 800-218 提供一组基于风险的安全软件开发实践，不是 NIST 供应商认证，也没有通用合规总分。
SSDF 的四组实践是什么？
分别是 Prepare the Organization（准备组织）、Protect the Software（保护软件）、Produce Well-Secured Software（生产安全软件）和 Respond to Vulnerabilities（响应漏洞）。1.1 版在每组下列出实践和任务。
买方第一轮应该索取什么证据？
先确认产品与版本、供应商声称对应的 SSDF 实践或任务、支撑制品、责任人、制品日期，以及这些材料要支持的采购决定。
一份制品能否证明完整实施 SSDF？
通常不能。构建记录、威胁模型或漏洞政策只能支持有边界的说法；更广泛的实施需要结合供应商真实研发环境核对多组实践。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
