波仔
🛡️ 第四章 系统漏洞的防范
📄 一句话概括

漏洞评估的量化指标（漏洞风险评估系统）不是"给漏洞打分"这么简单：CVSS 回答"技术上有多严重"，EPSS 回答"未来 30 天被利用的概率有多大"，KEV 回答"是不是已经在被利用"，SSVC 回答"我现在该做什么"——这四个信号解决的是四个不同的问题，而只用 CVSS 排序会造成大量的无效工作。

📝 本节和前面几节的关系

4-2 留了一个问题："一个补丁日要修 206 个漏洞，怎么排先后？" 这一节就是回答这个问题的。

它也是 4-9 的下游：那一节讲"清单从哪来"，这一节讲"清单一堆数字怎么用"——没有排序，扫描结果就只是一份无法执行的列表。

一、四个信号，各回答一个问题

先记住每个指标负责回答什么，这是这一节最重要的框架：

信号 回答的问题 取值
CVSS v4.0 技术上有多严重 0.0 ~ 10.0
EPSS 未来 30 天被利用的概率 0.000 ~ 1.000
CISA KEV 是不是已经在被利用 在目录里 / 不在
SSVC 该采取什么动作 Act / Attend / Track

四个问题的性质完全不同：

看一个漏洞的优先度，最少要看前三个。只看 CVSS 的后果，下面用数字说明。

二、只看 CVSS 会浪费多少力气

这是一组很能说明问题的数字（来自 FIRST 的口径）。问的是同一个问题："我要抓住最要紧的那些漏洞，得处理多少量？"

策略 要处理的比例 覆盖到的比例 效率
修所有 CVSS 7.0 以上 57.4% 82.2% 1.43
修所有 EPSS 0.1 以上 2.7% 63.2% 23.41

效率的定义是"覆盖率除以处理量"。两行相除：23.41 ÷ 1.43 ≈ 16.3——也就是说，同样是"抓住最要紧的被利用漏洞"，用 EPSS 排序只需要处理 2.7% 的量，而用 CVSS 排序要处理 57.4%。

把这句话说得更直白一点：如果按 CVSS 排序，你 100% 的精力里有大约 17 分之 16 花在了"严重但不会被打"的漏洞上。

这不是说 CVSS 没用——它回答"严重不严重"很准确，但它不回答"会不会被打"。而修补工作的瓶颈从来不是"分不清严重程度"，而是"量太大"。

三、动手 Demo：把四个信号和真实分布摆在一起

下面这段脚本把"四个信号"、"两种排序策略的效率"、"真实世界的分布"摆在一起：

# 效率 = 覆盖率除以处理量
cvss_eff = 82.2 / 57.4      # 修所有 CVSS 7.0 以上
epss_eff = 63.2 / 2.7       # 修所有 EPSS 0.1 以上
print("效率差 {:.1f} 倍".format(epss_eff / cvss_eff))

实跑输出：

一、四个信号各回答一个问题
  信号            回答的问题                    取值
  ----------------------------------------------------------------------------------------------
  CVSS v4.0       技术上有多严重                0.0 ~ 10.0
  EPSS            未来 30 天被利用的概率        0.000 ~ 1.000
  CISA KEV        是不是已经在被利用            在目录里 / 不在
  SSVC            该采取什么动作                Act / Attend / Track

二、只看 CVSS 会浪费多少力气（FIRST 的口径）
  策略                      要处理的比例    覆盖到的比例    效率
  ----------------------------------------------------------------------------------------------
  修所有 CVSS 7.0 以上      57.4%           82.2%           1.43
  修所有 EPSS 0.1 以上      2.7%            63.2%           23.41

  效率 = 覆盖率除以处理量。两行相除：16.3 倍。
  → 同样是抓最要紧的，用 EPSS 排序只要动 2.7% 的量。

