PAGENT 論文閱讀分析：當漏洞報告真正卡住時，問題常常不是你知不知道哪裡有洞，而是你還做不出能穩定重現它的那個 PoC
PAGENT 論文閱讀分析：當漏洞報告真正卡住時，問題常常不是你知不知道哪裡有洞，而是你還做不出能穩定重現它的那個 PoC
論文基本資訊
- 論文標題：Program Analysis Guided LLM Agent for Proof-of-Concept Generation
- 作者：Md Shafiuzzaman、Wenbo Guo、Tevfik Bultan、Achintya Desai
- 年份：2026
- 來源：arXiv:2604.07624
- 論文連結：https://arxiv.org/abs/2604.07624
- 主題：AppSec、Proof-of-Concept Generation、Program Analysis、LLM Agents、Static Analysis、Dynamic Analysis
最近這波 AI × Security 論文很多都在談 prompt injection、tool boundary、memory poisoning 跟 runtime control plane。但如果把視角拉回比較傳統、也更貼近開發團隊日常的 AppSec workflow，真正常卡住的地方其實很務實：你可能知道某個位置疑似有漏洞，也拿到了 report，卻還是做不出一個能穩定把它打出來的 PoC。
而這篇 PAGENT 真正有意思的點，就是它沒有把問題簡化成「讓 LLM 幫你寫 exploit 字串」這種 demo，而是把漏洞重現看成一條需要程式分析、可達性判斷、輸入約束推理、動態驗證與反覆修正的工作流。
我會把它的核心價值濃縮成一句話：PoC generation 真正缺的，常常不是更會猜的模型，而是把 static analysis 跟 dynamic feedback 放回 agent 前面，讓它不要一直在錯的程式路徑上浪費 token。
這篇論文想解決什麼？
作者一開始就點出一個很真實的情境：軟體專案收到 vulnerability report 之後，開發者往往還得自己想辦法把漏洞「重現」出來，才能進一步做：
- vulnerability triage
- patch generation
- patch validation
問題是，很多報告其實沒有附上可靠 PoC；即使有，也未必容易在你的版本、你的 build 環境、你的 target path 上重跑成功。於是重現漏洞這件事，就會變成一個又慢、又仰賴高手經驗的瓶頸。
傳統上大家會想到幾種路：
- symbolic execution：理論上能產出可觸發漏洞的輸入，但 path explosion、環境建模與人工介入很痛。
- fuzzing：很強，但常常需要 harness、grammar、dictionary、seed corpus 與不少專家調校。
- 純 LLM / agent：自動化看起來高，但很容易 hallucinate，搞錯程式路徑、搞錯 entrypoint、搞錯哪些 input constraint 才真的 relevant。
所以這篇真正想做的，不是取代這些方法，而是把它們的優勢拼起來：用靜態分析幫 agent 找對方向，用動態分析告訴 agent 剛剛到底錯在哪裡。
這篇最值得記住的核心觀點：PoC 不是文字生成，而是 reachability 問題
我覺得這篇最對味的一點，是它沒有把 PoC generation 當成一般 code generation 任務。因為在漏洞重現這件事上，真正困難的往往不是「寫出一段像樣輸入」，而是：
- 那個輸入能不能真的走到目標程式位置
- 中間有沒有走錯 entrypoint / architecture / mode
- 外表看起來很像 exploit 的東西，實際上是不是根本沒碰到 vulnerable path
換句話說，PoC generation 的本質比較像：
給定 source code、target location 與 build script，推回去找一組可執行輸入，讓程式在真實運行時真的走到那個會出事的位置。
而這種問題如果只靠 LLM 憑語意猜，很容易出現一種假象：它看起來懂漏洞描述，也會講一些合理推理，但實際上輸入永遠打不到點。這篇論文就是在修這個落差。
作者提出的方法：PAGENT
作者提出的方法叫做 Program Analysis Guided proof-of-concept generation agENT（PAGENT）。整體流程分成三塊：
- Static Analysis Guidance
- PoC Generation Agent
- Dynamic Analysis Guidance
這不是單次 prompt，而是一條閉環 workflow：
- 先對 source code 做靜態分析，抽出和 target 漏洞位置有關的可達路徑與 vulnerability-specific guidance。
- 把這些 guidance 餵給 PoC generation agent，讓它生成 candidate PoC。
- 把 candidate PoC 丟進帶 sanitizer instrumentation 的測試環境執行。
- 如果沒 crash，就把 coverage 與執行回饋送回 agent。
- 讓 agent 根據失敗結果修正輸入，直到成功觸發或耗盡迭代預算。
白話講，它的設計哲學其實很務實：
不要讓 agent 一開始就在整個大型 codebase 裡亂猜；先把它縮到比較可信的 reachable region，再用動態回饋告訴它「你剛剛差在哪一步」。
Static Analysis 在這裡不是配角，而是幫 agent 篩掉大量錯路
作者的靜態分析設計分成兩階段，而且這個切法我覺得很聰明。
第一階段：lightweight static analysis
第一階段先做 entrypoint-driven call graph construction，找出從常見 entrypoints（像 main()、LLVMFuzzerTestOneInput()）可達的函式，並過濾掉 unreachable dead code。
這一步的意義很大。因為大型專案裡一堆函式其實跟目標漏洞沒有關係，如果 agent 一開始就在整個 repo 上自由探索，它很容易被噪音拖走。作者等於先用程式分析幫它做了一層 search-space reduction。
第二階段：rule-based static analysis
接著系統會在 LLVM IR 層級做 rule-based vulnerability analysis，生成一份比較結構化的 vulnerability report，內容包含：
- vulnerability type
- vulnerable function
- taint / reachability path
- entrypoint
- vulnerable program location
- template assertion violation
這裡最重要的不是欄位漂亮，而是它把「LLM 需要猜的東西」往下壓。也就是說，模型不再需要從自然語言漏洞描述裡自己腦補完整路徑，而是可以直接沿著可達路徑與 vulnerable site 做比較具體的推理。
作者給的例子很能說明為什麼這樣有效
論文裡舉了一個 GNU Binutils 的例子，漏洞在 get_register_operand，問題和 buffer overread 有關。表面上看，report 已經告訴你是某個檔案、某個函式附近有問題；但如果要真正做出 PoC，光知道「哪裡有 bug」還不夠，因為你還要知道：
- 該選哪個 disassembly mode
- 該走哪個 architecture constant
- 哪組輸入才能讓控制流真的進到那段 vulnerable code
作者提到，如果只靠 report，agent 可能會走到 TIC4X 路徑，而不是正確的 TIC30 路徑。這種錯非常典型：模型不是完全瞎猜，它其實走到了一條「看起來也說得通」的程式路，但就是沒打中目標。
這時候 static analysis 先把 feasible entrypoint 與 reachability path 拉出來，dynamic analysis 再用 coverage 告訴 agent：「你目前根本沒進到那段 code。」於是 agent 才能修正 architecture choice，最後把 PoC 打到正確位置。
這個例子很值得記，因為它說明了：很多 PoC 失敗不是因為模型不懂漏洞，而是因為它不知道自己到底走錯哪條路。
Dynamic Analysis 的角色：不是只驗證對不對，而是把失敗變成可用訊號
另一個我很喜歡的設計，是作者沒有把 dynamic analysis 只當成最後的 pass/fail checker。它真正做的是把失敗資訊轉成 agent 下一輪可利用的 guidance。
具體來說，candidate PoC 會在帶 sanitizer 的測試環境中執行；如果沒有成功 crash，系統會回傳：
- 執行結果
- coverage report
- 對於哪段路徑被走到、哪段沒走到的線索
這等於讓 agent 不只是被告知「你錯了」，而是被告知「你錯在沒有走到哪裡」。
對 LLM agent 來說，這很關鍵。因為如果只收到一個失敗訊號，它下一輪通常只會亂改；但如果知道自己差在 entrypoint、architecture choice、或某段 branch coverage 沒打到，那它就比較像是在做 guided refinement，而不是 token-based 碰運氣。
實驗設計：拿 203 個真實漏洞來測
作者的評估資料集來自 Cybergym，共 203 個 vulnerabilities，涵蓋 10 個 open-source projects，橫跨不同軟體領域，例如：
- IoT protocol
- data compression library
- GNU binary tools
這裡有個我覺得很重要的比較點：Cybergym 裡原本最強的 agent baseline，是在給定文字化 vulnerability report + stack trace的情況下表現最好；而 PAGENT 強調的是，它不需要 stack trace，甚至不需要完整 textual report，也能靠靜態 / 動態分析 guidance 把 PoC generation 撐上去。
結果怎麼看？headline 很猛，但更重要的是它在改哪個瓶頸
論文最吸睛的數字包括：
- 相較先前 top-performing agentic approach，PAGENT 在 PoC generation task 上提升 132%
- 使用 DeepSeek3.1 這種原本在此任務上偏弱的模型，也能達到 42% accuracy
- 換成 DeepSeek3.2 時，accuracy 提升到 64.6%
- 表現超過 Sonnet-4 與 GPT-5 reasoning agent
- 還額外找出 32 個 patched version 仍可觸發的 post-patch vulnerabilities
但我覺得真正重要的不是單一百分比，而是它揭露了哪個瓶頸最該補：
LLM agent 在 PoC generation 上最常輸的，不一定是語意理解不夠，而是缺少 program-structure guidance 與 execution feedback，導致它一直在不會通的路上花腦力。
這也是為什麼作者強調，連原本較弱的模型在加上 static + dynamic guidance 後，都能顯著超車只靠語言能力硬猜的更強模型。這個結果其實很有啟發性：在高結構約束安全任務裡，workflow 設計常常比裸模型分數更重要。
為什麼能抓到 post-patch vulnerabilities，這點很值得注意
論文裡另一個很有味道的結果，是 PAGENT 找出了 32 個 post-patch vulnerabilities。這不只是「多抓到幾個 bug」而已，它代表一件事：
當系統具備從 code location 出發、沿 reachability 與 execution feedback 反推輸入的能力時，它不只適合處理舊報告，也可能用來驗 patch 到底有沒有真的修乾淨。
這對 CI/CD 很有現實意義。作者也直接提到，PAGENT 其實很適合被放進 commit-level pipeline：每次 code commit 後，把變更位置丟進去，如果剛好引入某類已建模 vulnerability pattern，PAGENT 就可以嘗試自動生成 PoC 來證明它真的可被打出來。
換句話說，這篇不只是談「研究室裡能不能自動生 exploit」，而是隱約在指向一個更務實的方向：把 exploitability validation 前移到更日常的工程流程裡。
我怎麼看這篇論文？
如果把它放回最近一些 agentic security 論文脈絡裡，這篇其實提供了一個很好的對照組。
最近很多 paper 都在談：模型不要直接信任外部內容、tool output 要有 guard、execution boundary 要有 policy、memory 不該隨便污染。這些都對。但 PAGENT 告訴我們另一個方向：不是所有 agent 安全問題都來自「被攻擊」；有時候更核心的工程痛點是「即使沒有攻擊者，agent 自己也常因為缺乏結構化 guidance 而做不成高風險任務」。
而 PoC generation 正是一種典型高風險任務：
- 它需要正確理解程式結構
- 需要找到真實可達路徑
- 需要在真實執行裡被驗證
- 錯了不能只靠自然語言圓過去
所以我會把這篇看成一個很重要的提醒：當任務本質是結構化推理 + 可執行驗證時，最好的 agent 往往不是最會說的那個，而是最會把 analysis signal 接進閉環的那個。
這篇也有什麼限制？
當然，這篇不是沒限制。
- 它依賴已建模的 vulnerability rules：rule-based static analysis 很實用，但 coverage 仍取決於你定義了哪些漏洞模式。
- 主要聚焦在 PoC generation / crash-triggering 類型場景：對更複雜的邏輯漏洞、權限提升鏈或需要外部服務互動的 exploit，難度可能更高。
- 還是需要可建置、可 instrument 的 target environment：真實世界有些專案 build 起來本身就很折磨。
- 不代表完全 autonomous exploit engineering 已經成熟：它很強的是 guided reproduction，不是無限制地自動找任意 exploit chain。
但這些限制我反而覺得合理，因為作者沒有假裝自己解了全部問題。它比較像是在說：先把「可靠重現漏洞」這個工程痛點真的做紮實，再談更大的 autonomy。
總結
如果要把這篇收成一句話，我會這樣講：
PAGENT 真正證明的，不是 LLM 已經會自動寫 exploit，而是只要把程式分析和執行回饋接進 agent workflow，PoC generation 就不必再只是靠模型猜一條看起來像的路。
對 AppSec 團隊來說，這篇最值得抄的不是某個特定模型分數，而是它的設計觀：先用 static analysis 幫 agent 找對 reachable region，再用 dynamic analysis 告訴它哪裡沒打到，最後讓 refinement loop 真正朝可執行目標收斂。
這比單純問「哪個 LLM 最會寫 PoC」有價值得多。因為在真實漏洞處理流程裡，你最需要的不是一個很會說自己懂漏洞的 agent，而是一個真的能幫你把漏洞穩定重現出來的 agent。
一句話結論：PoC generation 真正卡住的，常常不是模型不知道哪裡有洞，而是它沒有被告訴該走哪條路、剛剛又走錯了哪一步；PAGENT 的價值就在於把這兩件事補回來。
本文由 AI 產生、整理與撰寫。