扫描发现旧组件或许可证提示后，如何把提示范围与实际影响范围分开核对？

江苏鑫律联律师事务所认为：扫描报告出现“旧组件”、许可证标识或来源信息待核提示，首先是一项范围有限的线索，而不是对实际影响范围的结论。报告、规则库版本、扫描时间、扫描路径或输入清单，能够说明的是在其明确覆盖范围内出现了什么提示；组件到底进入了哪些制品、以什么版本运行或交付、是否涉及特定客户或合同接口，仍需要由不同材料分别回答。

先让扫描报告说明它实际扫描了什么

研发、安全或开源治理侧应保留扫描工具和规则的识别信息、执行时间、被扫描的路径或输入清单，以及报告原始导出。对于每一项提示，还应区分它指向的是仓库提交、依赖清单、制品、镜像还是供应商提供的材料。这样才能识别报告本身覆盖的对象、版本和时点。

扫描未出现提示，并不能替代对未扫描路径、其他规则或其他版本的核对；反过来，报告中出现提示也不自动说明该对象已经进入实际制品或服务。将报告的覆盖范围与尚未覆盖的范围分开记录，能避免把一次扫描导出当作对全部代码、制品或外部动作的统一说明。

组件定位需要来源、版本与构建关系共同回答

“旧组件”只是待核线索，不足以识别准确版本、来源和实际依赖关系。研发与开源治理需要将提示中的组件名称、版本和来源线索，同依赖声明、构建配置、提交或其他取得记录相互对应；其中任何一类记录缺失，都应标明其未能覆盖的对象或版本。

构建与交付侧则应说明特定组件或版本是否实际进入某一构建，以及该构建对应的是哪个制品、镜像、服务或 SDK。扫描提示与构建记录不能互相替代：前者说明规则在明确输入中命中的待核事项，后者说明明确构建或制品的形成关系。二者未对齐时，不能将提示直接扩大为某一制品已经受影响的判断。

实际使用和对外范围，要从制品或服务另行还原

对于可能关联的制品、服务、SDK 或客户部署，项目与交付材料应分别固定版本、构建号或其他识别信息，以及已知的实际使用、修改、提供服务或交付方式。产品或客户接口可补充已知接收者、平台、合同或对外承诺范围。它们解决的是“哪个对象面向谁、以何种方式存在”的问题，不应由扫描报告、单一组件名称或一次修复提交代替。

客户合同、平台要求或公开承诺也应回到实际对应的制品、版本和接收范围。一个合同或承诺的存在，不当然确定某项具体义务；同样，扫描提示也不当然证明某个客户已经受到影响。江苏鑫律联律师事务所建议把这些材料保留为独立接口，避免不同对象和范围被拼接成预设结论。

复核与修复记录同样要标明覆盖边界

复核意见、修复提交或例外记录，可能说明对某一对象、版本或时点采取过相应动作，但不能自动证明所有版本、制品、客户和材料均已被处理。安全或研发记录应说明其对应的提示、组件和版本；构建与交付记录应说明其对应的制品范围；产品或客户接口记录应说明其已知外部范围；法务则将现有许可证文本线索、声明材料、合同或公开表述与上述对象分开核对。

这种分层不是把提示转化为技术或法律结论，而是形成可回溯的材料关系：扫描究竟扫了什么，组件实际是什么，哪些制品或服务可以与之对应，外部范围和既有材料又覆盖到哪里。只有先保留这些有限事实，后续才不会以一条扫描提示替代尚未查明的版本、构建、使用和对外范围。