依赖变更后的VEX复核机制

一次依赖升级可能修复旧漏洞，也可能引入新的传递依赖；即使漏洞组件的版本没变，调用链或部署配置的变化也可能推翻此前的“不可利用”判断。因此，VEX 不能被当作对某个 CVE 的永久豁免，它的结论只对当时的构建产物和使用条件成立。

复核的起点是比较变更前后的 SBOM，而不是只看直接依赖有没有升级。需要确认组件版本、传递依赖和基础镜像是否变化，再把受影响组件关联到已有的 VEX 记录。新增或版本变化的组件应重新扫描；组件未变但调用关系、对外暴露面或运行配置发生变化时，也要重新检查原有的可达性证据。尤其要关注此前标为 not_exploited 的记录：当初支撑降级的条件是否仍然成立，比状态名称本身更重要。

复核结果应区分“证据仍有效”和“尚未完成分析”。前者可以维持原判断，并记录本次构建与复核依据；后者不应沿用旧结论放行，可先转为 under_investigation，交由责任人复核。若发现漏洞路径已可达，再按 exploitable 对待；确认修复后，则要核对实际构建产物，不能仅凭依赖声明中的版本变化标为 fixed。

自动化可以负责发现变更和发起复核，却不宜把“分析器没找到路径”等同于“路径不存在”。动态加载、反射或跨语言调用可能超出可达性分析的覆盖范围；证据不足时，不降级是更稳妥的门禁原则。将每次构建的 SBOM、原始扫描结果、VEX 判断及其依据一同留存，后续才有条件解释：依赖已经变了，为什么这条漏洞仍被允许通过。