為什麼 LLM agents 正在變成真正的漏洞獵手

LLM agents 已經能在真實軟體中找出漏洞，不再只是協助寫程式。

LLM agents 不再只是新奇玩具；它們正在變成實用的漏洞發現工具，而 Linux kernel、Docker、OpenSSL 的最新發現已經證明這一點。這些不是練習題，而是現代基礎設施的核心元件。當一組自我協作的 agents 能在不同程式碼庫中，從大範圍搜尋一路走到可信的 bug 發現，資安研究的玩法就已經變了。

第一個論點

真正的突破不是「LLM 會猜 bug 模式」，而是多個 agents 能像小型研究團隊那樣分工：一個探索程式路徑，一個評估可利用性，一個修正假設，一個避免搜尋卡住。這種編排把模型從聰明的自動補字，變成持續工作的研究者。再加上 activation steering，代表系統不是只對提示詞做反應，而是被導向資安推理模式。

這和傳統 fuzzing 的演進很像。早期 fuzzers 很快，但覆蓋面窄；後來真正有效的流程，是把 fuzzing、symbolic execution、sanitizers 和人工 triage 串在一起。agentic LLM 工作流也是同一條路。重點不是「AI 找到一個 bug」，而是「一個工作流跨過 kernel、container、crypto 三種軟體層，靠多步推理找出漏洞」。這才是值得安全團隊重視的訊號。

第二個論點

在單一應用裡找到缺陷很有用，但同一套流程能在 Linux kernel、Docker、OpenSSL 都挖出可信漏洞，代表的是另一個層級。這三者分別對應現代運算的底層、中層與信任邊界：kernel 決定核心記憶體安全，container 決定隔離與執行環境，OpenSSL 則影響幾乎所有下游產品的機密性與完整性。能同時碰到這三層，表示它不是只學會某個專案的怪癖，而是在學系統軟體的通用推理方式。

這種可遷移性是防守方最該在意的地方。Linux kernel 是最難找遠端可達記憶體破壞漏洞的場域之一，程式碼巨大、歷史包袱重、細節又極度敏感。Docker 的問題會直接影響隔離失效與營運風險。OpenSSL 則可能讓加密信任鏈整個失守。當一條自動化探索管線能碰到這三個領域，瓶頸就不再是「AI 看不看得懂程式」，而是「人類能不能跟上 AI 輔助的偵察速度」。

反方可能怎麼說

懷疑者的論點其實很強：這些系統仍然需要專家監督，漏洞發現不等於穩定利用，更不等於負責任揭露。資安圈看過太多看起來很厲害、實際上卻經不起審查的 demo。若流程依賴大量手工 steering 和精細編排，那它就還不算真正自主；把它講成革命，容易高估方法成熟度。

這個批評是合理的，但它沒有推翻結論。完全自主不是重點，穩定地擴大搜尋空間、產出值得專家驗證的候選漏洞，才是重點。這次在 kernel、Docker、OpenSSL 的成果，已經跨過這條線。即使最後仍要人類確認影響範圍、撰寫報告，最昂貴的初始發現階段已經被明顯壓低成本。限制存在，但那是部署限制，不是重要性限制。

你能做什麼

資安團隊應該停止把 agentic LLM 當成旁支實驗，改把它納入漏洞研究流程。工程師可以把它和 fuzzers、static analysis、sanitizer 輸出串在一起，並在真實程式碼庫上量測 precision、triage 時間與漏洞品質。PM 應該把預算放在評估框架，而不是一次性 demo。創辦人若在做 devtools 或安全工具，應該優先打造讓 agents 能搜尋、排序、交接給人的工作流，因為價值已經出現在這裡；會贏的不是問「agents 能不能找洞」的人，而是把洞變成可處理結果的人。