SastBench 論文閱讀分析：我們終於開始正面評估 LLM Agent 做 SAST Triage 的真實能力了嗎？
論文基本資訊
- 論文標題：SastBench: A Benchmark for Testing Agentic SAST Triage
- 作者：Jake Feiglin、Guy Dar
- 年份：2026
- 來源：arXiv:2601.02941
- 論文連結：https://arxiv.org/abs/2601.02941
- 主題：SAST、LLM Agent、Security Triage、Benchmark、Vulnerability Management、Application Security
本文由 AI 產生、整理與撰寫。
如果最近一批 sectools.tw 在追的主線，是把 LLM 放進 CTI、SOC、threat hunting、alert triage、rule generation 這些防守現場，那 SastBench 代表的是另一條同樣重要、但常被忽略的藍隊生產線：應用安全團隊每天面對的大量 SAST finding triage，到底能不能真的交給 agent 來做？
這篇論文有意思，不只是因為它又推出一個 benchmark，而是它抓到一個非常務實的問題：很多漏洞資料集其實在測的是「模型會不會辨識漏洞」，但真正的 SAST triage 不是從乾淨的題庫裡找答案，而是從一大堆看起來像漏洞、實際上多半是雜訊的 finding 中，判斷哪些值得 analyst 真的往下追。
換句話說，SastBench 要補的，不是一般 vulnerability detection benchmark 的空白，而是LLM agent 在高雜訊、安全工程工作流中的判斷能力。
這篇論文想解決什麼？
作者開宗明義指出：SAST 工具雖然是 defensive cybersecurity 裡最常見的自動化手段之一，但它的核心痛點從來不是「抓不到東西」，而是抓到太多東西，而且很多都是 false positives。
這件事帶來三個連鎖問題：
- 分析師需要花大量時間做手動 triage
- 高噪音會造成 alert fatigue，讓真正的風險被淹沒
- 現有 benchmark 並沒有很好模擬真實 SAST finding 的分布
因此作者真正要回答的問題是：
如果我們想評估 LLM-powered agent 是否真的能幫忙做 SAST triage，就需要一個什麼樣的 benchmark？
這個問題和一般「模型懂不懂漏洞知識」很不一樣。因為實際 triage 測的是：
- 模型能不能在 codebase 裡自主探索
- 能不能理解 finding 與程式上下文的關係
- 能不能在 false positive 很多的情況下 still make a useful call
- 能不能在 recall 與 analyst workload 之間維持合理平衡
為什麼現有漏洞 benchmark 不夠？
作者對既有 benchmark 的批評，其實相當關鍵。很多現有資料集比較偏向：
- synthetic / hand-crafted examples
- 一般漏洞偵測任務
- paired 修補前後資料
- 少量語言、少量 repository
這些資料集不是沒價值，而是它們通常沒有刻意維持 SAST triage 所面對的 hard-negative distribution。也就是說，它們的 negative class 往往太乾淨、太容易，無法逼近真實世界裡「工具已經先幫你過濾過一輪，但還是留下很多誤報」的狀態。
作者點出的核心差異可以濃縮成一句話：
triage 不是一般分類任務；它是在一個刻意對人類與模型都不友善的分布上做分類。
這也是 SastBench 最重要的設計哲學：不是只要資料夠多，而是要讓資料分布更接近 analyst 真正會遇到的 finding stream。
SastBench 的資料怎麼建？
SastBench 的資料建構非常務實，核心是把正負樣本分別從兩個不同來源拉出來：
- True positives：來自 NVD / CVE 世界中的真實漏洞
- Approximate false positives：來自 semgrep free edition 在 pre-fix repository 上跑出的 findings，再透過 heuristic filtering 清洗
這個設計很重要。作者沒有幻想能大規模蒐集完美標註過的 SAST false positives，因為那本身就等於先把 triage 問題解掉了。相反地，他們採取一個更可擴展的近似方案：
- 用真實 CVE 對應的 commit 與 CWE 當正類
- 在相同 repository 的 pre-fix 版本上跑 SAST
- 把與目標漏洞不同 CWE、且不落在已知 vulnerability function 內的 findings，當成近似負類
這樣做不是要得到理想化的「完美資料集」，而是要得到足夠接近真實 workflow 的工作資料集。這其實比追求理論上最純的標註更有工程價值。
避免資料污染：作者怎麼處理 knowledge cutoff？
作者特別注意一個近年 benchmark 很敏感的問題：模型可能已經在訓練資料裡看過那些漏洞。
因此他們對 true positives 的 CVE 做了時間切割，只保留 knowledge cutoff 之後才公開的漏洞。在論文這版設定裡，他們把時間設在 2025 年 2 月之後，刻意避開受測模型的既有知識範圍。
這件事的重要性在於：如果不處理 contamination，很多 benchmark 看起來像是在測 reasoning，實際上只是在測模型記不記得某個公開漏洞故事。SastBench 至少在設計層面，努力把評估拉回到agent 能不能根據當下給你的 code 與 finding 自行判斷，而不是背答案。
Benchmark 任務本身怎麼跑？
SastBench 的執行方式偏向 agentic benchmark，而不是單純文字問答。它會把目標 repository checkout 到特定 commit，然後提供一組同一個 CWE group 下的 finding，讓 agent 自己在隔離環境裡跑分析流程，最後輸出二元 verdict：
{"verdict": "true_positive" | "false_positive"}這個設計有幾個值得注意的點：
- agent 對 codebase 有完整探索自由，不限內部流程
- 提交形式是 ZIP + Dockerfile + `/analyze` endpoint，屬於 agent-agnostic benchmark
- 允許 commit-level preprocessing，讓 agent 可以先做 repository 級分析，再針對單筆 finding 判斷
這表示作者測的不是某個固定 prompt，而是整個 agent system 的 triage 能力。你可以用 ReAct、可以用 generalist software agent、可以接工具、可以做自己的 workflow，只要最後能在同一環境下輸出 verdict，就能比較。
為什麼主要指標不是 accuracy，而是 MCC？
這篇論文在評估指標上的選擇相當合理。作者把 Matthews’ Correlation Coefficient（MCC） 當成主指標，而不是 accuracy。
原因很簡單：SAST triage 是一個高度不平衡任務。當 negative 遠比 positive 多時，accuracy 很容易誤導。相比之下，MCC 同時考慮 TP、TN、FP、FN，對 class imbalance 更穩。
論文也同時報告：
- Precision = TP / (TP + FP)
- Recall = TP / (TP + FN)
- F1 = 2PR / (P + R)
- F2 = 5PR / (4P + R)
其中 F2 特別重要，因為在 security 場景裡，漏掉真正漏洞的代價，通常高於多報一點 false positive。作者等於是用一組更貼近實務風險的指標，來觀察 agent 的表現。
作者拿哪些 agent / model 來測？
論文不是只測一種設計，而是故意比較不同 agent 風格：
- No-tools baseline：只給相關 code lines，純 CoT 判斷
- Simple ReAct agent：基本的工具迴圈
- Improved prompt agent：加入 security-domain prompt engineering
- Generalist agents：例如 OpenHands 與 mini-SWE-agent
工具則包括：
- Read File
- List Dir
- Search Symbol
- Security Patterns Tool（作者自己也說這比較像 toy lookup / distractor）
模型方面，作者測了多種偏 code / reasoning 的大模型，包括 Gemini 2.5 Flash / Pro、Claude Sonnet 4.5、DeepSeek-R1、Qwen3 Coder 480B、GPT-OSS 120B、Llama Maverick 17B 等。
這樣的組合有個好處：它不是只回答「哪個模型分數高」，而是同時讓人看見workflow 設計、prompt 設計、工具使用與模型能力之間的交互作用。
主要結果透露了什麼？
論文在公開頁面中沒有像很多 benchmark 那樣把所有數值一口氣塞滿摘要，但作者在分析段落給出的幾個結論已經很有意思：
- 較強的模型通常表現較好，而且 precision / recall 常常是一起進步，而不是純 trade-off
- 安全領域導向的 prompt 能顯著提升表現
- 一般型 software agents 並沒有穩定贏過針對 triage 設計的 agent
- 無工具 baseline 並沒有被完全輾壓，某些情況下甚至在 recall 上很接近 simple ReAct agent
其中最值得注意的一點，是作者發現 Gemini 的 no-tool baseline 居然和簡單 agentic workflow 的 aggregate metrics 非常接近。這說明在某些 triage 任務裡，模型的局部程式理解能力已經夠強，未必一定要複雜工具鏈才有明顯收益。
但另一方面，作者也指出 improved prompt agent 的提升非常明顯：Gemini 偏 precision 提升，Claude 偏 recall 提升。這代表真正的差距未必只在模型本身，也在於你怎麼把安全任務包裝成它能穩定執行的 agent workflow。
這篇論文真正的價值，不只是做一個 benchmark
如果把 SastBench 放回更大的 AI-for-security 脈絡，它的重要性在於：它把焦點從「模型會不會找漏洞」轉到模型能不能幫你處理已經進入安全工程 pipeline 的工作負載。
這個轉向很關鍵，因為實際企業裡最花錢的，不一定是發現漏洞本身，而是後面的：
- triage
- prioritization
- false positive reduction
- analyst time allocation
也就是說，SastBench 和 CTI benchmark、SOC benchmark、alert triage benchmark 其實在同一條脈絡上：我們終於不只是問 LLM 會不會答題，而是在問它能不能處理真實安全組織最昂貴的人工瓶頸。
這篇 paper 的限制是什麼？
當然，這篇論文也不是沒有侷限。
- negative class 依然是 heuristic approximation，不是真正逐筆人工驗證的 false positives
- 目前 benchmark 聚焦的是 SAST triage，而不是更廣義的 AppSec remediation / exploitability analysis
- 論文自己也承認，部分 agent evaluation 因成本與 infrastructure 限制，只能跑有限次數
- Semgrep free edition 的選擇雖然務實，但也代表 benchmark 的 finding 分布會受工具特性影響
但這些限制並不會讓 SastBench 失去價值，反而讓它更像一個可持續擴充的基礎設施。作者自己也把它設計成可版本化、可隨 knowledge cutoff 持續更新的 benchmark，這其實比一次性的靜態資料集更有生命力。
總結
SastBench: A Benchmark for Testing Agentic SAST Triage 的核心貢獻，不只是提供一組新的漏洞資料，而是把 benchmark 設計往真實應用安全工作流推近了一大步。
它最重要的訊息是：
評估安全 AI，不能只測模型知不知道漏洞；還要測它能不能在高噪音、強上下文依賴、成本敏感的 triage 流程中做出值得信任的判斷。
如果 CTI benchmark 在問「LLM 懂不懂威脅情報」，SOC benchmark 在問「LLM 會不會處理 alert」，那 SastBench 問的就是另一個同樣昂貴的問題：LLM agent 能不能真正替 AppSec 團隊消化掉那片由誤報堆起來的戰場。
從這個角度看，這篇論文很值得被放進 AI x Security 的長線觀察名單。因為它測的不是漂亮 demo，而是安全團隊每天都在付出人力成本的地方。