當您的 Agent 發現漏洞

Anthropic 研究科學家 Nicholas Carlini 將 Claude Code 對準 Linux 核心原始碼，要求它找出漏洞。整套配置不過是一個 10 行 bash 腳本加上一個啟用 ASAN 建置的 Docker 容器。逐一遍歷原始碼檔案，要求模型尋找漏洞，然後處理下一個檔案。¹³

結果令人震驚，Michael Lynch 在其演講整理文章中詳述了細節：²一個位於 NFSv4 LOCK 重放快取中、可遠端利用的堆緩衝區溢出漏洞，自 2003 年 3 月起便已存在——比 Git 本身還早。兩個合作的 NFS 用戶端可以用 1,024 位元組的 lock owner ID 溢出 112 位元組的緩衝區，藉此讀取敏感的核心記憶體。Carlini 在同一輪掃描中至少又發現了四個核心漏洞。此外，同樣的方法論向 Mozilla 提交了 122 個觸發崩潰的輸入，其中 22 個獲得了 CVE 編號。³ 他表示還有「數百個崩潰」尚未來得及驗證和回報。²

這些都是已確認並回報給維護者的漏洞，由使用 Opus 4.6 的 agent 發現——正是開發者日常用於程式碼審查、重構和功能開發的同一模型系列。Carlini 於 2026 年 4 月在 [un]prompted AI 安全研討會上發表了這些發現。¹

重點摘要

Carlini 的方法極為精簡：遍歷原始碼檔案，提示 Claude 在每個檔案中尋找漏洞，用 ASAN 斷言驗證結果。Opus 4.6 發現的漏洞數量遠超 Opus 4.1（早 8 個月）和 Sonnet 4.5（早 6 個月），顯示某個能力門檻已在近期被突破。² 瓶頸如今在於人工驗證，而非 AI 發現。這對從業者建構安全 hook、執行程式碼審查，以及思考 agent 輔助稽核的方式都有直接影響。

關鍵要點

• 安全工程師：這項能力真實存在且進步飛速。若您正在使用 agent 輔助程式碼審查，您的 PreToolUse 安全 hook 比以往更加重要——不是為了阻擋 Claude，而是為了管控它對所發現問題的處置方式。
• Harness 建構者：驗證瓶頸（「數百個我尚未驗證的崩潰」）是 harness 層面的問題。自動化分類、去重和嚴重性評級是下一層基礎設施。
• 其他所有人：同一個導致 446 倍效能衰退的模型，同樣能找到 23 年來人類審查所遺漏的漏洞。兩者同時為真。

方法論

Carlini 的方法既不需要客製化安全框架，也不需要微調模型或特殊提示詞。他形容整套工具不過是「一個 10 行 bash 腳本加上 Docker 容器」：³

1. 使用 ASAN（AddressSanitizer）插樁編譯目標程式
2. 遍歷原始碼檔案，由模型評估安全相關性
3. 對高相關性檔案，以 capture-the-flag 框架提示 Claude Code
4. 對每個目標進行多輪掃描（視程式碼庫規模 5-20 輪不等）
5. 使用自動化批評 agent 在揭露前驗證發現

Capture-the-flag 框架至關重要。告訴模型「這段程式碼有漏洞」所啟動的模式，與「檢查這段程式碼是否有問題」截然不同。開發者在日常使用中也注意到同樣的現象——當你告訴 Claude 問題確實存在時，它找出的問題比你詢問「是否可能存在問題」時更多。²

整輪掃描的成本以 API token 計算，而非以人月計。Carlini 使用一個通用的 agent CLI，就找到了五個已確認的 Linux 核心漏洞和 22 個 Firefox CVE。³ 正是那個幫你寫單元測試、整理 import 的同一工具。

能力門檻

最引人注目的發現是模型世代間的差距。Carlini 嘗試用舊版模型重現結果：²

• Opus 4.6（演講前約 2 個月發布）：找到了堆溢出漏洞及多個額外漏洞
• Opus 4.1（8 個月前）：僅找到極少數
• Sonnet 4.5（6 個月前）：僅找到極少數

某個門檻在模型世代之間被跨越了。在上下文中持有複雜程式碼庫、跨函式邊界推理資料流、辨識微妙的規格不匹配——這些能力似乎是突然湧現的，而非漸進提升。

Carlini 直言不諱：「我這輩子從來沒找到過這種漏洞。這非常、非常、非常困難。有了這些語言模型，我已經有一大堆了。」²

矛盾之處

