「CVSS 10.0」「CVSS 9.8 的 RCE」這類數字，幾乎出現在每則漏洞新聞裡。它們不是憑感覺打的分，而是從既定的評分標準（指標）和公式算出來的。下面從零開始講解它的讀法。
分數的對照
| 分數 | 等級 | 體感 |
|---|---|---|
| 9.0 – 10.0 | Critical（重大） | 立即處理。多為接管級 |
| 7.0 – 8.9 | High（高） | 盡早處理 |
| 4.0 – 6.9 | Medium（中） | 有計畫地處理 |
| 0.1 – 3.9 | Low（低） | 觀察處理 |
如果說 CVE 是表示「是哪個漏洞」的名字，那麼 CVSS 就是表示「它有多嚴重」的分數。例如「CVSS 10.0 的 RCE」，意味著最高等級的遠端程式碼執行＝最壞等級。
CVSS 的評分標準
CVSS 的分數大體由 3 個評估組構成。現實中公布的「CVE-XXXX 是 CVSS 9.8」，絕大多數指的是最上面那一組 基礎評估（Base） 的分數。
基礎 Base
漏洞本身的性質。公布出來的主體分數。
威脅 Threat
按利用程式碼的流傳程度隨時間修正。
環境 Environmental
按你自己的設定・重要度重新計算。
① 易被利用程度
② 影響的大小
基礎評估大致由 「① 易被利用程度」×「② 影響的大小」 決定。攻擊越簡單、危害越大，得分越高。下面兩個表就是這些評分項目的內容。
① 易被利用程度（攻擊有多容易）
| 指標 | 可取值 | 偏向高分的條件 |
|---|---|---|
| 攻擊途徑 (AV) | 網路 / 相鄰 / 本機 / 實體 | 網路（隔著網際網路）最危險 |
| 攻擊複雜度 (AC) | 低 / 高 | 低（不需要特殊條件或運氣）危險 |
| 所需權限 (PR) | 不需要 / 低 / 高 | 不需要（連登入都不用）危險 |
| 使用者互動 (UI) | 不需要 / 需要 | 不需要（受害者什麼都不做也能成立）危險 |
如果全部都落在「最危險的那一側」，那就意味著可以隔著網路、輕鬆、免認證、無需對方操作地發起攻擊，這是最壞的前提。
② 影響的大小（一旦成功會發生什麼）
CIA 是資訊安全三大支柱 機密性・完整性・可用性 的首字母。
| 指標 | 可取值 | 「高」的含義 |
|---|---|---|
| 影響範圍 (S) | 無變化 / 有變化 | 有變化＝侵害越過了原有的權限邊界，波及到其他地方 |
| 機密性 (C) | 高 / 低 / 無 | 能把資料一網打盡地讀取 |
| 完整性 (I) | 高 / 低 / 無 | 能隨意竄改資料 |
| 可用性 (A) | 高 / 低 / 無 | 能徹底停掉服務 |
「影響範圍(S)：有變化」會把分數推高
比如，是只在容器內部的危害（無變化），還是從那裡侵蝕到主機乃至其他服務（有變化），區別就在這裡。是否越過這個邊界，即便其他條件相同，也會讓分數大幅變動。
向量字串：用一行記錄分數的組成
CVSS 的分數必定附帶一段叫 向量字串的短字串。它記錄了「選了哪些指標、各自怎麼選的」，是分數的依據，讀懂它就能明白分數的來由。
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H → 10.0 (Critical)把這一行拆開，就能看到所有項目都落在了「最危險的那一側」。
| 分段 | 含義 | 本例的選擇 |
|---|---|---|
AV:N | 攻擊途徑 = 網路 | 可隔著網路攻擊 |
AC:L | 攻擊複雜度 = 低 | 輕鬆成立 |
PR:N | 所需權限 = 不需要 | 免認證即可 |
UI:N | 使用者互動 = 不需要 | 無需受害者操作 |
S:C | 影響範圍 = 有變化 | 越過權限邊界波及 |
C:H / I:H / A:H | 機密性・完整性・可用性 = 全部高 | 全被讀取・被竄改・被停掉 |
區分「10.0」與「9.8」的關鍵
上例中如果影響範圍變成「無變化（S:U）」，那麼即便條件相同，分數也會降到 9.8。是否為 S:C（越過邊界）決定了能否達到最高分 10.0。所以 9.8 和 10.0 可以理解為「兩者都是最壞等級，只是危害多擴散了一層」。
v3.1 與 v4.0：如今兩者並存
CVSS 有版本之分，現行最新是 v4.0（2023 年公開）。不過現實中的 CVE 大多仍用 v3.1（2019 年） 打分，短期內會並存。
| CVSS v3.1 | CVSS v4.0 | |
|---|---|---|
| 公開 | 2019 年 | 2023 年 |
| 表記 | 分數 + 向量 | 用 CVSS-B / BT / BE / BTE 明示用途 |
| 使用者互動(UI) | 不需要 / 需要 的 2 檔 | 細分為 不需要 / 被動 / 主動 的 3 檔 |
| 影響範圍 | Scope(S) 單一項目 | 分開評估「受擊系統」和「波及目標系統」 |
| 補充資訊 | 無 | 增加是否可自動化・可復原性・安全性等參考指標 |
實例：知名漏洞的實際分數
以下是 NVD 上登載的實際分數。從中可以看出：分數不一定等於現實中的損害大小，而且分數會因評估者或 CVSS 版本而改變。
| 漏洞 | CVSS v3.1 | 向量重點 | 從中看出什麼 |
|---|---|---|---|
| Log4Shell（CVE-2021-44228） | 10.0 Critical | 所有指標都在最壞一側，S:C | 典型的 10.0，而且出在被廣泛使用的元件裡 |
| Apache Struts（CVE-2017-5638） | 9.8 Critical | S:U（影響範圍無變化） | 在舊版 v2 是 10.0——版本不同，數字就不同 |
| 某 VPN 設備的漏洞（CVE-2018-13379） | NVD 9.8／產品廠商 9.1 | 兩方對完整性 I 的評估不同 | 同一個 CVE，來源不同分數就不同；據報導是半田醫院事件（英文）的入侵入口 |
| Heartbleed（CVE-2014-0160） | 7.5 High | 只有機密性 C:H，沒有竄改或停機 | 不是 Critical，卻成了可能洩漏私鑰的重大事故 |
這 4 個都列在美國 CISA 的「已知遭利用漏洞」目錄（KEV）裡。7.5 的 Heartbleed 也被實際利用過，所以光看分數無法判斷「可以晚點再處理」。
分數以外還要確認什麼
懂了評分標準，CVSS 就是個強大的工具。但別忘了分數是 「最壞條件下的理論值」。在實務中，把分數再乘上下面兩點來決定優先順序，才比較貼近現實。
看是否真的在被利用（KEV）
現實中已觀測到攻擊的漏洞（KEV＝Known Exploited Vulnerabilities），無論分數高低都是最優先。比起理論值，「此刻是否正在被攻擊」更重要。
確認你自己是否在用這個功能
即便是 CVSS 10.0，只要沒在用對應的功能或元件，實際危害就很小。反過來，中等分數但在你的生產環境裡必然中招，那就是最優先。以「實際在跑的版本」來判定是鐵律。
實例：曾有人把已公開的 CVSS 10.0 當作「與我無關」放著不管，結果被踩中而導致非法扣費。分數絕不能成為「可以放著不管的理由」。→ 放任 CVSS 10.0 的故事
如何檢查自己的環境
查出你在用的東西有哪些 CVE 與分數
查看廠商的安全公告、NVD 或 JVN。如果手上有 CVE 編號，本站的 CVE / KEV 查詢可以一次看到 CVSS、EPSS 與 KEV。
讀向量，判斷是否套用在自己身上
即使是 AV:N（隔著網路），只要那個功能沒有對網際網路公開，風險就會下降。若是 PR:L（需要登入），就要確認誰能登入。把向量貼到 CVSS 計算與向量解讀，就能看到各部分的意思。
讓機器比對相依套件
自己開發的 Web 應用程式，可以用相依套件漏洞掃描器或 Dependabot 掃描 lockfile，列出符合的 CVE 與分數。這比靠肉眼追蹤一切可靠得多。
出處（一手資料）
- FIRST, "CVSS v3.1 Specification Document" — first.org（指標與嚴重程度等級）
- FIRST, "CVSS v4.0 Specification Document" — first.org
- NIST NVD, "CVE-2014-0160" — nvd.nist.gov（CVE-2021-44228、CVE-2017-5638、CVE-2018-13379 的分數與向量，同樣以各自的 NVD 頁面確認）
- CISA, "Known Exploited Vulnerabilities Catalog" — cisa.gov
- FIRST, "Exploit Prediction Scoring System (EPSS)" — first.org
接下來閱讀
- 判斷：先修哪個 CVE？CVSS、EPSS、KEV 各自衡量什麼
- 工具：CVSS 計算與向量解讀（貼上向量字串即可查看評分與各項意義）
- 術語：CVE 是什麼（給漏洞標注的「流水號」） / RCE 是什麼（最壞等級的危害）
- 對策：把 CVE/CVSS 納入維運（相依套件的機器化監控）
- 事故：放任已公開的 CVSS 10.0 而被非法扣費的故事