三、真实分布（2026-09-27，覆盖 380,066 个 CVE）
  EPSS 低于 0.01（几乎没人会打）      61%
  EPSS 达到 0.1 （值得优先）          4.5%
  EPSS 达到 0.5 （很可能会被利用）    1.1%
  → 绝大多数漏洞只是【在册】，不构成实际威胁。

四、KEV 目录有多小
  CISA KEV 条目（2026-09-25）    1,726 条
  NVD 收录的 CVE                约 400,000 条
  → 比例不到 1/200。被确认真在被利用的，是极小的一撮。

五、日本这边的对应体系（教材提到的 JVN）
  JVN iPedia 累计收录（2026 年第二季度末）  290,167 条
  2026 年第二季度新增                        13,131 条
  本季最常报的弱点                          释放后重用 749 个（第一）
  → JVN 由 JPCERT/CC 与 IPA 运营，同时给出 CVSS v3 与 v4 两套评分。

读这个输出：

四、⚠️ 2026 现状

30 秒实验

今天做两个动作，各 15 秒：

  1. 随便找一条最近看到的漏洞告警（新闻、厂商公告、系统提示都行），只做一件事：把它对应到本节那四个信号上，看看它在每个信号下是什么状态。比如：它的 CVSS 是多少？EPSS 有没有数据（一般会在漏洞库页面上标出）？是否在 KEV 里？ 你会发现很多让你紧张过的漏洞，EPSS 其实低得惊人——这个动作的作用是校准你的直觉。
  2. 对你正在维护的系统，定一条"自己的 KEV 规则"：写出"什么条件下一律当天处理"。最简版本可以就用一句： "凡是已经进 KEV 的、且我这个系统能被外网访问的，当天处理。" 把它写下来（一条就够）——这一步的意义是把"排序"从每次临时判断变成一条固定规则，而固定规则才可能被执行。

这一节要带走的一句是：CVSS 告诉你"有多严重"，EPSS 告诉你"会不会被打"，KEV 告诉你"已经有人在打"，SSVC 告诉你"现在做什么"——只顾第一个，会把大部分力气花在没人会碰的漏洞上。

常见误区

  1. 错误：CVSS 分越高就越该先修。——纠正：CVSS 只回答"如果被利用，后果有多严重"，它完全不回答"会不会被利用"。这一节的数字很直接： 按 CVSS 7.0 以上排序，要处理 57.4% 的漏洞；按 EPSS 0.1 以上排序，只要处理 2.7%——而两者覆盖到的"真正要紧的漏洞"差不多（82.2% 对 63.2%）。 效率差 16.3 倍。 现实中的经典反例也很多： 一个 CVSS 只有 5.8 分的网络设备漏洞，因为已被实际利用直接进了 KEV（4-2）。所以正确的排序是"先看有没有被实际利用（KEV），再看被利用概率（EPSS），最后才看严重程度（CVSS）"。
  2. 错误：EPSS 分数低就说明这个漏洞不用管。——纠正：EPSS 说的是"未来 30 天被利用的概率"，它是一个概率，不是保证。即使分数很低，也有两个理由不能直接忽略：① 我的系统可能有特殊情况（比如这个组件正好暴露在公网、或者我在一个被针对的行业）；② EPSS 是基于"全网数据"的预测，它不知道"有没有人在专门打你"。 所以 EPSS 值的用法是"排序"，不是"过滤"——也就是说： 它帮你决定"先做哪个"，而不是"哪个可以不做"。 这一点和 4-3 里"零日不可预测"是配套的： 任何统计模型都覆盖不了"针对你的那一次"。
  3. 错误：这么点 KEV 条目（1,726 条），跟 40 万个 CVE 比，说明"被真利用的漏洞很少，我不用太紧张"。——纠正：这个比例的读法正好相反。"不到 1/200"说明的是"KEV 的门槛极高"（要有实际的利用证据才能进），而不是"威胁很小"——恰恰相反，正因为只有这 1,726 条是"已经确认被利用"，它们才是最值得优先处理的那一撮。 而且要注意规模感的另一面： 1,726 条里，2026 年前九个月就新增了 247 条（超过 2025 年全年的 245 条）——"入册速度在翻倍"这个事实，比"总量小"更值得关注。 另一个数字更能说明"这一撮的破坏力"： CISA 的复盘显示，大多数入侵并不是用了国家级零日，而是"扫描并利用了已知漏洞"（4-11）——这些"已知漏洞"里的相当一部分，就在 KEV 里。
  4. 错误：日本有个 JVN，跟我没什么关系。——纠正：JVN（JVN iPedia）的价值在于它是"另一套独立归档"，而在实际工作中，"多一个数据源"有几个具体用途：① 它是日文体系的漏洞库，很多日本厂商产品的漏洞信息以它为准（如果你用过日本设备或软件，这里是第一个该查的地方）；② 它同时给出 CVSS v3 与 v4 两套评分（在 v3 到 v4 的过渡期，这一点很实用）；③ 它的统计口径可以作为交叉验证——本节 Demo 第五部分显示，它这一季最常报的弱点是"释放后重用"（749 个）和 XSS（697 个），与全球口径一致。所以"用哪个漏洞库"这件事的正确回答是"主要用一个，同时知道其他几个在哪、怎么查"。
