不免俗地，系列第一篇還是先來一段前言喇賽。
去年我第一次參加鐵人賽，題目是「打雜工程師的資安修煉之路」。
原本覺得連續寫 30 天根本是在找自己麻煩，沒想到每天東湊一點、西補一點，最後還真的寫完了。雖然過程中也有幾天很想直接躺平，但整體來說比想像中有趣，所以今年又跑回來挑戰一次。
以前準備發文時，我其實滿擔心自己文筆不夠好，甚至怕別人看完會想說：「這是哪個小學生投稿錯地方？」
不過這一兩年 AI 發展得很快，至少在寫作這件事上，確實能幫忙整理句子、潤稿和製作圖片。對我來說，它降低了不少寫作門檻，也讓我比較有勇氣再參加一次。
當然，AI 可以幫忙打字，卻不能幫忙負責。資料對不對、文章怎麼安排，以及最後到底想表達什麼，還是得由自己把關。
那今年為什麼會選 CVE？
其實原因也沒有多甚麼。這幾年看到的 CVE 通報愈來愈多，加上今年因緣際會接觸到一些漏洞通報相關內容，查著查著才發現，原來一個漏洞從被發現到正式公開，中間要經過的事情比想像中多很多。
誰負責發 CVE 編號？
為什麼同一個漏洞會看到不同的 CVSS 分數？
CWE、CAPEC、EPSS 又是在幹嘛？
有 CVE 就代表很危險嗎？
這些名詞平常都看過，但真的要把它們串在一起時，腦袋可能還是會打結。
所以這次想用 30 天，跟著一個漏洞走完它的公開旅程。從 CVE 編號、CNA 協調與漏洞描述，一路走到 CWE、CVSS、EPSS，以及最後怎麼判斷修補優先順序。
這個系列不會著重在某個漏洞要怎麼打，也不會每天丟一大堆規格文件叫大家回去啃。比較像是把我自己查過、踩過坑的內容整理起來，看看一份漏洞資訊究竟要怎麼寫，後面接手的人才不會看得一頭霧水。
先想像一個很常見的情境。
某天群組突然有人丟進三個連結：
三篇標題不一樣，使用的名詞也不一樣。
研究者寫「某產品登入流程可被繞過」，廠商公告寫 Authentication bypass in product X，資安新聞則變成「未授權攻擊者可存取管理功能」。
這時候第一個問題通常還不是「這個洞幾分」，而是：
等一下，這三篇是在講同一個洞嗎？
研究者關心攻擊手法，廠商關心受影響與修補版本，防禦端先看有沒有利用跡象，系統管理者只想知道今晚到底要不要留下來加班。
大家都沒說錯，只是站的位置不同，講出來的東西自然也不一樣。
這就是 CVE 最先要處理的問題：先讓大家確定，我們現在講的是不是同一件事。
說穿了，CVE ID 有點像漏洞的身分證字號。
名字可能有人翻成中文、有人使用英文，也可能每篇文章下的標題都不一樣；但只要大家引用的是同一組 CVE ID，至少可以先把資料對到同一個漏洞上。
例如：
CVE-YYYY-NNNN
它不會告訴你漏洞的全部細節，也不會直接告訴你今晚要不要加班，但它提供了一個穩定的關聯點。後續的廠商公告、修補版本、CVSS、CWE、EPSS、KEV 與資產盤點，才有辦法圍繞著同一個漏洞串起來。
很多人第一次接觸 CVE 時，會以為 CVE 就等於完整的漏洞分析報告。其實比較精準的說法是：CVE 主要解決漏洞識別與資訊交換問題。
一筆 CVE Record 會包含漏洞描述、受影響產品或版本、參考連結等基本資訊，也可能進一步提供 CWE、CVSS 或其他補充資料。但 CVE 本身並不保證所有細節都已經完整到可以重現漏洞。完整技術細節通常還是會出現在 vendor advisory、研究者文章、修補 commit、PoC 或其他公開資料裡。
所以在閱讀 CVE 時，可以把它當成一個入口：
這樣比較不會把 CVE 當成萬能答案，也比較符合實務上的使用方式。
對防禦者來說，漏洞資訊最大的挑戰通常不是「知不知道有漏洞」，而是「能不能快速判斷跟自己有沒有關係」。
標準化資訊至少帶來幾個好處。
第一，它讓資產盤點可以對應漏洞。當掃描器、SBOM、弱點管理平台、修補公告都能引用同一個 CVE ID，組織就比較容易回答：「我們有沒有受影響版本？」
第二，它讓風險排序更有基礎。CVSS 可以描述漏洞的技術嚴重性，EPSS 可以補充漏洞在未來 30 天內遭實際利用的可能性，CISA KEV 這類清單則能告訴我們，哪些漏洞已經確認遭到實際利用。這些資料之所以能被串接，很大一部分是因為 CVE ID 提供了共同的關聯點。
第三，它降低跨團隊溝通成本。工程、維運、資安、管理層在討論漏洞時，如果都能引用同一個識別碼，就比較不容易在名稱、版本、影響範圍上各說各話。
漏洞通報的品質，會直接影響後續修補與風險判斷。如果描述只寫「存在安全漏洞」或「可造成未授權存取」，讀者仍然會有很多疑問：
因此，標準化不是把文字變得制式，而是讓必要資訊更容易被檢查、理解與重複使用。好的漏洞描述，通常會盡量交代哪個產品或元件出了問題、問題發生在哪裡、攻擊者需要具備什麼條件，以及成功利用後會造成什麼影響。
例如，比起這樣寫：
某系統存在漏洞，攻擊者可取得資料。
更好的方向會是：
某產品在特定版本中，因為未正確限制某功能的存取權限，已通過身分驗證的遠端攻擊者，可能讀取原本不應存取的資料。
這段仍然是泛化範例，但它至少把產品範圍、版本概念、攻擊條件、問題原因和影響方向放進同一句話裡。
CVE 是這個系列的起點，因為很多漏洞知識都會圍繞它展開。
接下來幾天會依序拆開幾個常見但容易混在一起的概念：CVE ID、CVE Record、CNA、NVD、Vendor Advisory。之後會進入 CWE、CAPEC、CVSS、EPSS 等主題。
如果把漏洞通報想成一份資料表，CVE ID 像是主鍵；CWE 幫助描述弱點類型；CAPEC 描述攻擊模式；CVSS 描述技術嚴重程度；EPSS 補充利用可能性。這些資料各自回答不同的問題，但串在一起後，就能讓漏洞資訊更容易被理解、搜尋、排序與處理。
今天先建立一個基本觀念：漏洞需要標準化通報，不是因為大家喜歡填表，而是因為漏洞資訊會被很多角色重複使用。
CVE 的核心價值，是讓不同資料來源能對齊同一個漏洞。它不等於完整技術報告，也不等於風險的全部答案，但它是後續分類、評分、修補追蹤與風險管理的重要入口。
下一篇就從最常被混用的三個名詞下手：CVE ID、CVE Record、CVE List。平常聊天時混著說無妨，真的要查資料或寫系統時，它們可不能算同一樣東西。
iThome鐵人賽
看影片追技術