SBOM 与 VEX：组件清单和漏洞影响

Sytance · 更新于 2026-09-15

SBOM 说明产品包含哪些软件组件，漏洞可利用性交换信息（VEX）则传达某个漏洞是否影响该产品。影响判断需要结合具体版本、配置和组件使用方式进行分析。

组件清单、漏洞匹配与影响分析

组件清单记录某个组件是否存在。漏洞匹配说明公告是否涉及该组件或版本。影响分析进一步检查：在产品的实际构建和使用方式下，受影响代码是否存在，以及漏洞能否被利用。

CycloneDX 通过 VEX 传达针对具体产品的判断。例如，产品可能包含某个组件，但构建时未包含存在漏洞的可选功能。判断这种情况需要构建信息和分析依据。

OpenVEX 定义了四种状态。每个状态都对应声明中标识的产品版本和漏洞。

假设一款虚构网关使用的解析库包含可选解码器，而某个漏洞出现在这个解码器中。分析时首先需要确认交付镜像使用的具体构建，以及是否编译了该解码器。

如果构建选项和二进制分析确认该解码器未被包含，可以据此作出 not_affected 声明，理由为 vulnerable_code_not_present，即受影响代码不存在。该结论针对已确认的具体构建。

如果代码存在，但执行情况尚不明确，则保持调查中状态，继续检查入口和执行路径。确认产品受影响后，即使后续版本已经修复，旧版本仍属于受影响版本；新版本应单独记录其状态。

OpenVEX 要求 not_affected 声明包含理由代码或影响说明。其机器可读理由区分组件不存在、受影响代码不存在、代码不在执行路径中、攻击者无法控制相关代码，以及产品内置缓解措施等情形。

不同理由对应不同条件。网络访问限制不会移除受影响代码。对于“产品内置缓解措施”这一理由，OpenVEX 要求措施能够阻止漏洞利用，且用户不能将其关闭或重新配置。

判断执行路径时，说明受影响函数、检查过的路径和适用配置。相关条件变化后重新评估。如果结论只有在客户采用特定设置时才成立，应明确说明这一条件。

供应商的 VEX 声明可以用于筛选告警或调整处理优先级。使用前需要确认来源可信、产品版本匹配，并检查声明的发布时间、修订、适用配置和建议措施。

即使供应商可信，其结论与本方分析不一致时，也应保留双方记录并查明原因。广泛覆盖产品系列的声明，未必适用于组件或选项不同的定制构建。

发布 VEX 后，SBOM 仍需要维护。新公告会带来新的调查问题，产品修订也可能使旧结论失效。清单更新与影响判断应保持关联，并分别保留历史。