动态调用场景如何验证漏洞可达性?

静态调用图里找不到漏洞函数，不等于动态调用场景下它不会执行。反射、依赖注入、按字符串加载模块，以及由配置决定的分支，都可能让实际调用路径落在分析引擎的覆盖范围之外。验证漏洞可达性时，关键不是再跑一次版本匹配，而是回答一个更具体的问题：在当前构建产物和运行配置下，应用入口能否经由动态调用触及漏洞所在函数。

先核对分析对象。构建产物中的组件版本、运行时配置和实际加载的模块，应与扫描所依据的 SBOM 对得上；若组件可能在运行时引入，仅凭构建阶段的清单不足以下结论。随后定位动态调用的选择机制：调用目标来自固定配置、条件分支，还是运行时输入？这些来源不同，能够排除的路径范围也不同。

验证应围绕可能触发该路径的入口设计测试，并记录实际加载的模块、选中的调用目标，以及漏洞函数是否执行。观察到函数执行，可以确认该路径可达，但不能单凭这一点认定漏洞可利用；还要核对触发漏洞所需的输入和条件。反过来，测试期间没有观察到调用，也不能直接证明不可达，因为测试可能没有覆盖另一种配置或输入。

因此，“不可达”应是一项有边界的判断：明确它适用于哪些构建产物、配置和入口，哪些动态路径已经核查，哪些仍未覆盖。未覆盖的反射目标、传递调用或跨语言调用，应保留为待调查项，不宜降级。只有排除了相关动态路径，才把判定依据连同 SBOM 和分析结果留档，供后续配置或依赖变化时复核。