"这个扫描结果需要 VEX"，现在值得安排销售沟通吗？
群消息里的扫描结果不等于可成交的 VEX 服务请求——五步资格链帮你补齐产品、CVE、组件路径、可利用性状态、理由负责人和发布日期，再决定是否推进销售沟通。
简短回答：不，现在还不值得。一条被粘贴到群里的扫描发现只是对话的起点，不是一个合格的 VEX 服务请求。在把它推到销售通话之前，你至少需要五条原消息几乎一定没有的信息。
三个必须先对齐的概念
VEX 请求里反复出现三个核心实体，负责筛选线索的人需要足够理解它们，才能认出少了什么。
**Vulnerability Exploitability eXchange（VEX，漏洞可利用性交换）**是一份结构化的证明文件，声明某个特定产品是否受已知漏洞影响。它把一个状态——例如 affected（受影响）、not_affected（不受影响）或 under_investigation（调查中）——与一段解释原因的理由配对（CISA，《VEX 最低要求》，2023 年 4 月 21 日发布）。没有确切的产品和版本，VEX 文档根本无法编写。
**Software Bill of Materials（SBOM，软件物料清单）**是一份嵌套的组件清单，描述了一个软件产品由哪些成分组成（CISA，SBOM 资源中心，2026 年 8 月 3 日访问）。一个请求说“我们还需要 SBOM”，只告诉你对方想要的产出物类型；它不会告诉你对方是需要获取已有文件、新生成一份、格式标准化还是持续更新。把 SBOM 当作一个独立的范围确认问题来处理。
**Common Vulnerabilities and Exposures（CVE，通用漏洞与暴露）**标识符是公开漏洞的唯一编号。如果扫描输出里没有 CVE 编号，编写 VEX 的团队就没有可以评估的对象。
五步资格链
按顺序走完以下五个问题。每一步都依赖上一步的答案。
1. 原样保存扫描发现
请对方粘贴原始扫描输出——不是截图，不是总结。工具名称、扫描日期、扫描目标和完整的发现文本都很重要。一句转述如“我们在 OpenSSL 上扫出一个高危”，不会给你组件路径、CVE 和版本范围。在做任何其他事之前，先把原始发现存下来。
2. 明确产品、版本和组件路径
这是大多数群消息请求卡住的地方。“我们的 Web 应用”不是一个产品。你需要商业产品名称、版本号或构建标识符，以及受影响组件在该产品内部的路径——例如 acme-portal v4.2.1 / lib/openssl.so。OWASP CycloneDX 将 VEX 描述为传达组件“在其所使用产品上下文中的可利用性”（CycloneDX VEX 能力页面，2026 年 8 月 3 日访问）。没有这个产品上下文，你无法判断组件是否可被触及。
3. 选择受支持的 VEX 状态
CISA 最低要求列出了四种公认状态：not_affected、affected、fixed 和 under_investigation。每一种都需要配合理由。不要让扫描器的严重程度驱动这个选择：一个“严重”的扫描发现，如果受影响的功能在产品构建中不可达，其 VEX 状态可以是 not_affected。
4. 获取有证据支撑的理由和负责人
理由回答的是为什么该状态适用。可接受的理由包括 component_not_present（组件不存在）、vulnerable_code_not_in_execute_path（漏洞代码不在执行路径中）、inline_mitigations_exist（存在内联缓解措施）或 vulnerable_code_cannot_be_controlled_by_adversary（漏洞代码无法被攻击者控制）。要问：对方组织内部或产品供应商中，谁能记录这些证据并签字确认？没有归属的理由在客户 assurance 流程中没有分量。
5. 记录发布决策和日期
VEX 文档需要一个带日期的发布决策——即使状态是 under_investigation 并附有计划复核日期。没有日期，接收方无法追踪时效性。确认谁将发布声明以及何时发布。
一条示意性群消息
以下复合示例展示了一条典型请求的到达方式及其遗漏内容。所有细节均为示意性描述，不代表真实客户或实际事件。
【示意性 / 复合场景 Telegram 消息】 “Hey team——我们的客户跑了一次 Nessus 扫描，在 Apache Log4j 上扫出一个严重漏洞。他们周五前要一份 VEX。谁有空接？”
这条消息提到了扫描器和组件家族，但缺少产品、版本、CVE、组件路径、可利用性状态、理由负责人和发布日期。它是一条线索，不是已确认的服务订单。正确的回复是索要原始扫描输出和产品上下文，然后将请求分流到合适的队列。
分流路由表
当你收集到对方能提供的所有信息后，将请求分流到最短的下一步路径。
| 你手头有什么 | 分流去向 |
|---|---|
| 仅有原始扫描输出，无产品上下文 | 证据收集——索要产品、版本和组件路径 |
| 有产品上下文，无 CVE 或理由 | 证据收集——索要 CVE 和可达性分析 |
| 产品、CVE、理由和负责人均已确认 | VEX 编写 |
| 非标准产品或涉及合规问题 | 专业复核 |
| 有扫描发现但未确认受影响状态 | 后续观察——等供应商公告或漏洞利用数据成熟后再评估 |
官方来源的关键事实
- CISA VEX 最低要求（2023 年 4 月 21 日发布）： 该文件规定了 VEX 文档的最低要素，包括产品标识符、漏洞标识符、受影响状态、理由和发布日期。这些是基线互操作性字段，不是可选项。查看原文
- CISA SBOM 资源中心（2026 年 8 月 3 日访问）： SBOM 被定义为软件组件的嵌套清单。该页面将 VEX 单独描述为一种证明文件，用于说明产品是否受已知漏洞影响。一个没有进一步限定的 SBOM 请求只告诉你产出物类型，而不是工作范围。
- OWASP CycloneDX VEX 能力页面（2026 年 8 月 3 日访问）： VEX 在产品上下文中传达可利用性。单独的通用扫描结果不能确立可达性或受影响状态。查看原文
- Telegram 隐私政策（2026 年 8 月 3 日访问）： 机器人是独立的第三方服务，被添加到群组后可以在有或没有消息访问权限的情况下运行，界面会显示当前模式。第三方机器人开发者应在访问数据前请求许可。这支持将审查范围限定在用户主动连接且有权访问的群组。
一个工作示例：为什么资格链值得跑完
假设一个潜在客户转发了一条扫描告警：“CVE-2024-3094 在 xz Utils 中——严重，需要 VEX。“你按五步资格链逐一确认，发现该产品是一个内部管理后台，虽然分发了 xz 但从未调用受影响的压缩路径。可达性分析显示 vulnerable_code_not_in_execute_path。VEX 状态为 not_affected，理由已记录，内部安全团队负责发布，目标日期为 2026 年 8 月 15 日。
如果跳过资格链，同一条请求可能被直接路由到 VEX 编写环节，按 affected 处理——产出一份扭曲实际风险的声明，并浪费专业人员的时间。
资格完成后仍然未知的事项：该扫描器对此 CVE 在此产品版本上的误报率、组件路径分析是否基于最新构建版本、以及对方的下游客户是否接受以代码路径理由支撑的 not_affected 还是需要额外证据。在请求进入编写环节之前，每一项未知内容都应分配给指定负责人。
FAQ
在编写 VEX 文档之前，我需要完整的 SBOM 吗？
SBOM 描述的是 VEX 声明所引用的组件清单。已有 SBOM 可以加快组件路径识别，但它不是严格的前置条件：CISA 定义的 VEX 最低字段（2023 年 4 月 21 日）要求的是产品、版本和漏洞标识符，而不是 SBOM。如果对方既无法提供 SBOM 也无法提供组件路径，先分流到证据收集。
扫描器的严重程度评分可以替代 VEX 状态吗？
不能。扫描器给 CVE 分配一个通用的严重程度；VEX 状态则说明该 CVE 是否影响实际使用的特定产品。OWASP CycloneDX（能力页面，2026 年 8 月 3 日访问）强调，可利用性必须在产品上下文中评估。一个“严重”的扫描发现，在特定构建中可以是 not_affected。把扫描器评分当作 VEX 状态来路由，跳过了产品上下文这一步，会产生误导性的证明。
当 VEX 针对第三方组件时，谁拥有发布决策权？
构建和分发组装产品的产品供应商或组织拥有发布决策权。组件的上游可能发布自己的公告，但 VEX 状态和带日期的发布属于交付对方实际运行产品的那个实体。如果对方是最终用户组织而非供应商，先确认内部安全团队能否担任负责人，还是需要供应商参与，然后再路由到 VEX 编写。
群消息多了之后
上述资格链适合逐条处理请求。当一个安全服务团队同时监控多个群组渠道——行业论坛、用户社区、合作伙伴群——同样的不完整扫描转 VEX 请求会反复出现。在安排销售沟通之前识别缺失字段并分流每一条请求，本身就是瓶颈。
TOP Prospect 仅处理用户主动连接且有权访问的 Telegram 群组消息，产出的是供人工复核的候选项而非事实认证，由人做出最终的资格判断，且不会自动联系群成员。同时追踪多个群组中扫描发现讨论的团队，可以将它与 /zh/blog/telegram-signal-provenance/ 中描述的消息溯源方法和 /zh/blog/business-signal-confidence-scoring/ 中的置信度框架一起使用，在不完整的 VEX 请求被繁忙频道淹没之前将其呈现出来。产品主页为 /zh/telegram-business-signal-intelligence/。
**下一步：**拿出最近出现在你群组渠道中的三条扫描发现消息，列出每条遗漏了哪些信息。如果三条都至少缺少五项资格字段中的三项，在你的首次回复例行流程中加入一段简短的“我们需要什么”模板。
常见问题
在编写 VEX 文档之前，我需要完整的 SBOM 吗？
SBOM 描述的是 VEX 声明所引用的组件清单。已有 SBOM 可以加快组件路径识别，但它不是严格的前置条件：CISA 定义的 VEX 最低字段（2023 年 4 月 21 日）要求的是产品、版本和漏洞标识符，而不是 SBOM。如果对方既无法提供 SBOM 也无法提供组件路径，先分流到证据收集。
扫描器的严重程度评分可以替代 VEX 状态吗？
不能。扫描器给 CVE 分配一个通用的严重程度；VEX 状态则说明该 CVE 是否影响*实际使用的*特定产品。OWASP CycloneDX（能力页面，2026 年 8 月 3 日访问）强调，可利用性必须在产品上下文中评估。一个"严重"的扫描发现，在特定构建中可以是 `not_affected`。把扫描器评分当作 VEX 状态来路由，跳过了产品上下文这一步，会产生误导性的证明。
当 VEX 针对第三方组件时，谁拥有发布决策权？
构建和分发组装产品的产品供应商或组织拥有发布决策权。组件的上游可能发布自己的公告，但 VEX 状态和带日期的发布属于交付对方实际运行产品的那个实体。如果对方是最终用户组织而非供应商，先确认内部安全团队能否担任负责人，还是需要供应商参与，然后再路由到 VEX 编写。
资料来源与延伸阅读
- CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX) (21 April 2023)
- CISA, Software Bill of Materials (SBOM) resource hub (accessed 3 August 2026)
- OWASP CycloneDX, Vulnerability Exploitability eXchange capability (accessed 3 August 2026)
- Telegram Privacy Policy (accessed 3 August 2026)
