SBOM仍可能带来误报：漏洞扫描需判断代码可达性

SBOM描述软件在特定阶段包含哪些组件、版本及依赖关系；漏洞扫描利用这些信息匹配已知漏洞，产生待核实的告警。组件版本命中漏洞记录，并不能直接说明产品会调用受影响的代码。要判断告警对交付产品的影响，还需要确认清单准确、组件匹配正确，并检查代码路径与触发条件。

CycloneDX的SBOM指南将清单描述为组件及依赖关系的库存，并区分构建前、构建时和构建后的信息。这个阶段差异决定了清单能代表什么：项目文件表达依赖意图，构建过程解析实际版本，构建后的产物则可能经过排除、替换或重新打包。扫描器只能分析它收到的组件记录，无法凭一次漏洞匹配补齐清单中遗漏的内容。

清单先要对应实际交付物

同一项目在源代码、锁定文件和最终交付物中，可能呈现不同的组件集合。项目声明文件通常列出直接依赖及允许的版本范围；锁定文件记录一次依赖解析得到的具体版本和传递依赖；交付物还可能包含手工引入的库，或已经剔除声明文件中的部分组件。因此，清单格式正确，只能说明数据可以交换，不能说明它完整反映了采购方收到的产品。

生成阶段也影响版本判断。构建前的清单适合发现计划使用的组件，却可能尚未确定最终解析结果；构建时取得的依赖信息更接近实际选择；构建后分析可以核对打包结果，但工具能识别什么，仍取决于产物形式和识别依据。若扫描的是旧版本清单，告警可能指向早已替换的库；若传递依赖没有进入清单，扫描结果又可能漏掉相关漏洞。

交付前的清单核验可以集中在会改变漏洞判断的几项信息：

记录清单对应的产品版本、构建批次和生成阶段，使组件记录能够追溯到具体交付物。
核对直接依赖及其带入的传递依赖，保留准确版本和依赖关系，而不只列出顶层包名。
将锁定文件中的解析结果与构建产物对照，查明被排除、被替换及额外打包的组件。
对修改版或分叉版组件记录来源与变更依据，避免把上游版本号直接当作交付版本的完整身份。

这些核对同时防止两类相反的问题：漏列组件会让后续扫描看不到潜在风险，多列未交付的组件则可能制造无关告警。组件总数相近也不足以证明清单准确；真正关键的是每条记录能否对应交付物中的组件，以及依赖关系有没有把它带入产品。

标识符把组件接到漏洞情报，但匹配仍有边界

扫描器需要先确定清单中的组件身份，才能查询漏洞情报。CycloneDX的漏洞识别说明列出purl、CPE等标识符及其匹配用途，并建议开源软件优先使用purl；不同漏洞情报来源支持的标识符并不完全相同。purl侧重包所属的生态、名称和版本，CPE常用于标识漏洞数据库收录的软件产品，二者不能仅凭名称相似就视为等价。

标识符缺失或填错，会把清单质量问题带进扫描结果。同名包可能来自不同生态或发布方；修改过的组件也可能保留上游名称，却已有不同的补丁状态。匹配过宽时，不相关的漏洞记录会进入告警列表；匹配不到时，已有漏洞可能不会出现。对有争议的告警，应保留扫描器使用的组件标识符、版本范围和漏洞记录，才能分辨问题出在组件身份、情报映射，还是产品影响判断。

即便身份无误，漏洞记录中的“受影响版本”通常仍是组件层面的判断。它提示该版本可能包含有问题的代码，却没有说明代码是否被打包进当前产品、位于哪个模块，也没有说明运行配置是否满足触发条件。把版本匹配结果直接写成“产品可被利用”，会跳过这些影响结论所需的证据。

代码可达性缩小告警范围，也有分析盲区

组件确实存在、版本也确实命中时，受影响函数仍可能从未被应用调用。一项SBOM漏洞管理研究覆盖2414个开源仓库；其中人工核验的案例得到92.0%的告警误报率，在相同验证条件下，函数调用分析过滤了61.9%的误报。误报率来自人工核验的案例，并非全部仓库的统一比率，也不能直接套用到其他产品或扫描器。

可达性分析关注应用入口能否沿调用路径到达受影响的函数或模块。以一个明确的假设为例：应用交付了某个存在已知漏洞的库，却只使用库中与该漏洞无关的功能。扫描器按组件版本发出告警是合理的初筛；要判断当前应用是否受影响，还须定位漏洞所涉及的代码，再核对调用路径、输入来源、配置和运行环境。

“没有找到调用路径”也需要结合分析方法理解。静态调用图可能看不到反射、动态加载或依赖外部配置的路径；运行时观测则只能覆盖实际执行过的场景。漏洞公告如果没有指出具体受影响函数，自动化工具也难以直接完成函数级判断。因此，可达性证据能帮助缩小调查范围，但不足以单独证明任何使用情形都安全。

用VEX记录产品层面的影响判断

完成代码与运行条件核验后，团队可以用VEX记录某个漏洞对特定产品版本的影响状态及理由。例如，结论可以说明受影响代码未进入交付物，或代码虽存在却无法从产品的调用路径触达。这样的记录把“组件命中漏洞”与“产品是否受影响”分开，便于供应商向采购方说明为何采取修复、继续调查或判定不受影响。

VEX承接的是已有分析结果，不会自动验证结论。记录中应能识别产品版本、漏洞和判断依据；若后续构建重新引入了相关模块，启用了此前关闭的功能，或部署条件发生变化，原来的影响判断就需要重新审视。对于仍缺少函数信息或调用证据的告警，保留待调查状态比直接写成“不受影响”更准确。

把生成验证与漏洞研判接成两个阶段

流程的交接点，是一份身份信息足够明确、并已与交付物核对的SBOM。前一阶段解决“产品实际包含什么”，后一阶段解决“这些组件的已知漏洞是否影响产品”。两类问题分开记录，才能在告警出现时定位清单遗漏、标识符错误或代码影响判断的具体分歧。

生成并验证清单：利用已解析的依赖和构建信息生成SBOM，记录产品版本与生成阶段；核对直接依赖、传递依赖和实际构建产物。对每个组件检查版本、来源及适用的purl或CPE，标出尚未识别清楚的组件和交付物差异。
扫描并研判告警：先追溯“组件清单→标识符匹配→漏洞情报”的依据，再调查受影响代码是否存在、能否被调用，以及配置和输入是否满足触发条件。用可达性分析和人工核验形成产品影响判断；证据充分时记录VEX，证据不足时保留待调查事项。

漏洞情报更新时，即使产品没有重新构建，也可能出现需要研判的新记录；产品重新构建时，则应重新确认清单和既有影响结论。这样，告警处置依据的是当前交付物与当前证据，而不是某次扫描留下的永久标签。