2. 漏洞信息采集渠道梳理与去重策略
三类来源的字段差异与采集要点
同一批漏洞公告在厂商公告、CVE/NVD、内部扫描器三类来源中，字段结构、标识方式和粒度都不同。去重前必须先明确各来源能提供什么、缺什么，否则合并规则会建立在错误假设上。
| 来源 | 主标识 | 关键字段 | 典型粒度 | 主要缺口 |
|---|---|---|---|---|
| 厂商公告 | 厂商公告号（如 MSRC-2024-001） | 受影响产品、版本区间、补丁链接、发布时间 | 一个公告覆盖多个 CVE | 无 CVSS、无资产关联 |
| CVE/NVD | CVE 编号 | CVSS 向量、CWE、参考链接、描述 | 一个 CVE 对应一个漏洞 | 无内部资产、无补丁状态 |
| 内部扫描器 | 扫描器内部编号（如 SCAN-2024-0871） | 资产 IP、端口、服务、插件 ID、证据 | 一个资产一条记录 | 无 CVE 映射、无厂商上下文 |
采集时需保留原始来源标识，不能提前丢弃。厂商公告号、CVE 编号、扫描器内部编号三者都要作为候选键进入合并流程，否则后续无法回溯。
去重与合并规则设计
去重不是简单按标题字符串比较，而是按“漏洞身份”判断。本案例采用三级匹配策略，优先级从高到低：
- CVE 精确匹配：若两条记录都含 CVE 编号且相同，判定为同一漏洞，直接合并。
- 厂商公告号 + 产品匹配：若厂商公告号相同且受影响产品一致，判定为同一公告下的同一漏洞，合并。
- 资产 + 插件 ID + 端口匹配：内部扫描器记录之间，若资产 IP、插件 ID、端口三者一致，判定为重复扫描结果，合并。
合并时字段取值遵循“信息互补”原则：CVE 编号、CVSS 向量优先取 CVE/NVD；补丁链接、受影响版本优先取厂商公告；资产 IP、端口、证据优先取内部扫描器。冲突时以更具体来源为准，并在合并记录中保留来源列表。
合并后统一条目字段：统一编号、CVE 编号、厂商公告号、扫描器编号列表、漏洞标题、受影响产品与版本、CVSS 向量、严重性、资产 IP 列表、端口列表、补丁链接、来源列表、首次采集时间、最后更新时间。
模拟数据与去重验证
以下用 6 条模拟记录演示去重过程。数据为教学示例，非真实漏洞。
记录1（厂商公告）：公告号 MSRC-2024-001，产品 Windows Server 2019，CVE-2024-1111，补丁 KB5001001
记录2（CVE/NVD）：CVE-2024-1111，CVSS 8.8，CWE-787
记录3（内部扫描器）：SCAN-0871，资产 10.0.1.15，端口 445，插件 90012，CVE-2024-1111
记录4（内部扫描器）：SCAN-0872，资产 10.0.1.15，端口 445，插件 90012，CVE-2024-1111
记录5（厂商公告）：公告号 MSRC-2024-002，产品 Exchange Server 2019，CVE-2024-2222，补丁 KB5002002
记录6（内部扫描器）：SCAN-0873，资产 10.0.2.20，端口 443，插件 90045，无 CVE
按规则执行：记录1、2、3、4 均含 CVE-2024-1111，合并为一条统一条目；记录3与记录4资产、端口、插件一致，属于重复扫描，合并后资产 IP 列表去重为 [10.0.1.15]；记录5独立为一条；记录6无 CVE，按资产+插件+端口规则单独保留，标记为“待映射 CVE”。
去重效果验证指标：
- 原始记录数：6
- 合并后条目数：3
- 去重率：(6-3)/6 = 50%
- 合并条目来源覆盖：条目1覆盖厂商公告、CVE/NVD、内部扫描器三类来源
- 未映射条目：1 条（记录6），需进入后续 CVE 映射流程
验证时重点检查：合并后是否丢失任一来源的原始编号；资产 IP 列表是否去重；CVE 编号是否唯一；无 CVE 记录是否被错误合并到其他条目。
可复用的去重检查清单
| 检查项 | 判断标准 | 不通过时的处理 |
|---|---|---|
| CVE 唯一性 | 同一 CVE 在清单中只出现一次 | 回溯匹配规则，检查是否漏合并 |
| 来源编号保留 | 合并条目含所有原始来源编号 | 补充来源列表字段 |
| 资产 IP 去重 | 同一资产不重复出现在同一插件下 | 按资产+插件+端口二次去重 |
| 无 CVE 记录标记 | 无 CVE 记录单独保留并标记待映射 | 不得强行合并到其他条目 |
| 去重率可计算 | 原始数、合并数、去重率三者一致 | 重新核对原始记录数 |
完成上述流程后，统一漏洞条目清单即可作为后续 CVE 映射、严重性评分和优先级排序的输入。本案例的关键在于：先保留原始标识，再按三级规则合并，最后用去重率和来源覆盖验证效果。