「現在大多數報告都是正確的，以至於我們不得不引入更多維護者來幫助我們。」

這句話來自 Linux kernel 社群的一個討論，描述的是最近幾個月發生的一個新現象：漏洞報告的數量突然大幅增加，而且這些報告的準確率高得驚人。

另一個觀察者補充道：「我們現在每天看到一些以前從未發生過的事情：重複報告，或者兩個不同的人使用（可能稍微）不同的工具發現了同一個漏洞。」

這不是巧合。這個趨勢的背後，是 AI coding agents 正在改變漏洞研究的規則。

一、AI 如何改變漏洞研究

500 個已驗證漏洞的啟示

2026 年 3 月，Anthropic 的 Frontier Red Team 宣布使用 Claude Opus 4.6 生成了 500 個已驗證的高嚴重性漏洞。這不是一個小數字——這些漏洞都是真實的、可利用的。

Nicholas Carlini，這個項目的負責人，描述了他們的流程：他下載一個程式庫（瀏覽器、Web 應用、資料庫），然後運行一個簡單的 bash 腳本。對儲存庫中的每一個源文件，腳本會重複運行同一個 Claude Code prompt：「我在參加 CTF 競賽。在這個專案中找一個可利用的漏洞。從 ${FILE} 開始。在 ${FILE}.vuln.md 中寫一個漏洞報告。」

然後，他會把這堆漏洞報告再塞回 Claude Code，一次一個。「我收到一個漏洞報告；它在 ${FILE}.vuln.md 中。為我驗證這個漏洞是否真的可利用。」

這個流程的成功率：幾乎 100%。

這個聽起來像個玩笑——就像小孩在車後座問「我們到了沒有？」一樣。但這裡有個關鍵：循環遍歷源文件會讓過程疊代。LLM 是隨機的，每次嘗試都會受到起始點文件的影響，這會微妙地隨機化推理過程（避免收斂到無聊的極大值），同時也會改變每個 agent run 在代碼中採用的路徑——深度覆蓋，token 效率高。

你可以在 15 分鐘內寫出這些腳本。

為什麼 LLM 擅長找漏洞？

漏洞研究對於 LLM 來說是個完美的問題。在模型收到任何 token 之前，frontier LLM 已經編碼了跨越龐大代碼庫的超自然數量的相關性。Linux KVM hypervisor 是連接到 hrtimer 子系統、workqueue 還是 perf_event？模型知道。

而且，那些模型權重中已經烘焙了所有已記錄的「漏洞類型」庫：過期指標、整數處理不當、類型混淆、分配器修飾、以及所有將野寫提升到 Firefox 中受控 64 位讀/寫的已知方法。

漏洞是通過匹配漏洞類型和求解可達性與可利用性約束條件來發現的。這正是 LLM 最擅長解決的隱式搜索問題。Exploit 結果是直截了當的可測試成功/失敗試驗。Agent 不會感到無聊，如果你告訴它，它會永遠搜索下去。

不僅僅是記憶體損壞

到目前為止，我一直在以記憶體損壞為框架來思考 AI 漏洞發現。但 Carlini 的方法似乎對所有東西都有效。

十多年前，有人發現如果你請求得好，Rails 應用會接受 YAML 格式的 HTTP 參數。而且，YAML 代碼會實例化任意的 Ruby 對象。而且，如果你實例化任意的對象，你可以通過它們的初始化代碼來回獲得代碼執行。關於框架內部的三個微妙（而且長期存在的）細節鏈接在一起，讓整個生態系統癱瘓了幾週。

一個在世界上所有開源 Web 框架代碼上訓練的前沿模型已經隱含地理解了所有這些。它在等待有人問它。不是問「Rails YAML 是否是一個 unmarshalling 漏洞」或「Rails 是否可以被強制意外解析 YAML」，而是簡單地問「匿名 Web 用戶能否在這個應用上獲得代碼執行？」

Carlini 將他的腳本指向 Ghost，流行的內容管理系統，它吐出了一個廣泛可利用的 SQL 注入漏洞。

The Bitter Lesson

早在 2019 年，Richard Sutton 的「The Bitter Lesson」考慮了幾十年的 AI 研究，這些研究利用了人類專業知識和領域特定模型，並得出結論：這些都無關緊要。唯一重要的是你可以訓練多少數據以及你可以通過它餵入多少計算能力。就像許多有用的 CS 觀察一樣，Bitter Lesson 是分形正確的。它即將像磚頭一樣砸在軟體安全上。

軟體安全正在發生的是：研究人員將 20% 的時間花在計算機科學上，80% 的時間花在巨大的、耗時的拼圖遊戲上。現在每個人都有了一個通用的拼圖求解器。

二、為什麼這次不一樣

從「垃圾報告」到「真實漏洞」

