📚 课程目录第3章漏洞信息采集与标准化

3. 漏洞信息采集与标准化

漏洞管理的第一道工程难题，不是“怎么修”，而是“怎么把散落在各处的漏洞信息收拢成一份可信、可比、可去重的清单”。如果采集与标准化没做好，后面的定级、派单、修复、复测都会建立在错误的数据之上。本节围绕三个问题展开：漏洞信息从哪里来、不同来源的标识体系如何对齐、以及如何做归一化与去重。

一、漏洞信息的四类来源

企业实际面对的漏洞数据，通常来自四个方向，它们的格式、粒度和可信度差异很大：

扫描器输出：主机漏扫（如 Nessus、OpenVAS、Nmap NSE）、Web 漏扫（如 AWVS、AppScan）、容器镜像扫描（如 Trivy、Clair）、SCA 组件扫描（如 Dependency-Check）。特点是量大、字段固定、含插件 ID 与端口/路径等定位信息，但存在误报。
人工与渗透测试：渗透报告、SRC 提交、众测平台、内部安全评估。特点是数量少但质量高，常含业务逻辑漏洞，格式不统一，多为自然语言描述。
外部情报源：厂商安全公告（如微软 MSRC、Oracle CPU）、CVE/NVD、CNVD、CNNVD、GitHub Advisory、Exploit-DB、Twitter/公众号等。特点是提供“是否已被利用”“是否有 EXP”等上下文，但需要与资产关联才有意义。
内部反馈：研发自测、代码审计（SAST）、CI/CD 流水线门禁、运维巡检。特点是贴近代码与配置，能定位到具体提交或文件行号。

这四类来源的字段结构完全不同：扫描器给的是“插件 ID + 主机 + 端口”，情报源给的是“CVE + CVSS + 影响版本”，渗透报告给的是“业务场景 + 复现步骤”。标准化要做的，就是把它们映射到同一套内部模型。

二、标准标识体系：CVE、CNVD、CNNVD 与 CVSS

漏洞标识是跨来源对齐的“主键”。常见标准包括：

标识	维护方	格式示例	主要用途
CVE	MITRE / NVD	CVE-2021-44228	全球通用漏洞编号，NVD 提供 CVSS、CPE 影响范围
CNVD	国家信息安全漏洞共享平台	CNVD-2021-95914	国内漏洞收录，含事件型与通用型
CNNVD	国家信息安全漏洞库	CNNVD-202112-1069	国内漏洞库，与 CVE 有映射关系
CVSS	FIRST	CVSS:3.1/AV:N/AC:L/...	严重程度评分，非唯一标识

关键点：CVE 是标识，CVSS 是评分，两者不能混用。同一漏洞可能同时有 CVE、CNVD、CNNVD 三个编号，也可能只有 CNVD 没有 CVE（如部分国产软件漏洞）。标准化时必须建立“多编号 → 内部漏洞 ID”的映射表，否则同一漏洞会被重复统计。

实践建议：内部漏洞主键不要直接用 CVE，而应使用自增的内部 ID（如 VUL-2024-000123），再通过映射表关联 CVE/CNVD/CNNVD 及扫描器插件 ID。这样即使某来源没有标准编号，也能纳入统一管理。

三、数据归一化：把异构字段映射到统一模型

归一化的目标是让每条漏洞记录都具备可比较、可派单、可统计的最小字段集。建议的内部模型至少包含：

标识层：内部 ID、CVE、CNVD、CNNVD、扫描器插件 ID。
资产层：资产 IP/域名、端口、URL、组件名与版本、责任人、业务系统。
漏洞层：漏洞名称、类型（如 SQL 注入、反序列化）、CVSS 向量与分值、利用条件、是否有公开 EXP。
状态层：发现时间、来源、当前状态（待确认/已确认/修复中/已修复/误报）、复测结果。

归一化的具体操作，通常包括字段抽取、枚举值统一、时间格式统一、资产关联四步。以 Nessus 输出为例，其 plugin_id、host、port、severity 需要映射为内部字段；severity 的 0-4 等级要转换为统一的“严重/高/中/低/信息”枚举；host 若是 IP，还需通过 CMDB 反查责任人与业务系统。

# 归一化伪代码示例
raw = {
  "plugin_id": 156032,
  "host": "10.20.3.15",
  "port": 8080,
  "severity": 4,
  "plugin_name": "Apache Log4j RCE"
}
normalized = {
  "internal_id": "VUL-2024-000123",
  "cve": "CVE-2021-44228",
  "asset_ip": "10.20.3.15",
  "asset_owner": "订单中台组",
  "port": 8080,
  "severity": "严重",
  "source": "Nessus",
  "status": "待确认"
}

四、去重：同一漏洞的多种“面孔”

去重是标准化中最容易出错的一环。同一漏洞可能以多种形式出现：

同源重复：同一扫描器多次扫描，产生多条相同记录。
跨源重复：Nessus 和 AWVS 都发现了同一个 Log4j 漏洞，但插件 ID 不同。
编号重复：同一漏洞同时有 CVE-2021-44228 和 CNVD-2021-95914。
资产重复：同一 IP 的多个端口或同一域名的多个路径，指向同一组件漏洞。

去重策略建议采用“分层键”方式：第一层用 CVE/CNVD/CNNVD 做精确匹配；第二层用“资产 + 组件 + 漏洞类型”做模糊匹配；第三层对无编号漏洞用“资产 + 路径 + 参数 + 漏洞类型”做指纹匹配。对于跨源重复，优先保留信息最完整、可信度最高的记录，其余记录作为“关联证据”挂接，而不是直接丢弃。

五、工程落地中的常见坑

第一，把 CVSS 当唯一排序依据。CVSS 反映的是漏洞本身的技术严重性，不反映资产重要性。一个 CVSS 9.8 的漏洞如果位于无数据的测试机，优先级可能低于 CVSS 6.5 但位于核心支付系统的漏洞。标准化时应保留 CVSS，但排序要结合资产权重。

第二，去重过度导致漏报。如果只按 CVE 去重，同一 CVE 在不同资产上的多条记录会被合并成一条，导致修复范围被低估。正确做法是：去重键应包含资产维度，即“同一漏洞在同一资产上只保留一条”，而不是全局只保留一条。

第三，忽略时间戳与状态同步。扫描器每次扫描都会产生新记录，如果不做增量比对，清单会不断膨胀。建议以“资产 + 漏洞指纹”为键做增量更新：已存在的记录更新最后发现时间，新出现的记录新增，已修复的记录标记状态而非删除。

注意：CNVD 与 CNNVD 的编号并非一一对应，部分漏洞只有其中一个编号。建立映射表时，应以 CVE 为桥梁，无法关联 CVE 的国内漏洞单独维护，避免强行合并造成错误。

总结来说，采集与标准化的核心是“统一主键、统一字段、统一去重规则”。只有把这一步做扎实，后续的定级、派单、修复、复测才有可靠的数据基础。建议在工程实现上，把归一化与去重做成独立的服务或流水线阶段，输入原始扫描结果与情报数据，输出标准化的内部漏洞清单，并保留完整的字段映射日志，便于排障与审计。