自测三问（点开对答案） 1. CVSS、EPSS、KEV 三个信号，为什么必须一起看？ —— **因为它们回答三个完全不同的问题，缺一个都会误判**。**CVSS 回答"如果被利用，后果多严重"——它不知道有没有人在用；EPSS 回答"未来 30 天被利用的概率"——它是预测，不是事实；KEV 回答"是不是已经被实际利用"——这是事实，但覆盖面极窄（1,726 条 vs 40 万条）。** **一个典型的错判是：** **只看 CVSS 会把大量"严重但没人碰"的漏洞排到前面**（**本节数据：按 CVSS 排序要处理 57.4% 的量，效率只有 1.43**）；**只看 EPSS 会漏掉"已经发生的事"**（**因为 KEV 是事实、EPSS 是概率，事实优先于概率**）。**正确的顺序是：** **先问"在不在 KEV"（事实）→ 再问"EPSS 多高"（概率）→ 最后用"CVSS + 我的暴露情况"定档**（**SSVC 就是把这个顺序固化成流程**）。 2. "效率差 16.3 倍"这个数字，在实际工作中意味着什么？ —— **它意味着"排序方式"本身就是一个生产力问题**。**具体来说：** **假设一个团队一年能处理的漏洞数量是固定的，那么用什么排序方式，决定了这些处理量里有多少落在了"真正会被利用的漏洞"上。** **用 CVSS 排序，要处理 57.4% 的漏洞才能覆盖 82.2% 的关键漏洞；用 EPSS 排序，只要处理 2.7% 就能覆盖 63.2%。** **两者的差距不是"谁更准"，而是"同样的力气，一个花在了刀刃上，一个花在了刀背上"。** **更实际的一层意义是：** **当"一个补丁日要修几百个漏洞"成为常态时，"全都尽快打"根本不可行**（4-2）——**所以排序不是"锦上添花的优化"，而是"让工作能够进行下去的前提"。** 3. 为什么"大多数入侵来自已知漏洞"这个事实，让漏洞排序变得更重要而不是更不重要？ —— **因为它把攻击的"来源"和防御的"优先级"连在了一起**。**如果攻击主要来自无法预测的零日，那排序的意义就有限**（**因为你不知道要防哪个**）；**但事实是：大多数入侵来自"已知的、有补丁的漏洞"**（4-11、4-3）。**这就意味着：** **你的损失几乎全部集中在一份"可枚举的清单"上**——**而既然清单是可枚举的，那么"先修哪个"就直接决定了你会不会出事。** **换一种说法：** **漏洞管理不是"和未知的敌人赛跑"，而是"在一份已知清单上做取舍"**——**而取舍的质量，取决于你用的排序信号。**

相关笔记