版本与公告交叉验证是什么
仅凭版本号判定「脆弱」或「已修复」都会失真：Linux 发行版常把安全补丁回移植（backport）到旧版本号上，因此包版本低于上游修复版并不代表未修复；反过来，部分软件自报版本与实际加载的库不一致。可靠做法是版本、发行版补丁记录、上游公告范围三方面交叉确认。
基本信息
| 判定链 | 版本 → 发行版补丁状态 → 上游公告受影响范围 → 实际影响确认 |
|---|---|
| 常见误报 | 版本号低于修复版但补丁已回移植 |
| 常见漏报 | 自编译版本未走包管理，补丁状态无人跟踪 |
| 证据形式 | 变更日志中的 CVE 记录、公告版本区间 |
确认已修复（以发行版为例）
确认已修复（以发行版为例）
apt changelog openssl 2>/dev/null | grep -i CVE | head # Debian/Ubuntu 包变更日志
rpm -q --changelog openssl | grep -i CVE | head # RHEL 系 RPM 变更日志
rpm -q openssl ; openssl version # 包版本与运行时版本对比
# 上游版本：对照官方安全公告中的受影响版本范围
# 三者一致才能下结论，缺一项就标为待确认典型使用场景
- 扫描结果研判：把版本类命中逐条核实，减少误报进入工单
- 审计应答：向检查方提供包变更日志与公告比对记录
- 漏洞复现确认：判断手中环境是否真的可被利用
- 情报初筛后确认：候选资产列表的逐项落地核实
- 自编译组件治理：建立独立台账并规定版本与补丁记录方式
结论与动作
| 情况 | 判定 | 动作 |
|---|---|---|
| 版本低于修复版但有回移植记录 | 已修复 | 记录证据，关闭条目 |
| 版本在受影响区间且无补丁记录 | 未修复 | 进入修复流程 |
| 版本信息无法获取 | 待确认 | 登录核实并补台账 |
| 自编译且无变更记录 | 待确认 | 按上游公告版本区间人工判断 |
自编译安装的中间件要建立独立台账：包管理器管不到它们，版本与补丁状态需要人工维护，否则漏洞来了只能逐个登录确认。
扫描器的版本指纹识别本身会出错（尤其经过代理、CDN 或反向定制后），把指纹当结论是误报的主要来源之一。