「CVE-2021-44228」「CVE-2017-5638」这样的编号，在每一则重大事故新闻里都会出现。本文讲解它们的含义，以及个人开发者现实可行的追踪方法。
编号怎么读
CVE 编号由 3 个部分构成。编号本身不含严重程度的含义（严重程度是另外一回事）。
为什么需要它
漏洞每天都被大量发现。如果叫法各不相同，「你说的那个漏洞」和「我修好的那个漏洞」是不是同一个就分不清了。有了 CVE 这个通用 ID，新闻、修复补丁、扫描器、数据库就能可靠地指向同一个漏洞。这就是对策的起点。
编号由谁分配
CVE 由 CVE 计划（CVE Program）管理，由美国的 MITRE 运营、美国 CISA 出资支持。编号本身由世界各地获得授权的 CNA（CVE 编号分配机构）来分配：软件厂商、安全研究机构、各国的 CERT 等，总数达数百个。在日本，JPCERT/CC 就是其中之一。
CVE 记录有状态之分。「Reserved（预留）」表示编号已占下但细节未公开；「Published（已公开）」表示内容已公开；「Rejected（已拒绝）」表示因重复或错误而撤回。新闻里出现了编号却查不到细节时，它可能仍处于预留状态。
CVE、NVD、JVN 的区别
同一个 CVE 编号，在不同地方查到的信息不一样。
| 名称 | 运营方 | 包含的内容 | 用途 |
|---|---|---|---|
| CVE（cve.org） | MITRE（CISA 支持） | 编号、简短说明、参考链接 | 查正式编号与概要 |
| NVD | 美国 NIST | CVE 信息加上 CVSS 分数和受影响产品 | 查分数和哪些产品受影响 |
| JVN | JPCERT/CC 与 IPA | 日本产品的漏洞，附日语说明与对策 | 日语详情、日本产品 |
| KEV | 美国 CISA | 已确认被利用的 CVE，附修复期限 | 确定优先级 |
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 编号。编号不需要背下来；关键在于：用编号检索，就能把各处关于同一个漏洞的信息汇集起来。
| CVE 编号 | 通称／产品 | 相关事故 |
|---|---|---|
| CVE-2014-0160 | Heartbleed（OpenSSL） | Heartbleed：服务器内存被泄露 |
| CVE-2017-5638 | Apache Struts | Equifax：未打补丁，1.47 亿人的数据外泄 |
| CVE-2018-13379 | VPN 设备 | 半田医院：据报道是勒索软件的入侵入口 |
| CVE-2021-44228 | Log4Shell（Log4j） | Log4Shell：通过没人注意到的间接依赖被使用 |
| CVE-2023-34362 | MOVEit Transfer | MOVEit：危害波及 2,700 多个组织 |
| CVE-2024-3094 | XZ Utils | XZ Utils：发布文件中被植入后门 |
编号一旦公开，攻击者读到的也是同样的信息。在 Equifax 和半田医院的事故中，从修复发布到遭到入侵之间都有一段时间。在你应用修复之前的这段时间，就是可能被攻击的时间。
个人开发者现实可行的追踪方法
靠人力把所有 CVE 都追一遍是不可能的，而那个漏掉的疏忽会直接变成事故。→ 已公开的 CVSS 10.0 被漏看数月的故事
所以要让机器来盯。
常犯的错误
- 看了新闻就凭人力判断「我们应该没事」
- 只看
package.json里的写法来估危险程度 - 用「以后再更新」搪塞，不定截止期限
让机器来盯
- Dependabot（GitHub）：对依赖中相关的 CVE 自动发 PR 通知
- osv-scanner（Google）：检查锁文件，在 CI 中只需一步
- 以实际运行的版本来判定（不要轻信下限写法）
要点在于以「实际运行的版本」来判定。package.json 里的下限写法可能与实际运行的版本不同（RCE 的事故中，这也曾是误判的原因）。
如何检查自己的环境
查一个 CVE 编号讲的是什么
把新闻里出现的编号输入 CVE / KEV 查询，就能一次看到它的 CVSS 分数、被利用概率（EPSS）以及是否在 KEV 中。
列出影响你依赖的 CVE
把锁文件（package-lock.json、pnpm-lock.yaml 等）载入 依赖漏洞扫描器，即可得到相关 CVE 和 GHSA 的清单。npm 项目用 npm audit 也能做到同样的事。
服务器和设备按产品与版本对照
对于服务器、VPN 设备等不在包管理器里的产品，查看厂商的安全公告，确认你运行的版本是否受影响。如果受影响，就为更新定下期限（→ CVE 的实际处置流程）。
出处（一手资料）
- CVE Program, "Process" — cve.org（由 CNA 分配编号以及 CVE 记录的状态）
- NIST, "National Vulnerability Database" — nvd.nist.gov
- JPCERT/CC and IPA, "JVN (Japan Vulnerability Notes)" — jvn.jp
- CISA, "Known Exploited Vulnerabilities Catalog" — cisa.gov
接下来读什么
- 术语：什么是 CVSS（严重程度的打分标准） / 什么是 RCE
- 对策：搭建追踪 CVE 的机制（机器监控）
- 实务：先修哪个 CVE（确定优先级与期限）
- 事故：Equifax — 放任已知 CVE