摘要

  • CVE ID 和相应记录使不同主体可以指向同一个漏洞；它们本身不证明存在补丁、发行版已经打包，或某个资产已经完成修复。
  • 编号保留、公开记录、供应商公告、下游软件包、KEV 优先级信号和本地修复都是不同作者留下的不同证据。
  • 一份从记录到修复的简短凭据能保留这些交接，而不把公共协调基础设施误写成安全结论。

同一编号解决的是指认问题，不是运行结果

CVE Program 对自身功能的描述很有节制。CVE ID 及相应的 CVE Record 使多个主体能够确信自己所指的是正确的漏洞；CVE Numbering Authority（CNA）则在自身范围内获授权分配 ID 并发布记录。 CNA 运行规则 这是实际的协调成果。没有共同引用，研究报告、供应商公告、扫描结果、软件包变更说明和内部工单即使涉及同一缺陷，也可能彼此错过。

但共同指认不是共同运营状态。分配 ID 的主体不会因此选择供应商的修复代码；发布公告的供应商不会因此为所有下游构建软件包；构建软件包的发行版不会因此知道每个客户资产是否安装；修改一个资产的运营者也不会因此证明所有依赖服务已脱离风险。每一步都可以重要，但任何一步都不能无声地借用为下一步的证据。

官方流程已经把第一个边界写出。它区分发现、报告、ID 保留，以及在具备最低必要信息后发布记录；它也区分 RESERVED、PUBLISHED 和 REJECTED。 CVE Program 流程 这些是编号和公共记录的状态，并不是所有可能受影响机器的修复阶段。

FAQ 进一步说明了这一点。一个 Reserved-but-Public ID 可以已在公共资源中被使用，而详细记录仍处于 RESERVED；DISPUTED 标记让读者知道存在分歧，却不由 Program 替各方判断谁正确；REJECTED 记录继续保留，是为了说明该 ID 和记录不应使用。 CVE Program FAQ 这些状态没有一个回答某个产品是否已有适用补丁、某项本地配置是否在范围内，或某家机构是否完成了更改。

公开记录有其证据范围

PUBLISHED CVE Record 比单独流传的编号更强：它以人和机器可读的形式公开描述与参考资料。但“已公开”有精确含义。CNA 规则要求，在相应记录发布之前或同时，互联网上必须已有公开参考；记录本身不得成为漏洞的第一次公开披露。 CNA 运行规则 因此，发布把漏洞说明与公共参考连接起来；它不交付供应商补丁，也不签发运营方的修复证明。

这不是贬低公共记录。它可以让读者找到应审阅的公告、产品范围或技术说明，也可以让采购、通知和防御讨论使用相同对象。可是它不能告诉读者哪一份不可变源代码修订真正修正了问题、某个发行版是否回移了改动、哪一个软件包携带它、该软件包是否适用于资产，或补偿性控制是否改变了暴露面。这些答案分别出现于别的系统和别的责任面。

CVE Services 的说明也保持了这一范围：它向 CNA 提供保留 ID 和发布 CVE Record 的自助工具。 CVE Services 文档描述的是 CVE 内容管理。从它的存在推导供应商已交付、资产清单正确、变更已获批准、软件已安装或修复已验证，是把引用层的功能扩张为执行层的权力。

一个把“CVE 已发布”与“已修复”并列的仪表板很容易遮蔽这个差别。前者可用公共记录核对。后者需要指定资产、版本或配置、获批动作、执行时间、验证观察以及可负责的主体。把两件事涂成同一种颜色，得到的是简洁，却失去了可追溯性。

优先级信号不是完成声明

CISA 将 Known Exploited Vulnerabilities Catalog 描述为已知在野利用漏洞的权威来源，并建议机构把它作为漏洞管理优先级框架的一项输入。 CISA KEV Catalog 这是安排调查和资源的重要信号；它不是每一家机构暴露状态或完成修复的总账。

来源的机构范围也不能被省略。CISA 的 Binding Operational Directive 22-01 为受覆盖的 Federal Civilian Executive Branch 机构规定修复义务和截止框架。 CISA BOD 22-01 它不会因为目录公开而自动变成所有企业、项目和运营者的普遍义务。把“进入 KEV”写成“任何人都逾期”，抹掉了该指令明示的范围，也跳过了判断某个资产实际状态所需的证据。

反向推论同样不成立。供应商公告已存在，并不能说明某项本地资产可以按此路径更新。仍要判断资产是否受影响、发行版是否携带相关组件、更改是否获批、维护窗口是否可用、补偿控制实际覆盖什么，以及怎样验证结果。这不是把公共信息当作无用；而是承认公共信息不能代替承担运行后果的主体作出这些选择。

让凭据沿着责任边界走

合适的改进不是要求 CVE 变成部署系统，也不是要求 CISA 为每个组织签发变更结论，而是保存一张足够小的“记录到修复”凭据：CVE ID 与记录修订、CNA 与状态、供应商公告及不可变修复参考、下游发行版和软件包边界、资产适用性证据、获批动作、部署或补偿控制、验证结果，以及剩余风险的负责人。

每个字段回答不同的问题。记录修订说明讨论对象；供应商材料说明上游主张；软件包边界说明实际交付物；资产证据说明本地问题是否存在；变更和验证说明运营者做了什么、看到了什么；剩余风险负责人使未解决例外不会藏进一个绿色汇总状态。

这份凭据是 Daniel Kade 的编辑建议，不是新的 CVE 规则。它与 Lu Heng 所强调的区分一致：参与和信息可以构成证据，却不能自动取得对承担后果一方的授权。 The Multi-Stakeholder Mirage 一项判断越接近正在运行的系统，其关键证据越应来自系统与负责运营者，而不应停留在上游标签。 Running-Code Primacy

这份记录不能证明什么

这些来源不证明任何具名 CVE 可被利用、已被修正、已被打包、适用、安装、缓解或关闭。它们没有选择供应商、产品、版本、资产、机构、利用事件、事故、期限或客户。CVE 状态、公开参考、供应商公告或 KEV 条目在这里都不是某家机构暴露、违规或修复结果的证明。所提凭据属于编辑指导，并非 CVE Program、CISA、供应商或监管机关的要求。

来源