CVE-LLM 論文閱讀分析：當漏洞管理真正卡住時，缺的往往不是更多 CVE，而是把產品脈絡一起帶進判斷的能力
如果前面幾篇 sectools.tw 已經一路把 SynthCTI 的長尾資料問題、TRIAGE 的 CVE→ATT&CK impact mapping、以及 ThreatLinker 的 CVE→CAPEC attack-pattern linkage 慢慢接成一條線，那這篇 CVE-LLM 值得補上的位置就很清楚：它不是再往下游補一個 mapping benchmark，而是把問題拉回企業內部最常卡住的那一層——同一個 CVE 到了不同產品、不同部署條件、不同組件組合裡，到底該怎麼被評估、解讀、回應與處置。
論文全名是 Ontology-Assisted Automatic Vulnerability Evaluation Using Large Language Models（arXiv:2502.15932）。作者來自 Siemens Healthineers 等單位，場景非常務實：醫療設備製造商每天得面對大量第三方元件漏洞通知，光靠人工逐筆判斷 CVE 對哪些產品真的有影響、該怎麼寫內部評語、要不要通知客戶、CVSS environmental vector 該怎麼補，就已經是一條會把專家時間吃光的流水線。
這篇 paper 最有意思的地方，在於它沒有把問題寫成抽象的「讓 LLM 幫你看 CVE」；它處理的是一個更接近真實組織運作的任務：讓模型根據資產描述、軟體版本、受影響組件、通知內容、CVSS 向量，以及從 ontology / knowledge graph 補進來的前提條件與 mitigation 脈絡，自動產生一份可被資安專家接手、修正、採納的 vulnerability evaluation。
論文基本資訊
- 論文標題：Ontology-Assisted Automatic Vulnerability Evaluation Using Large Language Models
- 作者：Rikhiya Ghosh、Hans-Martin von Stockhausen、Martin Schmitt、George Marica Vasile、Sanjeev Kumar Karn、Oladimeji Farri
- 年份：2025
- arXiv：https://arxiv.org/abs/2502.15932
- 主題：Vulnerability Intelligence、LLM、Ontology、Knowledge Graph、VEX、CVSS、Medical Device Security
這篇論文到底在解什麼問題？
很多人談漏洞 intelligence automation，常會停在「能不能把 CVE 自動分類」或「能不能把 CVE 連到 ATT&CK」。但企業內真正最耗人的，其實是更細碎也更實際的問題：
- 這個第三方元件漏洞，對我們哪個產品真的 relevant？
- 如果 relevant，它是 Affected 還是 Not Affected？理由是什麼？
- 要給內部資安團隊什麼 comment？
- 要給客戶什麼 comment？
- 環境脈絡下的 vector 該怎麼補？
在 Siemens Healthineers 的場景裡，這不是少量案例，而是龐大量級：論文提到組織大約有 1.7K products，再加上大量第三方元件與通知，人工 vulnerability evaluation 的規模大到近乎不可持續。這也是作者切入點很有價值的原因：他們不是在做漂亮 demo，而是在處理一條會真實壓垮產品資安團隊的營運流程。
它和前面幾篇 vulnerability intelligence 論文有什麼不同？
如果拿這篇和最近的幾篇一起看，差異很鮮明：
- TRIAGE 比較像把 CVE 連到 ATT&CK impact 脈絡
- ThreatLinker 比較像把 CVE 連到 CAPEC attack patterns
- CVE-LLM 則是把 CVE 拉回組織內部資產與產品情境，回答「那所以我們現在要怎麼判？」
換句話說，前兩篇偏向 knowledge enrichment；這篇更偏向 operational evaluation。它不只是想讓漏洞知識更完整，而是想讓知識能真的進入產品安全決策。
方法核心：不是只餵 CVE，而是把產品脈絡一起送進模型
作者的系統不是單純看一段 CVE description 就輸出答案。它的輸入其實相當豐富，至少包括：
- 組織 / 子組織資訊
- 軟體名稱與版本
- 產品 / asset 描述
- 通知內容（notification description）
- 產品與通知之間共同出現的元件
- CVSS base / temporal vector 的文字化描述
- 從 CAPEC 補進來的 prerequisites、typical severity、mitigations
這裡有一個很重要的觀念：漏洞評估從來不是只讀 CVE 本身，而是讀「CVE × asset context × exploitation condition × mitigation posture」的交集。 這也是很多泛用型 LLM 在漏洞任務上容易失真的原因——它們常常懂漏洞描述，卻不懂那個漏洞放進特定產品脈絡後，實際上該怎麼判。
Ontology / Knowledge Graph 在這篇裡扮演什麼角色？
論文的關鍵詞是 ontology-assisted。作者使用 SEPSES cybersecurity knowledge graph，把 CVE、CWE、CAPEC 串起來，然後從 CAPEC 拉出幾類很有用的補充知識：
- Prerequisites：攻擊要成立需要什麼條件
- Typical Severity：這類 attack pattern 通常造成多大衝擊
- Mitigations：常見緩解方式
這個設計的妙處在於：它不是把 ontology 當裝飾性的 metadata，而是把 ontology 當成讓模型理解新漏洞的橋。 論文明講一個重點——這些 ontology-enriched historical data 讓系統在不重新訓練 LLM 的情況下，也比較有機會理解新的 vulnerability notification。
也就是說，這篇 paper 真正想解的，不只是 accuracy，而是 generalization on unseen notifications and assets。這件事在真實漏洞管理裡很重要，因為你永遠不可能把所有新 CVE 都提前放進訓練集。
資料規模與訓練方式
這篇的工程量其實不小。論文提到兩層資料與兩階段訓練：
- DAPT dataset：約 350K vulnerability description documents，包含公開 NVD CVEs（約 248K）與組織內 vulnerability documents（約 102K）
- SFT dataset：約 750K unique instructions
模型流程採用：
- Domain Adaptive Pretraining (DAPT)
- Supervised Fine-Tuning (SFT)
基底模型是 MPT-7B，作者還做了 vocabulary expansion，把組件名稱、軟體名稱等產品域詞彙補進模型。這裡再次說明一件事：在 vulnerability evaluation 這種高度 domain-specific 的任務上，只靠通用模型裸跑，常常不是能力上限，而是詞彙、語境與任務格式根本沒對齊。
它要模型輸出什麼？
這篇不是單一 classification task，而是把 vulnerability evaluation 拆成多種輸出：
- VEXCategory
- VEXJustification
- InternalComment
- CustomerComment
- Vector
這很值得注意。因為真實世界的安全工作通常不是「判一個 label 就好」，而是還要生成能被人接手的敘述與解釋。這也是為什麼作者同時使用 micro-F1 去評分類別任務，並用 ROUGE-L 去評估 comment generation。
結果怎麼看？
論文的核心發現不是「LLM 全面取代專家」，而是更克制也更可信的幾點：
- CVE-LLM 在相近規模的開源模型比較中表現更好
- 分類型任務（如 VEXCategory、VEXJustification、Vector）整體比生成型任務更穩
- Domain adaptation 帶來顯著提升
- Ontology enrichment 在 deployment、也就是面對新的 notifications / assets 時，比在靜態 test set 更有價值
這個結論很重要。很多 paper 只在 test split 上證明自己變好，但這篇反而點出更接近實務的事實：ontology 補強最有價值的地方，不一定是把已知題做得更高分，而是讓系統在遇到新題時不那麼失真。
部署面最值得記住的一點：它真的進了內部系統
這篇 paper 的一個強訊號是：作者不是停在 offline evaluation，而是把模型接進了內部 Cybersecurity Management System (CSMS)。每天利用新到的通知與產品版本資料批次產生 AI 建議，再交給產品資安專家審核、修正、採納。
這種設計比「全自動」更成熟，因為它承認漏洞評估是高風險工作，不該一開始就完全放手給模型。它採取的是比較合理的路線：
- 模型先產生可用草稿
- 專家優先審高風險或 Affected 類別
- 修正後的結果再回流成後續訓練資料
這其實很像一個真正能落地的 human-in-the-loop vulnerability operations pipeline，而不是只在 paper 裡喊 automation。
效率提升有多大？
論文裡一個很現實的數字是：專家平均一筆 evaluation 需要大約 194 秒，中位數也有 58 秒；模型推論則可壓到約 1 秒/筆。即使考慮人工審核，這種量級差距依然非常可觀。
這代表它的價值未必是把人拿掉，而是把人從重複、瑣碎、可模板化的工作裡解放出來，專注在真正困難或高風險的邊界案例。
這篇論文真正告訴我們什麼？
如果要把這篇 paper 濃縮成一句話，我會寫成：
漏洞 intelligence 的難點，不只是把 CVE 讀懂，而是把 CVE 放進產品脈絡裡，轉成一份可被組織採用的判斷。
這也是為什麼它和一般「CVE 分類」研究不太一樣。它不是把 vulnerability 當純 NLP 資料集來刷分，而是把它視為一個需要：
- 資產上下文
- 攻擊前提條件
- 緩解脈絡
- 組織內決策格式
- 專家覆核流程
共同構成的 operational problem。
它的限制也很明顯
當然，這篇也不是沒有邊界。至少有幾個限制值得記住：
- 場景高度依賴單一大型製造商的產品與流程脈絡
- 醫療設備情境的規範與風險容忍度，不一定能直接外推到一般企業 IT
- 內部資料與知識圖 enrichment 對結果幫助很大，也意味著外部團隊未必能輕易複製同樣效果
- arXiv 頁面也標示了與另一篇論文有 substantial text overlap，閱讀時需要保留這層背景
不過即使如此，它仍然很有參考價值。因為它展示的不是一個完美通用解，而是一種非常務實的設計原則：如果你真想把 LLM 用在 vulnerability operations，重點不是直接問模型答案，而是先把可用的 ontology、knowledge graph、asset metadata、workflow constraints 都接進來。
怎麼把它放回 sectools.tw 這條主線？
如果把最近幾篇連起來看，脈絡大概會是這樣：
- SynthCTI 問的是資料不足時怎麼補
- TRIAGE 問的是 CVE 如何長出 ATT&CK impact 脈絡
- ThreatLinker 問的是 CVE 如何連到更可操作的 CAPEC attack patterns
- CVE-LLM 問的則是：當這些知識真的要進產品安全流程時，評估工作怎麼自動化、但又不要失去脈絡
它把整條 vulnerability intelligence 鏈往「組織內最後一公里」推進了一步。這一步其實很關鍵，因為很多安全知識工程論文最後都停在 graph 很漂亮、mapping 很完整，但沒有真的回答：所以你的產品團隊明天要怎麼用？
Takeaway
CVE-LLM 最值得記住的地方，不是它又證明了一次 LLM 可以看懂漏洞，而是它把漏洞 intelligence 的真正難點講得很清楚：企業需要的從來不是一個只會重述 CVE 的模型，而是一個能把漏洞描述、產品脈絡、攻擊前提與緩解知識一起折疊成可採用判斷的系統。
而 ontology / knowledge graph 在這裡扮演的，也不是華麗配件，而是讓模型在新漏洞與新資產面前不至於完全失去方向感的結構性支架。對任何正在思考「LLM 能不能真正進 vulnerability management」的人來說，這篇都很值得讀。
免責聲明
本文由 AI 產生、整理與撰寫。