TitanCA 論文閱讀分析：真正讓漏洞 AI 開始有產線味的，通常不是模型變神，而是終於有人把誤報漏斗做對
論文基本資訊
- 論文標題：Lessons from Orchestrating LLM Agents to Discover 100+ CVEs
- 作者：Ting Zhang、Yikun Li、Chengran Yang 等
- 年份：2026
- 來源：arXiv:2604.17860
- 論文連結：https://arxiv.org/abs/2604.17860
- 主題：LLM Agents、漏洞挖掘、SAST、零時差漏洞、CVE、Agent Orchestration
這篇 Lessons from Orchestrating LLM Agents to Discover 100+ CVEs 最有意思的地方，不是它又來一次「LLM 也能找漏洞」，而是它把真正困難的那段講得很清楚：如果你想把漏洞 AI 從 demo 變成可以持續產出 CVE 的 production pipeline，重點通常不在單一模型多聰明，而在你怎麼把 matching、filtering、inspection、adaptation 這幾段串成一條不會被誤報淹死的流程。
作者提出的系統叫 TitanCA，由新加坡管理大學與 GovTech Singapore 合作開發。論文裡最吸睛的數字是：在開源軟體上，TitanCA 已經找出 203 個確認的 zero-day vulnerabilities，並產生 118 個 CVEs。這不是一般 benchmark 上多拿幾分的故事，而是直接把成果放進真實漏洞揭露與修補脈絡裡。
所以這篇文章真正值得讀的，不只是「它找到了很多洞」，而是它背後那個更重要的命題：
要讓 LLM agents 在漏洞研究上真的有產出，核心不是讓它像人一樣想，而是讓它在對的階段只做對的事，並且把錯誤盡可能在前面就篩掉。
這篇論文在處理什麼問題？
作者一開始就點出傳統 Static Application Security Testing（SAST） 的老問題：它很適合當第一道防線，但長期都被高 false-positive rate 拖住。掃描器能吐出一大堆疑似弱點，卻不代表那些 issue 真的構成可利用、可驗證、值得工程團隊處理的漏洞。
也就是說，真實世界的痛點從來不只是「找不到 candidate」，而是：
- 候選太多，人工 triage 成本太高
- 很多警報根本不成立
- 不同弱點類型需要不同檢查邏輯
- 即使模型能看懂部分 code，也很難穩定地把發現一路推到可確認漏洞
TitanCA 想處理的，就是這條從 大規模候選訊號 到 可確認漏洞 的落差。它不是直接讓單一 agent 對整個程式庫自由探索，而是把任務拆進多個模組，讓每一段只承擔一部分風險。
核心觀點：漏洞 AI 的瓶頸，常常不是 recall，而是 precision 與工作流設計
如果把 TitanCA 放進近一年一堆 AI for AppSec 論文裡看，我會覺得它最有價值的地方，是它很務實。很多研究喜歡展示模型能看懂 CWE、能做 exploit reasoning、能在某個資料集上比 baseline 好；但真要落地時，團隊最先撞到的通常不是「模型完全看不懂」，而是：
- 它會講很多看起來合理、但其實不成立的弱點故事
- 它會把一般 code smell 說成可利用漏洞
- 它很難在大型 codebase 中穩定縮小搜索面
- 它對不同專案、不同語言、不同缺陷型態的泛化不一致
TitanCA 的 framing 幾乎就是在回答這些問題。作者沒有把 LLM 當萬能漏洞獵人，而是把它放進一個多階段降噪與聚焦的管線裡。換句話說，這篇 paper 真正講的是：生產級漏洞代理系統的關鍵，不是 one-shot brilliance，而是 staged narrowing。
TitanCA 的四模組架構
根據摘要，TitanCA 的整體流程由四個模組組成：
- Matching
- Filtering
- Inspection
- Adaptation
雖然論文摘要沒有把每一模組的所有內部細節完整展開，但光看這四段切法，就已經很能反映作者的工程思路。
1. Matching：先把可能相關的弱點模式對上去
我對 matching 的理解，是先把大型 codebase 中可能與特定漏洞模式相關的區塊、函式、資料流或規則特徵拉出來，讓系統不要從零開始盲找。這一步的重要性在於：你必須先縮小戰場，後面的 agent 才不會把 token 與推理預算浪費在大片無關程式碼上。
這有點像把傳統 SAST 或規則式訊號，從「終點判決器」降級成「候選生成器」。它不負責最後定案，但負責把搜尋空間變得可控。
2. Filtering：把最明顯的誤報先擋掉
這一步大概是整條管線能不能活下去的關鍵。因為如果 matching 送來的 candidate 沒有經過有效過濾，後面的 inspection agent 只會被海量垃圾訊號淹沒。
也就是說，filtering 的意義不是追求完美，而是先把那種一眼就不值得深挖的候選排掉，讓高成本推理資源只用在比較有希望的地方。從工程角度看，這其實比再疊一層 fancy reasoning 還重要，因為它直接決定系統吞吐量與人類 reviewer 的負擔。
3. Inspection：把疑似問題往真正漏洞推進
到了 inspection，任務就不再只是「這裡看起來怪怪的」，而是要回答更接近漏洞研究員的問題：
- 這段 code 是否真的存在安全邊界被破壞的可能？
- 攻擊前提是什麼？
- 是否能形成可利用路徑？
- 屬於哪類漏洞？風險影響在哪？
這一步其實就是把 pattern-level suspicion 往 vulnerability-level claim 推進。很多 AI 弱點工具最終失敗，常常就卡在這裡：它能講得頭頭是道，但講不出足以讓 maintainer 採信的證據鏈。
4. Adaptation：讓系統會針對不同專案與漏洞樣態調整
Adaptation 很值得注意，因為這代表作者知道漏洞挖掘不是固定配方。不同專案、語言、框架與漏洞家族，往往需要不同檢查策略。若系統沒有某種自我調整或策略切換能力，很容易在一個資料分布上有效，換個 target 就整段失靈。
所以 TitanCA 不是只想做一條硬編排流水線，而是想保留一點能根據場景調整的彈性。這也是它比單一 SAST + LLM 補丁式整合更像「agent orchestration」的地方。
為什麼這篇論文的重要性，遠超過「又一個找到 CVE 的 agent」？
因為它把一件常被模糊帶過的事說破了：真實漏洞研究不是單次推理，而是多階段證據累積。
我們很容易被「LLM 發現了幾個漏洞」這種 headline 吸走注意力，但真正能不能在 AppSec 流程裡造成影響，要看的是：
- 能不能穩定在大量專案中跑
- 能不能把誤報壓到人能處理的程度
- 能不能把發現轉成可揭露、可修補、可分配 CVE 的成果
- 能不能持續運作，而不是一次性的 showcase
TitanCA 的 203 個 confirmed zero-days 與 118 個 CVEs，真正代表的不是單點 capability，而是這條 pipeline 至少在某種程度上已經跨過了「研究展示」和「實際產出」之間那條很難的線。
和傳統 SAST 的關係：不是取代，而是重新分工
我不會把這篇論文讀成「LLM agent 將取代 SAST」。比較合理的讀法是：SAST 依然是高覆蓋率的第一層訊號來源，但它不再被期待自己完成整個漏洞確認流程；後面的 agent orchestration 才負責把大量候選慢慢收斂成高可信漏洞。
這種分工其實很聰明：
- SAST 擅長便宜、快速、大規模掃描
- LLM agents 擅長在較小範圍內做語意整合、上下文理解與策略性檢查
- 人類研究員 則保留在高價值確認、揭露與修補溝通階段
這樣看，TitanCA 其實更像是把漏洞研究流程做成一條 human-scalable funnel，而不是幻想模型可以完全單飛。
這篇論文透露出一個很重要的產業訊號
當一篇 paper 開始不只講 benchmark，而是直接分享「建置與部署這類 LLM-based vulnerability discovery solution 的實務經驗」，我會把它解讀成一個明確訊號：AI for vulnerability research 正在從能力驗證階段，往流程工程與營運工程階段移動。
這個轉折很關鍵。因為到了這個階段，大家真正要比的就不只是誰的 prompt 比較花，而是：
- 誰的 candidate generation 更有效
- 誰的 filtering 更能壓低誤報
- 誰的 inspection 更能產生 maintainer 願意採信的證據
- 誰的 adaptation 更能跨專案複用
換句話說，TitanCA 這篇 paper 的價值，在於它把「漏洞 AI」從模型能力問題，重新拉回系統設計問題。
這篇論文的限制也很值得記住
當然，光看摘要也能預期一些限制：
- 找到很多 zero-day 與 CVE，不等於整體 precision / recall 已經充分透明
- 不同語言、框架、程式類型上的泛化表現，可能仍有很大差異
- 若上游 matching / filtering 偏了，後面 agent 再強也只是在錯的候選上深挖
- 真實可利用性、修補成本與維護者接受度，仍然不是 purely model-side 問題
不過也正因為如此，這篇 paper 才更有參考價值。它沒有把故事停在抽象的「LLM 很有潛力」，而是用真實產出提醒大家：漏洞代理系統最難的，從來不是會不會說 CWE 名詞，而是能不能把搜尋、過濾、檢查與調整做成一條長期穩定的生產線。
我怎麼看這篇論文？
如果要我用一句話總結 TitanCA，我會這樣說：
真正讓 AI 漏洞挖掘開始有「產線味」的，未必是模型忽然變成超強研究員，而是終於有人把它塞進一個知道怎麼縮小搜索面、怎麼過濾誤報、怎麼逐步驗證的多代理流程。
這篇文章最值得 sectools.tw 讀者記住的，不是 118 個 CVE 這個 headline 本身，而是那個更深的 lesson：在漏洞研究裡，AI 的真正價值往往不是 magical discovery，而是把原本又吵、又散、又高誤報的候選空間，慢慢收斂成可以被人類接手的高品質發現。
如果之後這條路線持續成熟，那 AppSec 團隊的工作重心很可能會跟著變：從自己親手翻每個 candidate，變成設計更好的 orchestration、驗證介面、證據模板與 disclosure workflow。那時候，比起問「LLM 會不會找漏洞」，更重要的問題會是：你有沒有一條能把模型輸出變成真正漏洞成果的工作流。
重點整理
- TitanCA 聚焦的不只是漏洞偵測，而是把 LLM agents 組成可持續產出 CVE 的漏洞發現流程。
- 論文核心不是單一模型能力，而是 matching、filtering、inspection、adaptation 四段式編排。
- 這個架構本質上是在處理 SAST 長期最痛的問題：高誤報與高 triage 成本。
- 203 個 confirmed zero-days、118 個 CVEs 的意義，在於它顯示這條 pipeline 已經部分跨進真實世界漏洞揭露。
- 這篇 paper 最值得記住的 lesson 是：漏洞 AI 能不能落地，關鍵常常不在模型本身，而在整條降噪、聚焦、驗證的 orchestration 設計。
免責聲明
本文由 AI 產生、整理與撰寫。內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要；儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。