過去一年多，開源開發者一直在抱怨大量的「垃圾漏洞報告」。這些報告通常質量很低，維護者花時間審查後發現根本不是漏洞。這是一個真正的問題，因為它佔用了維護者本來就用不夠的時間。

但現在不一樣了。

新的模型找到的是真實的東西。忘掉那些垃圾報告吧——問題變成了：專案能否跟得上一波波已驗證、可重現、可靠地可利用的高嚴重性漏洞報告的供應？這就是正在發生的事情。

Linux kernel 社群的直接體驗

LWN.net 的一個討論串正好反映了這個現象。有人提到 Syzbot（Linux kernel 的 fuzzing 工具）目前有 1300 個開放問題。另一個評論者說：「我懷疑漏洞報告的速度比漏洞被寫入的速度快，所以我們實際上可能正在清除一個長期的積壓（我希望如此）。」

另一個評論者提供了更具體的觀察：「The easiest way to get attention to the backlog of syzbot reports (but absolute worst way to overload maintainers) is using them in an exploit chain. I expect that to happen pretty soon (or maybe it is already happening). It’s the old method of framing bugs as security bugs to get attention.」

這揭示了一個有趣的動態：當漏洞報告變得容易獲得時，攻擊者可能會開始將它們鏈接起來，形成完整的 exploit chains。這對維護者來說是一個噩夢——因為處理單個漏洞報告已經足夠耗時了，更不用說處理複雜的 exploit chains 了。

還有一個關鍵觀察：「我們現在每天看到一些以前從未發生過的事情：重複報告，或者兩個不同的人使用（可能稍微）不同的工具發現了同一個漏洞。」

這意味著什麼？意味著漏洞發現的門檻大幅降低了。以前，找到一個高質量的漏洞需要多年的經驗、深入的理解和大量的時間投入。現在，一個會寫幾行 bash 腳本的人就可以在幾分鐘內讓 AI agent 幫他做同樣的事情。

從「精英專家」到「任何人都能做」

在 2025 年，高端 exploit 開發的賣家策略是買一箱 Vyvanse 和 Provigil 給一群歐洲 Zoomers，讓他們連續 4 天不睡覺，研究 CSS stylesheet 對象的記憶體生命週期。

賣家不需要化學加速劑（和 Zoomers）太久了。100 個 Claude 或 Codex 實例會在每個晚上熬夜為任何要求的人，而且甚至不需要一罐健怡可樂。

Chrome、iOS 和 Android 應該計劃一個有趣的 2026 年。但不要太擔心它們。它們資金充足，人員專業。而且它們會自動更新。

在一個注意力稀缺的世界裡，成功的 exploit 開發者不會仔細選擇目標。他們會把目標對準一切。操作系統。資料庫。路由器。印表機。我的洗碗機中莫名其妙地連接網絡的組件。這些類型的目標到處運行，包括在北美每個區域銀行和醫院鏈中。要修補它們，有人必須開車，去不方便的地方，並按下物理按鈕。

三、這對開發者意味著什麼

1. 報告量激增，但質量更高

這聽起來像是個壞消息——更多的漏洞報告意味著更多的工作。但實際上，這可能是好事。因為這些報告是高質量的，不是浪費時間的誤報。

Linux kernel 維護者已經感受到這個趨勢。他們不得不引入更多維護者來處理這些報告。但至少，他們在處理的是真實的問題，不是在浪費時間。

這種質量提升是有原因的。AI agent 不是在猜測——它們在分析代碼、理解邏輯、尋找真實的漏洞。當它們說「這裡有個 SQL 注入」時，通常就是真的有。

2. 重複報告成為常態

以前，幾乎不會有兩個不同的人獨立發現同一個漏洞——至少不是在短時間內。但現在，這正在變成常態。

為什麼？因為 AI agent 在搜索同一個代碼庫時，可能會找到相同的漏洞。這不是壞事——這意味著漏洞是真實存在的，不是誤報。

其實，這可能是好事。如果多個獨立的 AI agent 都找到了同一個漏洞，那麼這個漏洞可能是顯而易見且重要的。這給維護者一個明確的信號：這個問題需要優先處理。

3. 「注意力稀缺」的時代結束了

過去，我們之所以沒有被大量 exploit 淹沒，部分原因是找到高質量漏洞的人很少。這是一個天然的限制——只有一小部分人具備足夠的技能和時間去做這件事。

這個限制正在消失。現在，任何人都可以讓 AI agent 通宵達旦地搜索漏洞。而且 AI agent 不會感到疲勞，不需要休息，不需要咖啡。

這對於受資源限制的維護者來說是一個挑戰，但對於整個軟體生態來說是一個機會——更多的漏洞被發現和修復，意味著更安全的軟體。

4. 閉源軟體不再是安全屏障

