4. 漏洞情报采集与优先级判定

漏洞修复的第一道难题不是“怎么修”，而是“先修哪个”。一个中等规模企业每月可能收到数千条漏洞告警，其中真正需要立即处置的往往不足百分之几。如果按扫描器给出的严重级别从高到低排队，团队会被大量“高危但无人利用”的漏洞拖住，而真正被攻击者盯上的漏洞反而排在后面。本节要解决的就是：把分散在多个漏洞库、威胁情报源、利用可能性指标和业务资产信息中的数据汇聚起来，形成一份可执行的修复优先级排序。

多源漏洞库接入：先解决“同一漏洞多个身份”的问题

漏洞情报的原始来源通常包括：厂商安全公告（如微软 MSRC、Oracle CPU）、国家漏洞库（NVD、CNNVD）、开源生态公告（GitHub Advisory、OSV）、漏洞利用情报（Exploit-DB、Metasploit 模块、CISA KEV 目录）以及商业威胁情报源。这些来源对同一个漏洞可能给出不同的编号和描述，因此接入的第一步是建立标识映射。

核心标识是 CVE 编号，但并非所有漏洞都有 CVE。例如某些 Linux 发行版补丁只带发行版自己的编号（如 RHSA-2024:1234、USN-6789-1），某些商业产品公告只有厂商内部 ID。工程上通常维护一张映射表，把厂商公告 ID、发行版公告 ID、CVE、CWE 关联起来。接入时按“公告 → 受影响产品与版本区间 → CVE → CVSS 向量”的链路解析，而不是只抓一个严重分数。

版本区间解析是接入中最容易被低估的环节。NVD 的 CPE 匹配经常出现漏配或过配，直接依赖会导致误报。更稳妥的做法是同时保留厂商公告中的“受影响版本 < 修复版本”语义，在资产侧用实际安装版本做区间判断。下面是一个简化的映射记录示例：

{
  "source": "vendor_msrc",
  "advisory_id": "MSRC-2024-0512",
  "cve": ["CVE-2024-21412"],
  "product": "Windows Defender SmartScreen",
  "affected": "< 1.0.240101.10001",
  "fixed": "1.0.240101.10001",
  "cvss_v3": {"base": 8.1, "vector": "AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N"},
  "cisa_kev": true,
  "epss": 0.71
}

威胁情报融合：把“可能被利用”变成“正在被利用”

CVSS 描述的是漏洞本身的技术严重性，不描述现实世界的利用活跃度。威胁情报融合的目标是补上这一层。最直接可用的信号是 CISA KEV（已知被利用漏洞目录）：进入 KEV 意味着该漏洞已在真实攻击中被利用，处置优先级应显著提升。其次是 Exploit-DB、Metasploit、GitHub PoC 仓库中是否出现可用的利用代码，以及暗网、蜜罐、EDR 遥测中是否出现相关攻击行为。

融合时要注意情报的时效性和可信度。一条“某漏洞存在 PoC”的推文与一个可稳定复现的 Metasploit 模块，权重完全不同。工程上可以给不同来源设定置信度权重，例如：KEV 目录 1.0、厂商确认在野利用 0.9、Metasploit 模块 0.8、公开 PoC 仓库 0.6、仅有讨论 0.3。融合结果不是简单相加，而是取最高可信信号作为“在野利用”判定，其余作为辅助证据。

EPSS：用概率量化“未来 30 天被利用的可能性”

EPSS（Exploit Prediction Scoring System）由 FIRST 组织维护，输出 0 到 1 之间的概率值，表示某 CVE 在未来 30 天内被利用的估计概率。它基于大量历史利用数据训练，比 CVSS 更贴近现实。例如 CVE-2021-44228（Log4Shell）在爆发期 EPSS 接近 0.97，而很多 CVSS 9.8 的漏洞 EPSS 长期低于 0.01。

EPSS 的使用要点有三个。第一，它是概率不是严重性，不能替代 CVSS，二者应组合使用。第二，EPSS 会随时间变化，需要定期刷新，不能只在接入时取一次。第三，EPSS 对没有 CVE 的漏洞不适用，这类漏洞要靠厂商公告和资产匹配单独处理。实践中常见的组合判断是：CVSS ≥ 7.0 且 EPSS ≥ 0.1，或进入 KEV 目录，即进入高优先级候选池。

业务影响面分析：把技术风险翻译成业务风险

同样一个漏洞，落在对外暴露的支付网关和落在内网测试机上，业务影响完全不同。业务影响面分析要回答四个问题：资产承载什么业务、暴露面有多大、数据敏感度如何、中断后的损失是什么。这些信息通常来自 CMDB、资产台账、网络分区图和业务影响分析（BIA）结果。

一个可操作的量化方式是给资产打三个维度分：暴露度（互联网直接暴露 3 分、DMZ 2 分、内网可达 1 分、隔离区 0.5 分）、数据敏感度（核心数据 3 分、内部数据 2 分、公开数据 1 分）、业务关键度（核心业务 3 分、支撑业务 2 分、一般业务 1 分）。三者相乘得到资产影响系数，再与漏洞侧评分相乘，得到最终优先级分数。

下面这张图展示了从多源接入到优先级排序的完整数据流，以及各环节的关键判断点。

形成可执行的修复优先级排序

把上述四类数据合到一起后，排序不是简单按分数从高到低，还要考虑修复窗口和依赖关系。一个实用的做法是分档：P0 为 KEV 命中或确认在野利用且资产影响系数高的漏洞，要求 24 小时内处置；P1 为 EPSS 较高且暴露面大的漏洞，要求 7 天内处置；P2 为 CVSS 高但暂无利用情报的漏洞，纳入常规补丁周期；P3 为低风险漏洞，按季度批量处理。

排序结果还需要可解释。运维人员看到“这个漏洞排第一”时，应能立刻知道原因：是因为进了 KEV、EPSS 高，还是因为资产是核心支付系统。因此输出中应保留各维度原始值和加权过程，而不是只给一个最终分数。下面是一份可直接参考的优先级排序表结构示例：

优先级	CVE	CVSS	EPSS	在野利用	资产影响系数	综合分	处置时限
P0	CVE-2024-21412	8.1	0.71	KEV	18（互联网+核心数据+核心业务）	高	24 小时
P1	CVE-2024-3400	10.0	0.42	Metasploit	12（DMZ+内部数据+支撑业务）	较高	7 天
P2	CVE-2024-2887	8.8	0.03	无	6（内网+内部数据+一般业务）	中	30 天
P3	CVE-2024-1234	5.5	0.01	无	2（隔离区+公开数据+一般业务）	低	90 天