SEC-bench 論文閱讀分析：當 LLM Agent 真的進到軟體安全工程現場，才知道會寫 code 不等於會做 security work
論文基本資訊
- 論文標題：SEC-bench: Automated Benchmarking of LLM Agents on Real-World Software Security Tasks
- 作者：Hwiwon Lee、Ziqi Zhang、Hanxiao Lu、Lingming Zhang
- 年份：2025
- 來源：arXiv:2506.11791
- 論文連結：https://arxiv.org/abs/2506.11791
- DOI：10.48550/arXiv.2506.11791
- 主題：LLM Agent、Software Security、Benchmark、PoC Generation、Vulnerability Patching、Security Engineering
如果最近這一串 sectools.tw 的論文主線，已經從 SOC triage、incident response orchestration、agent guardrail、open agent governance 一路寫到 system prompt attack surface，那下一步其實很自然會碰到另一個更工程、也更殘酷的問題：當我們說 LLM agent 可以幫資安團隊做事，到底是能做「看起來像資安」的 demo，還是能在真實的 software security workflow 裡，把該做的事真的做完？
SEC-bench 這篇論文的價值，就在它不再滿足於讓模型回答資安知識題，或在玩具場景裡解一兩個漏洞 challenge，而是直接把問題拉到更貼近實務的層次：如果你真的把 LLM code agent 放進 security engineering workflow，它能不能自己重現漏洞、寫出 exploit PoC，或者甚至修出一個真正能過測試的 patch？
我會把這篇 paper 視為最近 agentic security / benchmark 脈絡裡很值得補上的一塊，因為它把評測焦點從「模型會不會講資安」往前推到模型能不能在有 repository、有 harness、有環境限制、有漏洞重現需求的條件下完成工作。這跟前面幾篇偏 SOC、偏 incident handling、偏 governance 的文章不太一樣；它比較像是在問：如果把 agent 放進更接近 AppSec 與安全工程的第一線，它到底還剩多少真本事？
這篇論文想補的洞：目前很多 benchmark 還是太像考卷，不像工作
這篇論文的出發點非常明確。作者認為，現在很多針對 LLM agent 的安全評測，雖然已經比一般 NLP benchmark 更進一步，但仍有一個很大的共同問題：它們通常不是太合成、就是太簡化。
換句話說，模型也許能在這些 benchmark 上展現某種「懂漏洞」「懂 exploit」「懂 patch」的樣子，但這不等於它真的能勝任 security engineer 的工作。因為真實世界裡的 software security task，從來不是一題一答就能完成，而是會同時包含：
- 閱讀與理解真實 code repository
- 在受控環境中重現漏洞
- 根據 failure signal 調整 exploit 或修補策略
- 處理測試 harness、dependency、執行約束與驗證機制
- 最後交出一個可以被客觀驗證的結果
也就是說，真實世界的 security task 本質上是 workflow problem，不只是 knowledge problem。 你可以知道什麼是 SQL injection，也可以背出某種 memory corruption pattern，但如果你沒辦法在特定 repository 裡找到可利用點、讓 PoC 真正跑起來，或提交一個能修掉漏洞又不把系統打壞的 patch，那在工程現場其實還是沒交付。
SEC-bench 要解的，就是這個落差。它不是再做一個「資安題庫」，而是想建立一個可以自動化、可重現、可量化，而且足夠接近真實 security engineering 任務的 benchmark framework。
SEC-bench 的核心主張：不要只問模型懂不懂漏洞，而要問它能不能交付 exploit 與 patch
作者把 benchmark 任務收斂到兩個非常關鍵、也非常實際的 security engineering 工作：
- PoC generation：根據真實漏洞與對應程式碼環境，產生可重現漏洞的 proof of concept
- Vulnerability patching：針對同一類真實漏洞，產出能通過驗證的修補程式
這個選題其實很聰明。因為它避開了很多容易失真的評測方式。
例如，如果你只是叫模型「解釋這個 CVE」，那測到的往往是知識回憶和語言整理能力；如果你只是叫模型「指出哪裡有漏洞」，那又很容易落回 pattern matching。可是 PoC generation 和 patching 不一樣：這兩件事都要求模型不只要懂，還要產生會造成真實後果的可執行輸出。要嘛 exploit 成功、要嘛 patch 真的把洞補起來，這比文字答題殘酷得多。
也因此，SEC-bench 不是在測「agent 看起來像不像資安工程師」，而是在測：當你真的把 agent 放到 security engineering loop 裡，它到底能不能完成最基本、也最重要的交付。
它怎麼做到「真實」又「可自動化」？關鍵在於 repository、harness 與 gold patch 的全自動建構
這篇論文最有意思的地方，不只是最後拿哪個模型來跑，而是它怎麼建 benchmark。
作者提出的 SEC-bench framework，不是手工整理一批漏洞題目讓 agent 去做，而是用一個 multi-agent scaffold 自動去完成 benchmark instance construction。從 abstract 與論文說明來看，這個系統會做幾件很關鍵的事：
- 自動構建帶有漏洞的真實 code repositories
- 替每個 instance 配好可驗證的 harness 與隔離執行環境
- 重現對應漏洞，確保評測條件不是紙上談兵
- 生成可作為評估基準的 gold patch
這裡的工程味非常重，而這正是它的價值。因為很多 benchmark 的痛點不是「想不到題目」，而是缺乏一個足夠可靠、足夠便宜、又能規模化的真實任務生成流程。如果每個漏洞案例都要靠大量人工整理環境、修測試、驗 exploit、做 patch baseline，那 benchmark 很快就會卡在成本與維護地獄裡。
SEC-bench 的一個很亮眼的數字，是作者聲稱它能以每個 instance 約 0.87 美元的成本，自動建立具有可重現 artifact 的高品質 security task。這個數字不只是「便宜」而已，更重要的是它代表一件事：真實世界 security benchmark 的擴張，不一定非得靠高昂人力；如果 pipeline 設計對了，它可以變成一條可以持續長大的資料生產線。
這篇 paper 最值得注意的一點：它測的是 agent，不只是 model
SEC-bench 很清楚站在 agent evaluation 的脈絡裡。這意味著它不是單純比較某個 base model 的靜態能力，而是把焦點放在LLM code agent 在完整操作流程中的實際表現。
這點很重要，因為只要進入 repository-level security task，問題就已經不再只是「模型能不能想出正確答案」，而會同時牽涉到：
- agent 如何規劃步驟
- 如何讀檔、搜尋、修改、執行
- 如何根據測試失敗訊號修正策略
- 如何在 exploit 與 patch 之間維持狀態一致性
也就是說，同一個模型權重，放在不同 agent scaffold 上，最後交出的 security work product 可能完全不是同一個等級。 這也是最近很多 agentic security 論文反覆在提醒的一件事：一旦任務進入多步驟、長上下文、工具互動與狀態管理，真正的能力單位就不再只是 model，而是 model × scaffold × environment 的組合。
SEC-bench 因此很像是在替這個觀點補上一個更硬的驗證場：如果你要說某個 LLM agent 可以做 security engineering，那就來看它能不能在真實 repository 上交付 exploit 與 patch。
結果其實很殘酷：最強 agent 也沒有你想像中那麼能打
這篇論文最值得警惕的一組數字，是它把現階段 SOTA LLM code agents 拉回現實。
作者的整體結論很直接：在完整 SEC-bench dataset 上，最先進的 agent 系統表現依然存在明顯落差：
- PoC generation 最多只有 18.0% 成功率
- Vulnerability patching 最多只有 34.0% 成功率
這兩個數字都不算好看，而且正因為不好看，所以很有價值。它提醒我們：今天很多看起來很會寫 code、很會解 benchmark 的 agent，一旦丟進更接近真實 security engineering 的環境，能力其實立刻出現大幅折損。
尤其 PoC generation 只有 18% 左右，這個結果很能說明 exploit-oriented task 的難度。因為這類任務不只是產生某段看似合理的輸入而已，而是需要 agent 對 code path、漏洞觸發條件、執行環境、測試驗證方式都有相對紮實的掌握。只要其中一個環節出錯，PoC 就不會成功。
而 patching 雖然相對高一點，最高約 34%，但這也遠遠稱不上「已經能交給 agent 自動處理」。它比較像是在告訴你：LLM agent 已經開始碰得到 security engineering 的門把，但離可靠、自主、可大規模託付，還差很遠。
這篇論文的重要性，不只是分數低，而是它讓我們知道低在哪裡
很多 benchmark 只會告訴你模型沒過幾題，但 SEC-bench 真正更有研究價值的地方，是它把失敗放回工作流裡理解。
從這篇論文的設計邏輯來看，agent 失敗的原因往往不只是「模型不知道答案」，而可能是整條 execution chain 的任何一段出了問題，例如：
- 沒有正確定位漏洞觸發點
- 沒有掌握 repository 中相關模組與依賴關係
- 生成了看似合理、實際卻無法重現的 exploit
- patch 修掉一個路徑，卻破壞其他功能或未通過 harness
- agent 在多輪嘗試中失去狀態、卡在錯誤假設上反覆空轉
這點很關鍵。因為它說明了 security agent 的可靠性問題，不是簡單再加一點 domain knowledge 就能補完。很多時候你缺的不是「知道更多 CVE」，而是：
- 更好的 repository navigation
- 更穩定的 tool use
- 更可控的 execution feedback loop
- 更嚴謹的 patch validation
- 更不容易崩壞的長程任務記憶
換句話說，SEC-bench 最終在打的，不只是 code generation，而是 autonomous security work 的系統可靠性。
它和最近幾篇 agentic security 論文的差異在哪裡？
如果把它放進最近 681–696 這串文章的脈絡裡看，SEC-bench 的位置其實很清楚。
- 它不像 SIABench、IRCopilot、Hallucination-Resistant Security Planning 那樣聚焦 SOC / IR 流程。
- 它不像 AgentDoG、AIR、Clawed and Dangerous 那樣以 safety、guardrail、governance 為主軸。
- 它也不像 CVE-Bench、Red-MIRROR 那樣更偏 offensive exploitation capability 本身。
SEC-bench 比較特別的是，它把討論焦點轉到安全工程交付物。不是只問 agent 能不能找到洞，也不是只問它知不知道風險，而是問：
當 agent 真正參與 software security workflow，它能不能產出工程上可驗證的成果？
這種角度我認為很值得寫，因為它剛好替前面那串文章補上一塊常被忽略的拼圖：agentic security 不只存在於 SOC 和治理，也會出現在程式碼、修補、驗證、CI/CD 與 security engineering pipeline 裡。
為什麼 PoC 與 patch 這兩個任務特別重要？
我很喜歡這篇論文把 benchmark 壓到這兩件事上，因為它們剛好代表 security engineering 裡兩個最有代表性的交付方向。
1. PoC generation：測的是對漏洞機理與執行條件的真正掌握
PoC generation 的困難，不只是 exploit code 要寫得出來，而是 agent 必須正確理解：
- 漏洞成因是什麼
- 觸發條件是什麼
- 在當前程式與環境中怎麼把它重現
- 成功的驗證訊號是什麼
這比一般 code generation benchmark 難得多，因為你不是在生成「看起來像正解」的程式，而是在生成會造成真實安全效果的程式。
2. Vulnerability patching：測的是修補品質與系統相容性
另一方面，patching 也不是把某段危險 API 刪掉就算完成。真正有意義的 patch，通常必須同時滿足幾件事：
- 確實移除或阻斷漏洞路徑
- 不破壞既有功能
- 能通過測試與 harness 驗證
- 最好還保有某種可維護性與合理性
這其實非常接近現場 security engineer 或開發者真正會遇到的張力：不是「把洞補掉」這麼簡單，而是「把洞補掉，同時不要把產品搞壞」。
因此，這兩個任務合起來，剛好形成一個很好的雙面鏡：一面看 agent 能不能理解並重現安全問題，另一面看它能不能提出工程上可接受的修補方案。
SEC-bench 對產業最大的提醒：demo 能力和交付能力是兩回事
我覺得這篇論文對產業界最有價值的一句潛台詞，大概是這樣：
不要因為 agent 在 code generation 或漏洞說明上看起來很流暢，就誤以為它已經具備可託付的 security engineering 能力。
這句話很重要，因為現在很多團隊對 AI for security 的期待，常常會被幾個漂亮 demo 拉高：模型能 summarise 一個 CVE、能指出可疑函式、能寫出像樣的 patch 草稿，看起來都很厲害。但 SEC-bench 告訴你，一旦進入需要可驗證交付的場景，現況仍然離 fully autonomous 很遠。
這並不是說 LLM agent 沒價值。相反地，我認為它的價值正在浮現，只是更合理的位置可能是：
- 協助 security engineer 快速理解 repository 與 bug context
- 產生 PoC 或 patch 的第一版草案
- 縮小搜尋空間，減少人工 trial-and-error
- 在 human-in-the-loop 條件下提高工程效率
而不是現在就把它當成一個可以全自動接案、全自動修洞的 autonomous security engineer。
從研究角度看，這篇論文其實在推動一種更成熟的 agent evaluation 文化
SEC-bench 真正令人欣賞的一點，是它代表一種比較成熟的研究態度：不要只做看起來會贏的 benchmark，而要做能讓系統暴露真實弱點的 benchmark。
這種態度對 agentic security 特別重要。因為這個領域很容易被 flashy demo 帶著跑，尤其當模型會說話、會用工具、會改 code 時，旁觀者很容易高估它的可靠性。可是真正有用的 benchmark，應該反而要去問：
- 它在哪些任務上穩定失敗？
- 它是卡在 reasoning、tooling，還是 validation？
- 它哪些能力其實只是 benchmark-specific trick？
- 它離 production-grade autonomy 還缺哪些工程條件？
SEC-bench 至少朝這個方向走了一步。它把 agent 拉進 repository、環境、harness、gold patch 這些更接近現實的結構裡，迫使大家用比較誠實的方式看待現況。
這篇論文的限制也很值得一起看
當然，SEC-bench 也不是沒有侷限。
- 第一，它聚焦的是 software security engineering，不等於整個 cybersecurity。 所以它無法代表 SOC、CTI、IR 等其他工作流。
- 第二，即使比很多 benchmark 更真實，它終究仍是 benchmark environment，而不是企業內部複雜 CI/CD 與組織流程。
- 第三，它非常強調可自動化與可驗證，這很好，但也可能讓某些較難形式化的安全工作被排除在外。
- 第四，成功率雖然低，卻未必能直接拆出所有失敗的根因；後續若能做更細的 trajectory analysis，價值會更高。
不過這些限制不會削弱它的重要性。因為它最核心的貢獻，本來就不是「完整涵蓋所有資安任務」，而是把其中一塊極重要、極需要真實評測的區域——安全工程交付——拉到一個比較能被嚴格討論的 benchmark 層次。
總結
SEC-bench: Automated Benchmarking of LLM Agents on Real-World Software Security Tasks 是一篇很值得接在最近這串 agentic security / benchmark 脈絡後面的論文，因為它把問題從「agent 會不會做資安題」往前推成「agent 能不能完成真正的 security engineering 交付」。
它最重要的訊息，不只是分數很低，而是低得很有意義：即使是當前最先進的 LLM code agents，到了真實 repository、真實漏洞、真實 harness 驗證的世界裡，PoC generation 最高也只有 18%，patching 最高也只有 34%。 這不是壞消息，反而是很有用的現實校準。
如果要把這篇 paper 濃縮成一句話，我會這樣說：
真正能用於資安工程的 agent，不會因為它很會講漏洞就成立，而是要等到它能在真實程式碼與驗證環境裡，穩定交出 exploit 與 patch，才算真的踏進門檻。
而 SEC-bench 的價值，就是把這個門檻第一次量得夠清楚、也夠不留情面。
本文由 AI 產生、整理與撰寫。