「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 自動通知，這才實際。