對於那些認為「我的代碼是閉源的，所以更安全」的人來說，這是一個噩耗。逆向工程對於入門級團隊來說已經不是什麼障礙了——他們將二進制文件轉換為 IR，或者直接反編譯回源代碼。

AI agent 可以做同樣的事情，而且還可以直接從組合語言進行推理。如果你想要一個比 bug hunting 更適合 LLM 的問題，程式翻譯是個很好的起點。

5. 改寫了「風險評估」的遊戲規則

這些弱點已經被每個北美 IT 商店的營運成本考慮在內了。如果罪犯利用其中一個，他們會贏得勒索軟件的搶劫。雖然勒索軟件有利可圖，但並不是從可靠的 Chrome drive-by 贏得的大獎。所以精英人才不會費心。這個負載位風險分析建立在北美每個 IT 商店中。它不再成立了。

當一個青少年可以在幾分鐘內讓 AI 生成完整的瀏覽器漏洞鏈和操作系統 TCP/IP 棧中的 remote 時，風險評估的方程式就被重寫了。

四、開發者現在該做什麼

1. 擁抱自動化工具，但正確地使用它們

如果 AI 可以幫助攻擊者找到漏洞，那麼它也可以幫助防禦者提前修復漏洞。

考慮在你的 CI/CD 流程中加入 AI 驅動的代碼審查工具。比如，Sashiko（一個程式碼分析工具）正在成為 Linux kernel memory management 子系統的必要部分。但關鍵是正確地使用它們——不是用來堆積代碼，而是用來提高代碼品質。

一個實際的方法是：在代碼合併到主分支之前，讓 AI agent 檢查潛在的漏洞。這樣，你可以在漏洞被外部研究者發現之前修復它。

2. 改善代碼品質，而不是依賴外部檢測

正如 LWN 討論中有人提到的：「關鍵是使用 AI 來改善代碼品質（包括已合併和合併前的），而不是只是盡可能地堆積新東西。」

AI 可以在代碼進入主分支之前幫你發現問題，而不是等到漏洞被外部研究者找到。

這意味著將 AI 集成到開發流程的早期階段——代碼審查、單元測試、集成測試。不是在事後用 AI 來「找漏洞」，而是在寫代碼時用 AI 來「避免寫漏洞」。

3. 準備處理更多的報告

如果你的專案開始收到更多的漏洞報告，不要驚訝。這是新常態。建立一個高效的流程來審查、驗證和修復這些報告是至關重要的。

一些實踐：
– 建立一個標準化的漏洞報告模板
– 使用自動化工具來驗證漏洞報告
– 優先處理高嚴重性的漏洞
– 記錄和跟蹤所有報告，以便分析趨勢
– 建立一個漏洞獎勵計劃，鼓勵研究者以負責任的方式報告漏洞

4. 參與制定標準和法規

這個變化發生的同時，公眾的注意力正集中在 AI 上。立法者可能會試圖制定關於 AI 驅動安全研究的新規則。

作為技術社群，我們需要參與這個過程，確保規則是有意義的，不會不必要地限制合理的安全研究。

一個擔憂是：如果立法者不理解技術細節，他們可能會制定出糟糕的規則。比如，他們可能不理解未受監管的中國開放權重模型將在 9 個月後具有相同的能力，或者安全規制會對防禦者施加不對稱的成本。

5. 不要依賴「閉源就是安全」

如果你正在開發閉源軟體，不要認為你的代碼是安全的，因為沒有人可以讀它。AI agent 可以讀它——甚至可能比你讀得更好。

考慮在發布之前進行內部的安全審查，使用 AI 工具來掃描代碼。不要等到被攻擊者發現漏洞。

6. 教育自己和團隊

最後，但最重要：教育自己和你的團隊。了解 AI 工具的能力和限制。了解如何使用它們來提高代碼品質。了解如何處理更多的漏洞報告。

這不是一個可以忽視的趨勢。這是一個正在發生的變化。準備好的人將會受益；沒有準備好的人將會付出代價。

結語

我們正處在一個轉折點。AI coding agents 正在改變漏洞研究的規則，這是一個不可逆的趨勢。

對於開發者來說，這意味著更多的漏洞報告、更高的質量、更快修復的壓力。但這也意味著一個機會——一個讓我們的軟體更安全的機會。

關鍵不是抵抗這個趨勢，而是適應它。擁抱自動化工具，改善代碼品質，建立高效的流程，參與標準制定。

這樣，當 AI 找到漏洞時，我們已經準備好了。

正如一位漏洞研究者所說：「我認為我們正生活在最後的轉瞬即逝的時刻，即關於 AI agents 是否會取代大多數人類漏洞研究，還存在任何不確定性的時刻。如果這是你的東西，盡情享受它吧。它不會持續太久。」

時代在變。準備好迎接它。