VulnSage 論文閱讀分析：當 LLM 不再只會報漏洞，而是開始把可疑告警一路修成可驗證 exploit

如果最近 sectools.tw 這波文章，一路在追 agentic security、AppSec benchmark、tool-using agents、runtime trust boundary，那這篇 VulnSage 值得補上的位置很清楚：它不是再問模型會不會找漏洞，而是直接往更危險、也更接近真實攻防價值的一步走——模型到底能不能把「看起來可疑」的弱點，真的收斂成可驗證的 exploit。

這件事之所以重要，是因為現代軟體供應鏈裡的弱點管理，常常卡在一個很煩但很現實的地方：靜態分析工具很會報，團隊卻沒辦法快速知道哪些 alert 真的打得通。 如果每個可疑點都要靠人手慢慢追資料流、補輸入結構、猜 constructor 參數、組 PoC，再一輪一輪修到能打通，成本就會高得離譜。VulnSage 想處理的，不是單純 code generation，而是這整條「告警 → 理解 → 生成 → 驗證 → 反省」的 exploit confirmation workflow。

它做的不是單一大模型神蹟，而是一個分工很像真人研究員的 multi-agent 流程

論文的核心設計很直白，但也正因為直白，反而比很多「丟一個超大 prompt 叫模型自己想辦法」的做法更可信。作者把自動 exploit 生成拆成幾個明確角色：

• Code Analyzer Agent：先從程式碼與靜態分析結果中抽出漏洞相關資訊、資料流與 exploit template。
• Code Generation Agent：根據漏洞脈絡與約束條件，實際生成 exploit code。
• Validation Agent：把生成結果丟進可執行環境裡驗，確認 exploit 到底有沒有真的成功。
• Reflection Agents：如果失敗，就利用執行錯誤、trace 與環境回饋去修 exploit；如果始終不通，也可能反過來判斷原本 alert 根本是 false positive。
• Supervisor Agent：像總控一樣決定下一步要叫誰做事，讓整個流程形成可迭代的 exploit refinement loop。

這個設計最值得注意的地方是：它把 exploit generation 當成一個需要 feedback、驗證與修正的長程流程，而不是一次性文字生成任務。 真正麻煩的從來不是模型能不能寫出幾十行像樣的 exploit code，而是它能不能在失敗後知道自己哪裡錯、該往哪個方向修。

VulnSage 抓到的關鍵，不是「怎麼讓模型更會寫 exploit」，而是「怎麼讓模型先看懂程式真正卡在哪」

這篇 paper 一個很聰明的切點，是把 constraint-guided comprehension 放在前面。作者的觀察其實很準：很多 exploit 打不通，不是因為 sink 不明顯，而是因為入口函式的輸入結構、物件初始化、繼承樹、polymorphism、控制流條件 太複雜。對真人研究員來說，這叫「你得先把程式是怎麼被正常呼叫的搞懂」；對模型來說，這叫 context 容量不夠、注意力飄掉、又很容易幻想出一段看似合理但根本跑不起來的 invocation。

VulnSage 的做法不是要求模型硬吃整個 codebase，而是先把跟漏洞有關的 code slice、dataflow 與約束條件整理出來，再讓生成代理沿著這些 constraints 去構造 exploit。這個方向很重要，因為它透露出一個更大的訊號：未來真正有戰力的 security agent，未必是上下文最長、參數最多的那個，而是最會先把問題壓縮成「對執行有用的結構化脈絡」的那個。

Validation + Reflection 才是這篇真正有味道的地方

如果只看到「multi-agent 自動 exploit 生成」，很容易把它當成又一篇 agent 編排論文。但這篇比較有意思的地方，在於它不把執行失敗視為單純輸出錯誤，而是把失敗本身當成訊號來源。

作者讓 Validation Agent 負責準備執行環境與 oracle，真正去驗 exploit 成不成功；失敗之後，再由 Reflection Agents 根據 runtime error 與 execution trace 提煉 correction insight。這裡的重點不是「模型會 self-reflect」這種很空的說法，而是：只有當反省是綁在可觀測執行結果上，它才比較像工程閉環，而不是語言幻覺的自我感動。