同一套 agent 架構，一方面導致效能衰退——118 個函式出現 3 倍到 446 倍的速度下降——另一方面卻能找出數十年來專家人工審查所遺漏的安全漏洞。這是同一能力特徵的互補面向。漏洞研究本質上是對已知類別（緩衝區溢出、use-after-free、整數符號問題）進行模式比對，恰恰是 LLM 的強項。⁴ 效能最佳化則需要相反的能力：推理特定的執行脈絡、快取行為和演算法複雜度。模型能在數百萬行程式碼中辨識出緩衝區溢出，卻無法判斷在您的存取模式下雜湊表是否比排序陣列更慢。請據此設計您的 harness——安全 hook 負責標記發現，效能 hook 負責在提交前進行量測。

驗證瓶頸

Carlini 最具啟發性的坦言：「我在 Linux 核心中找到了太多漏洞，多到無法回報，因為我還沒有驗證完。」²

瓶頸已從發現轉移到分類。發現潛在漏洞的成本，如今低於確認其真實性的成本。這為安全團隊帶來了新的基礎設施挑戰：

發現已自動化。一個 agent 能在數小時內掃描整個程式碼庫。

驗證仍需人工。每個潛在漏洞都需要概念驗證、影響評估和負責任的揭露流程。

分類是斷層所在。將數百個 agent 生成的發現區分為真實漏洞、誤報和低嚴重性雜訊——這項工作尚缺乏完善的工具支援。

這與我們在 agent 輔助程式碼審查中觀察到的模式如出一轍：agent 產出原始結果的速度，遠超人類評估的速度。價值不在於生成本身，而在於處理、過濾和分流產出的基礎設施。

對 harness 建構者而言，下一個高價值 hook 不是安全掃描器，而是安全分類系統：去重、嚴重性分級、誤報過濾和自動概念驗證生成。管控 agent 輸出的治理 hook 比掃描能力本身更為重要。

對從業者的意義

如果您在生產環境的程式碼庫上執行 Claude Code，您已經在運行一個具備發現真實漏洞能力的系統。問題不在於能力是否存在，而在於您的 harness 是否能妥善處理 agent 所找到的結果。

三項實際行動：

在審查流程中加入安全掃描。在 Write/Edit 上設置 PostToolUse hook，可對已更動的檔案觸發定向安全掃描。此 hook 從 stdin 讀取檔案路徑（Claude Code 透過 stdin 將事件 JSON 傳遞給 hook）：

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking — runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

這只是起點，尚非可直接上線的版本——您還需要加入去重、嚴重性過濾和速率限制。但核心模式與 Carlini 的方法一致：對檔案進行迴圈，搭配定向提示。³

建構分類基礎設施。缺乏嚴重性分級的原始漏洞發現不過是雜訊。若您的 agent 每輪掃描產出 50 項發現，在人工查看之前，您需要自動化去重和優先順序評分。這是 harness 問題，而非模型問題。

接受這個矛盾。需要效能防護措施的同一個模型，確實擅長安全模式比對。設計您的 harness 以發揮其優勢、彌補其弱點。安全 hook 負責掃描，效能 hook 負責量測，品質 hook 負責驗證。各自覆蓋彼此的盲區。

那個存在 23 年的 Linux 漏洞並非深藏不露，它就擺在眾目睽睽之下，存在於數千名工程師都讀過的檔案中。模型之所以找到它，正因為大規模模式比對是這類系統的本職。教訓不在於 agent 比人類更擅長安全工作，而在於 agent 覆蓋了不同的面向——而協調兩者的 harness 才是使組合可靠的關鍵。

參考來源

常見問題

我能用 Claude Code 重現 Carlini 的方法嗎？

方法論記載於 podcast 訪談中。³ 核心迴圈：用 ASAN 編譯、遍歷原始碼檔案、以 capture-the-flag 框架提示 Claude、驗證結果。Carlini 指出 Opus 4.6 發現的漏洞數量遠超舊版模型——使用其他模型世代的結果可能不同。

這是否意味著 AI agent 比人類更擅長找安全漏洞？

並非如此。這意味著 agent 覆蓋了不同的面向。Agent 擅長在大型程式碼庫中對已知漏洞類別進行模式比對；人類則擅長理解新型攻擊向量、商業邏輯缺陷和情境相關的安全屬性。兩者結合比單獨任何一方更強。

我是否應該擔心攻擊者利用這項能力？

Carlini 明確警告「一波大浪即將來襲」。幫助防禦者發現漏洞的同一項能力，攻擊者同樣可以取用。不對稱之處在於：防禦者可以自動化分類和修補，而攻擊者仍需開發利用程式——但發現環節的差距正在縮小。