RealVuln 論文閱讀分析：當大家都說 AI 很會找漏洞，真正該問的其實是它在真實爛程式上到底比誰強

論文基本資訊

• 論文標題：Benchmarking Rule-Based, General-Purpose LLM, and Security-Specialized Scanners on Real-World Code
• 作者：Faizan Raza、Davor Bokan、Niko Balabanić、Sandi Kažazić、Vedran Solić、Marko Štula、Luka Brkić、Marko Andrić
• 年份：2026
• 來源：arXiv:2604.13764
• 論文連結：https://arxiv.org/abs/2604.13764
• 主題：AppSec、SAST、LLM Evaluation、Vulnerability Detection、Secure SDLC、Benchmarking

本文由 AI 產生、整理與撰寫；內容基於論文與可公開查得資料，重點在快速抓主線與實務意義，建議仍搭配原文交叉閱讀。

如果最近一整串 sectools.tw 比較常在談 agent security、prompt injection、runtime boundary、MCP control plane，那這篇 RealVuln 很值得插進來，因為它把焦點拉回一個更老派、但其實更接近開發現場 KPI 的問題：當大家都說 LLM 很會找漏洞時，它到底是在 benchmark 上看起來很強，還是在真實有洞、而且混著陷阱與髒訊號的 codebase 裡真的比較能抓？

我覺得這篇最有價值的地方，不是它又做一個排行榜，而是它把三個常常被混在一起講的世界直接拉到同一個場上比較：

• 傳統 rule-based SAST
• general-purpose LLM
• security-specialized scanner

很多時候業界討論會直接跳成「AI 會不會取代 SAST」，但這問題其實問得太粗。真正該比的不是口號，而是同一批真實 vulnerable repos、同一套 ground truth、同一個 scoring framework 下，到底誰抓得多、誰亂報少、誰更適合 production。

這篇論文在解什麼問題？

作者想解的核心問題很直接：目前不同類型的安全掃描器，在真實世界的程式碼上到底表現如何？

這聽起來像很基本的問題，但其實並不容易回答。因為過去很多比較都卡在幾個老問題上：

• 資料集太小，或者太像 toy examples
• 只測單一工具類型，缺少橫向比較
• ground truth 不夠透明，導致很難重現
• precision / recall 權重沒講清楚，結果容易失真
• 掃出來一堆 issue，但你不知道哪些是真洞、哪些是 trap

RealVuln 的做法是把問題壓回比較乾淨、也比較讓人信服的 benchmark framing：找一批刻意保留漏洞的真實 Python repository，手動標註漏洞與 false-positive traps，然後讓不同類型的 scanner 全部上場對打。

資料集為什麼值得注意？

這篇 paper 最務實的地方之一，是它沒有只拿幾個單檔函式做展示，而是用了 26 個刻意含漏洞的 Python repositories。這些 repo 來自教育用途與 CTF 類應用，雖然不等於大型企業 monorepo，但至少比只測單點 code snippet 更接近「掃描器真的會面對的東西」。

更重要的是，作者不是只標「這裡有漏洞」，而是整理出 796 筆 hand-labeled entries，其中包含：

• 676 個真實漏洞
• 120 個 false-positive traps

這個設計我很喜歡。因為很多工具在 demo 時都很會「找到可疑東西」，但 production 真正最痛的從來不只是漏報，而是你每天得花多少時間清掉那些看起來很像漏洞、其實不是的雜訊。把 false-positive traps 明確放進 benchmark，等於是在逼工具回答一個更現實的問題：你是真的理解漏洞，還是只是對危險關鍵字過敏？

評測對象怎麼分？

作者總共測了 15 個 scanners，分成三類：

• 3 個 rule-based SAST
• 10 個 general-purpose LLM
• 2 個 security-specialized scanners

這樣的分法很重要，因為它把市場上常見的三種期待一次放上檯面：

• 老工具派會問：規則式掃描雖然保守，但會不會其實最穩？
• LLM 派會問：泛用模型是不是已經足以超越老派 SAST？
• 產品導向團隊會問：如果真的要落地，是不是專門為 security 調過的 scanner 才是最實際的解？

RealVuln 的價值就在於，它不是只回答其中一題，而是把三題一起回答。

這篇最值得記的評分設計：F3，而不是只看 F1

作者選擇用 F3 score 當主要排名依據，這一點很關鍵。因為在漏洞掃描場景裡，recall 通常比 precision 更貴、更關鍵——你漏掉一個真洞，後果往往比多報幾個可疑點嚴重得多。

F3 的意思是把 recall 權重大幅拉高，具體來說是 讓 recall 的權重約為 precision 的 9 倍。這個設計其實很符合 AppSec 實務：你可以接受工具偶爾吵一點，但比較難接受它自信滿滿地把真洞放掉。

同時作者也不是只看 F3，還有一起看 F1。這樣就能觀察一個很實務的現象：有些工具在 recall-prioritized 的世界裡很強，但如果你把 precision 拉回來，它的排名可能會換位置。

結果非常直白：三層分化，而且分得很開

論文最醒目的結論之一，是在不同 metric 下都出現很明確的 three-tier ranking：

• 第一層：security-specialized scanner
• 第二層：general-purpose LLM
• 第三層：rule-based SAST

如果只看作者主打的 F3：

• 表現最好的 security-specialized scanner 達到 73.0
• 最佳的 general-purpose LLM（Claude Sonnet 4.6）是 51.7
• 最好的 rule-based 工具（Semgrep）只有 17.7

這個差距其實非常大。尤其是後兩者之間，作者直接點出：最佳泛用 LLM 的 F3 幾乎是最佳規則式工具的三倍。

