版本清单核查：从资产名称走向可比对的组件事实

版本清单是软件安全事件更新的基础。若只能回答“我们大概在用这个产品”，就难以判断通告是否相关。有效清单不必一开始就覆盖所有细节，但应能够定位运行实例、组件版本、部署方式和责任边界。信息会随发布变化，应设定定期刷新方式。

确定清单粒度

桌面软件、服务器服务、容器工作负载和依赖库适合采用不同粒度。对外服务通常需要记录服务名、节点、监听入口和运行版本；容器则还应记录镜像标签或不可变摘要；应用依赖可记录锁定文件或构建产物。粒度过粗会掩盖差异，过细又会使维护停滞，应从高暴露资产优先开始。

同一产品可能有社区版、企业版、云端托管版或内部封装版，简称常常不足以判断版本关系。清单中应保存包名、发布渠道、版本字符串和采集时间，并保留原始输出。若通告只给出上游版本，内部封装产品需向维护方确认对应关系，不能自行假定。

可把资产采集接入部署流程、配置管理或周期性扫描，并记录采集失败的范围。新增实例、退役实例和临时测试环境都可能改变暴露面。每次重大安全事件后，把人工查询中发现的缺字段加入清单改进项，比无限扩展字段更有效。

清单应能导出“受影响候选列表”，再由责任人确认真实用途和配置条件。处置完成后更新版本与验证时间，避免下次事件仍把已升级实例列为待处理。对无法自动发现的组件，应记录人工确认的有效期。

版本清单不是静态表格，而是持续反映运行事实的记录。越能准确回答“哪里运行着什么”，安全通告的处置越能建立在证据上。