這也是為什麼這篇比很多單輪 exploit-generation demo 更值得看。因為它真正處理的是 exploit automation 裡最昂貴的部分：怎麼把一個幾乎正確但還不能打的 PoC，修成真的能驗證風險的 exploit。

成績看起來很猛，但真正該看的不是 146 個 zero-days 這個數字本身

論文給出的結果很吸睛：在 SecBench.js 上，VulnSage 的 exploit success rate 達到 53.47%，比作者拿來對照的現有工具高出至少 34.64%；另外還宣稱在真實世界中協助發現並驗證了 146 個 zero-day vulnerabilities。這當然很強，也很值得注意。

但如果只停在「哇，找到 146 個零時差」，反而會錯過這篇更重要的訊息。真正值得記住的，不是又一個華麗的攻擊能力 headline，而是：LLM-based exploit automation 開始有能力把靜態告警、程式理解、執行驗證與錯誤修正串成同一條閉環。 一旦這條鏈成形，它的意義不只是在 offensive security 更強，也會直接改寫 defensive validation、supply-chain triage、patch prioritization 與漏洞確認流程。

對防守方來說，這篇最不舒服的地方是：false positive triage 的成本可能開始被重新定價

很多組織今天之所以能勉強承受大量 static analysis alert，很大一部分原因是：把每個 alert 真的驗到 exploit-able，成本仍然很高。 這個高成本在某種程度上也是一道天然緩衝。VulnSage 這類方法如果繼續進步，最先被打穿的可能不是某個單點防線，而是這層「驗證很貴，所以我們可以慢慢來」的假設。

換句話說，未來藍隊與 AppSec 團隊可能得面對一個新的壓力：攻擊者與防守者都更容易把『可疑』收斂成『可利用』。 這會讓漏洞確認速度變快，但也會讓積壓的 technical debt 變得更不容易靠流程拖延。

把它放回近期 sectools.tw 的脈絡裡，這篇剛好接在 AppSec benchmark 與 agent workflow 之間

如果把它放回最近這串文章來看，它的位置其實很剛好。

• 它不像 SEC-bench 那類工作，重點放在真實 security engineering task 的整體評測；VulnSage 更聚焦在 exploit confirmation 這條高價值子流程。
• 它也不像單純的 offensive benchmark 只回答「模型會不會打」；它更在意模型怎麼透過分工、約束與回饋，一步步把 exploit 修到能打。
• 它同時又和近期不少 agentic security 論文呼應：真正決定 agent 能不能落地的，常常不是模型一句話答得多漂亮，而是整條 workflow 有沒有 validation、reflection 與 hard feedback loop。

所以這篇最好的閱讀方式，不是把它當成「AI 自動打洞又變強了」的聳動新聞，而是把它看成一個信號：資安 agent 的競爭點，正在從單次能力展示，轉向長程任務閉環能力。

我怎麼看這篇

我覺得 VulnSage 真正有價值的地方，不在於它是不是已經代表 fully autonomous exploit generation 成熟了，而在於它把一個很現實的研究方向講清楚了：漏洞利用不是單一步驟的 code synthesis 問題，而是一個需要結構化理解、環境回饋、驗證機制與錯誤修正的循環系統問題。

這也讓它比很多只秀幾個成功案例的論文更值得防守方警覺。因為當 exploit automation 真正開始變強，先被改寫的通常不是 headline 裡那些誇張的零時差故事，而是每天都在排隊等人確認的那一大堆告警、library 弱點與供應鏈風險。

真正麻煩的，常常不是模型忽然變成天才駭客，而是它開始夠穩地把「看起來像漏洞」一路推進成「可以被拿來證明風險」的工程流程。

本文由 AI 產生、整理與撰寫。 內容主要依據公開論文、arXiv 頁面與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。