如果改看 F1，順序會稍微變一下：Claude Sonnet 4.6 反而跑到第一，分數是 60.9，而 specialized scanner 約是 52.4。這代表什麼？代表泛用 LLM 的優勢不只是「比較會亂抓」，而是它在 precision / recall 平衡下也有很強競爭力；只是當你更強調 recall 時，專門為 security 調過的工具還是更占上風。

這篇 paper 真正想提醒的是：不要再把「LLM 很強」講得太抽象

我覺得 RealVuln 真正有用的地方，是它把一些原本很模糊的產業敘事拆清楚了。

例如以前常會聽到兩種極端說法：

• 「SAST 已經過時了，LLM 會全面取代它」
• 「LLM 都只會 hallucinate，安全掃描還是得靠老工具」

這篇的結果其實比較像第三種、更接近現實的答案：

泛用 LLM 的確已經比傳統 rule-based SAST 強不少，但如果你要的是在 recall-heavy 的安全情境下穩定抓洞，專門針對 security 任務打造的 scanner 目前仍然明顯更有優勢。

也就是說，這不是「AI 打贏傳統工具」這麼簡單，而是市場其實開始長出更細的分層：

• rule-based 工具仍有價值，但比較像 baseline / hygiene layer
• general-purpose LLM 已經能提供實用的上限提升
• security-specialized scanner 才最像真正朝 production optimization 走的那一層

為什麼這件事對 AppSec 團隊重要？

如果你是 AppSec、product security 或安全平台團隊，這篇 paper 的實務意義很直接。

第一，它提醒你 evaluation 不能再只做模型內比較。 很多團隊現在會問「GPT-4o 和 Claude 哪個好」「這個 security LLM 有沒有比一般模型強」，但更該問的是：和你今天已經在跑的 Semgrep、CodeQL、Snyk、各種既有 pipeline 比，新增這層 AI 到底多帶來多少 net value？

第二，它提醒你 metric 要和場景一起選。 如果你的場景是 PR gate、開發者本地掃描，precision 很重要；但如果你的場景是 release 前的深度審查、紅隊前置盤點、或高風險程式的定期健檢，那 recall 權重就應該拉高。同一個工具，在 F1 和 F3 下的排名變化，本身就是 deployment decision 的訊號。

第三，它提醒你 benchmark quality 本身就是安全問題。 沒有 false-positive traps、沒有手工 ground truth、沒有跨類型比較的評測，最後很容易只是在幫某種工具類型做行銷，而不是幫團隊做選型。

這篇和最近 sectools.tw 主線怎麼接？

雖然 RealVuln 看起來不像最近那一串 agent security 論文那麼「agentic」，但它其實剛好補上另一個很重要的現實面：當大家把 AI 安全系統講得越來越像自主 agent，底下真正要接 production 的很多能力，最後仍然要回到可評測、可選型、可交付的 security tasks。

換句話說，前面幾篇比較像在問：

• agent 會不會被帶偏？
• protocol 能不能驗證？
• runtime boundary 站不站得住？

而 RealVuln 問的是另一個同樣關鍵的問題：

就算你把 agent 安全邊界都補好了，它在最基本的漏洞辨識任務上，實際能力到底在哪？

這題很樸素，但很重要。因為如果底層 security capability 評測本身就不紮實，那上面再漂亮的 orchestration、planning、delegation，最後也可能只是把不穩定的判斷包裝得更像系統。

限制也要講清楚

當然，這篇 paper 也不是沒有邊界。

• 語言範圍目前是 Python，還不能直接外推到多語言大型系統
• repo 來源偏教育 / CTF / 刻意脆弱應用，和真實企業產品 still 有差距
• specialized scanner 的領先 很有價值，但也可能受產品成熟度、prompt / orchestration 細節影響
• benchmark 再真，也不等於完整 SDLC，因為真正落地還會牽涉 triage 成本、修補建議品質、重現能力與 developer adoption

不過我反而覺得作者對這些限制處理得算誠實。它沒有把 RealVuln 包裝成終極答案，而比較像是在說：如果你真的想比較不同掃描路線，至少先把比賽場地搭得像樣一點。

重點整理

• RealVuln 是一個針對真實脆弱程式碼的開放 benchmark，用來比較 rule-based SAST、general-purpose LLM、security-specialized scanner。
• 資料集包含 26 個刻意含漏洞的 Python repositories 與 796 筆人工標註條目，其中有 676 個真漏洞 和 120 個 false-positive traps。
• 作者共評測 15 個 scanners：3 個規則式工具、10 個泛用 LLM、2 個安全專用工具。
• 主要排名指標使用 F3，讓 recall 權重約為 precision 的 9 倍，更貼近漏洞掃描的實務需求。
• 在 F3 下，最佳 specialized scanner 為 73.0，最佳泛用 LLM（Claude Sonnet 4.6）為 51.7，最佳規則式工具（Semgrep）為 17.7。
• 在 F1 下，Claude Sonnet 4.6 反而以 60.9 領先，specialized scanner 約為 52.4，顯示 metric 選擇會直接影響選型判斷。
• 整體結果出現穩定的 三層分化：security-specialized scanner ＞ general-purpose LLM ＞ rule-based SAST。
• 這篇最值得記住的一句話是：泛用 LLM 已經明顯超過老派規則式掃描，但真正面向 production 的漏洞偵測優勢，現在仍然更像是 specialized security system 的戰場。

Takeaway

RealVuln 真正有用的，不只是證明哪個工具現在分數最高，而是幫大家把一個常常被講得太抽象的問題講清楚：AI 在漏洞掃描上的進步是真的，但它不是單純「LLM 打贏老工具」這麼粗；真正重要的是你到底在比哪一類系統、用什麼 metric、對哪種實務場景做選型。 如果你的目標是把 AppSec 從工具信仰拉回 evidence-based evaluation，這篇 paper 很值得收進清單。