漏洞报告标着未审核、版本映射没写全，扫描结论能不能直接照做
漏洞报告标着未审核、版本映射没写全时，扫描结论既不能直接照做，也不应该整份忽略。这两个标记说明的是数据本身的进度与完整度，不是缺陷的真伪：未审核指的是还没经过程序语言安全团队的确认整理，映射不全指的是来源公告里的一些版本号没能换算成标准模块版本表达。正确的用法是把它们当作线索，再按三步判定顺序决定处置。
未审核标记说明的是进度，不是真伪
公开漏洞库的数据来自多个来源，既有通用漏洞编号与厂商通告，也有维护者的直接上报，进入库之前还要经过安全团队的审阅整理。带未审核状态的条目，等于告诉你：这条记录的内容尚未完成这一轮整理，后续版本区间、受影响模块名都可能被修正。
对扫描结果的影响是双向的。未审核条目可能确有其事，只是因为生态数据接入滞后还没被确认；也可能是范围写得过宽，整理后会收窄。所以未审核不等于可忽略，它只等于「需要人工确认后再排期」。
版本映射不全为什么同时造成误报和漏报
来源公告里的版本表达五花八门：有分支名、有发布标签、有发行版自定义的后缀。当这些写法换算不成标准的模块版本区间时，报告会被附上一句明确说明——存在无法自动映射的额外版本。
后果是两面的：
- 匹配不到标准区间的真实受影响版本会漏掉，形成漏报；
- 宽泛表达被强行套进标准区间时，会把没问题的版本也算进去，形成误报。
扫描工具读到这种条目时给出的命中，只能证明「你的依赖名字出现在一份没被完整翻译的报告里」，不能证明「你运行的这个版本有此缺陷」。
三步判定顺序
- 看暴露面：这条缺陷所在的模块，是否被站点实际调用。以 SQL 注入类缺陷为例，如果触发点在一个只读取、不接收外部参数的内部模块里，风险等级要重估；
- 看版本证据：把自己锁定的依赖版本、构建时记录的校验值与报告中可映射的区间逐项对照，映射不进去的部分单独标注为待确认，不直接计入结论；
- 看可达路径：从对外入口往下追一层，确认外部输入能否到达缺陷函数。能到达才进入排期，不能到达就记录理由并留待复核。
依赖清单要留下什么
按语言划分的版本表达只是起点。站点以 GoLang 与 GORM 这类框架搭起来时，构建产物里应同时保留直接依赖与间接依赖的确定版本，以及可复现的锁定文件；容器化部署时还要记录基础镜像的标识。这三样缺任何一样，下次遇到映射不全的报告，你无法回答「线上跑的到底是哪个版本」。
自家系统的版本口径也要能对上：内容管理系统当前发布版本与修复内容是可查的，例如 v3.6.6 修复了列表排序参数注入与站点切换登录凭证伪造两类问题。把应用版本与依赖版本放在同一份清单里，判定时才不用在两套记录之间来回猜。
常见问题
未审核条目能不能先升级避开风险？ 可以，但要确认升级目标版本本身在报告的可映射区间之外。盲目升到最新，可能引入新的未审核条目。
扫描工具说命中，报告说无法映射，该信谁？ 都不直接信。按可达路径自己判一次，把结论和理由落到工单里，让下一次扫描有对照基线。
要不要把未审核条目全部屏蔽掉？ 不建议。屏蔽应针对具体条目写明理由，而不是按状态批量关闭，否则真正的漏洞也会被同一规则挡掉。