「CVE-2021-44228」「CVE-2017-5638」這類編號，在每則重大事故新聞裡都會出現。本文說明它們的含義，以及個人開發者實際可行的追蹤方法。
編號怎麼讀
CVE 編號由 3 個部分構成。編號本身不含嚴重程度的含義（嚴重程度是另外一回事）。
為什麼需要它
漏洞每天都被大量發現。如果叫法各不相同，「你說的那個漏洞」和「我修好的這個漏洞」是不是同一個就分不清了。有了 CVE 這個通用 ID，新聞、修復修補程式、掃描器、資料庫就能可靠地指向同一個漏洞。這就是對策的起點。
誰來分配編號
CVE 由 CVE 計畫負責，營運者是美國的 MITRE，經費來自美國 CISA。實際分配編號的，是全世界獲得授權成為 CNA（CVE Numbering Authority，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 都追一遍是不可能的，而那個漏掉的疏忽會直接變成事故。→ 放任已知 CVE（CVSS 10.0）導致 1.47 億人資訊外洩的故事
所以要讓機器來盯。
常犯的錯誤
- 看了新聞就憑人力判斷「我們應該沒事」
- 只看
package.json裡的寫法來估危險程度 - 用「以後再更新」搪塞，不定截止期限
讓機器來盯
- Dependabot（GitHub）：對相依套件中相關的 CVE 自動發 PR 通知
- osv-scanner（Google）：檢查鎖定檔，在 CI 中只需一步
- 以實際執行的版本來判定（不要輕信下限寫法）
要點在於以「實際執行的版本」來判定。package.json 裡的下限寫法，可能與實際執行的版本不同（RCE 的事故中，這也曾是誤判的原因）。
如何檢查自己的環境
查出某個 CVE 編號是什麼
把新聞裡看到的編號輸入 CVE / KEV 查詢，就能一次看到 CVSS 分數、被利用機率（EPSS），以及是否列在 KEV。
列出命中自己相依套件的 CVE
把 lockfile（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 與 IPA, "JVN (Japan Vulnerability Notes)" — jvn.jp
- CISA, "Known Exploited Vulnerabilities Catalog" — cisa.gov
接下來讀什麼
- 術語：什麼是 CVSS（嚴重程度的打分標準） / 什麼是 RCE
- 對策：建立追蹤 CVE 的機制（機器監控）
- 事故：Equifax — 放任已知 CVE