「CVE-2021-44228」「CVE-2017-5638」——这正是重大事故新闻里必定出现的那串编号的真面目。从机制讲起，一直讲到个人开发者现实可行的追踪方法，从零开始解说。
编号怎么读
CVE 编号由 3 个部分构成。编号本身不含严重程度的含义（严重程度是另外一回事）。
为什么需要它
漏洞每天都被大量发现。如果叫法各不相同，「你说的那个洞」和「我修好的这个洞」是不是同一个就分不清了。有了 CVE 这个通用 ID，新闻、修复补丁、扫描器、数据库就能可靠地指向同一个漏洞。这就是对策的起点。
CVE、CVSS、KEV — 别把职责混为一谈
这三者常常一起出现，但它们回答的是不同的问题。确定优先级时三者都要用上。
| 术语 | 回答的问题 | 例子 |
|---|---|---|
| CVE | 是哪个漏洞（名字） | CVE-2021-44228（Log4Shell） |
| CVSS | 有多严重（0～10） | 10.0（最高一档） |
| KEV | 是否已被实际利用 | 列入被利用观测清单＝最高优先 |
CVSS 高≠最高优先，未必如此
分数是「最坏条件下的理论值」。在实务中要结合 KEV（是否正被实际利用） 和 你自己是否在用那个功能 一起判断。CVSS 10.0 但没在用，影响就很小；分数中等但正被利用，则是最高优先。
从分配编号到修复的流程
CVE 不是「一发现就立刻公开」，而是经过协调后才公开。大致是这样的流程。
发现与上报
预留（Reserved）
修复与公开（Published）
被利用观测（列入 KEV）
个人开发者现实可行的追踪方法
靠人力把所有 CVE 都追一遍是不可能的，而那个漏掉的疏忽会直接变成事故。→ 放任已知 CVE（CVSS 10.0）导致 1.47 亿人信息泄露的故事
所以要让机器来盯。
常犯的错误
- 看了新闻就凭人力判断「我们应该没事」
- 只看
package.json里的写法来估危险程度 - 用「以后再更新」搪塞，不定截止期限
让机器来盯
- Dependabot（GitHub）：对依赖中相关的 CVE 自动发 PR 通知
- osv-scanner（Google）：检查锁文件，在 CI 中只需一步
- 以实际运行的版本来判定（不要轻信下限写法）
要点在于以「实际运行的版本」来判定。package.json 里的下限写法是会骗人的（RCE 的事故中，这也曾是误判的原因）。
接下来读什么
- 术语：什么是 CVSS（严重程度的打分标准） / 什么是 RCE
- 对策：搭建追踪 CVE 的机制（机器监控）
- 事故：Equifax — 放任已知 CVE
FAQ
QCVE 编号怎么读？
它的形式是“CVE-公元年份-序号”。例如 CVE-2025-12345 就是 2025 年分配的漏洞。编号本身不含严重程度的含义，严重程度另由 CVSS 表示。序号并非固定 4 位，会根据需要增加位数。
QCVE、CVSS、KEV 有什么区别？
CVE 是表示“是哪个漏洞”的名字，CVSS 是表示“有多严重”的 0～10 分数，KEV 是“是否已观测到实际被利用”的清单。在确定优先级时，不应只看 CVSS 的高低，把 KEV（是否正在被攻击）看得更重才更贴近实务。
Q个人开发者要把所有 CVE 都追一遍是不是不可能？
靠人力确实不可能，漏掉就会变成事故。所以要让机器来盯。用 Dependabot（GitHub）或 osv-scanner，让它只对你自己依赖中相关的 CVE 自动通知，这才现实。