版本比对的纪律
把组件版本与公开漏洞库匹配，是评估里最容易被做错的一步：只要版本落在受影响区间就打高危，是典型的过度定级。正确顺序是四步：拿到精确版本与构建号，查厂商公告确认受影响范围与修复版本，核对本地配置是否满足利用前提（组件是否启用、是否暴露、依赖是否可被影响），最后才定级。漏洞库条目存在滞后与误标，厂商公告是最终依据。
基本信息
| 顺序 | 精确版本 → 公告影响范围 → 本地前提核对 → 定级 |
|---|---|
| 依据优先级 | 厂商公告优先，漏洞库作为检索与索引补充 |
| 记录内容 | 公告编号、受影响版本范围、修复版本、核对结论 |
| 定级影响因素 | 暴露面、认证要求、是否满足利用前提、能否直接验证 |
| 表达要求 | 标注「已核实」或「待核实」，不含糊表述 |
典型使用场景
- 组件清单梳理后的漏洞匹配环节
- 为客户提供修复版本与升级路径
- 评估停服或不再维护组件的长期风险
- 回应客户「扫描器报告了这个问题」的复核请求
- 为报告中的版本类结论提供可核对的依据
匹配步骤
匹配步骤
1. 采集组件精确版本（含构建号与补丁级别）
2. 查厂商公告确认受影响版本范围与修复版本
3. 核对本地配置是否满足利用前提（组件启用、暴露面、依赖链）
4. 结论中引用公告编号，标注「已核实」或「待核实」
5. 不满足前提的，写入「观察项」而非缺陷条目结论分类
| 核对结果 | 定级思路 |
|---|---|
| 版本命中且前提满足且可验证 | 按实际影响定级，附验证证据 |
| 版本命中但前提不满足 | 降级为观察项，说明条件 |
| 版本命中但无法确认配置 | 标注待核实，说明所需信息 |
| 修复版本已安装 | 记录证据并说明不成立的原因 |
数据库条目存在滞后与误标：以厂商公告为最终依据，漏洞库用于检索与索引，两者不一致时以公告为准。
不要把「版本命中」写成「存在漏洞」：前者是匹配结果，后者需要满足利用前提并可被验证，表述差异直接影响定级可信度。