Project Glasswing: Scaling AI-Driven Vulnerability Research with Mythos Preview
針對網路安全進行特別微調的前沿模型（frontier models）之出現，標誌著從通用型 AI 助手向具備複雜推理能力的專業工具之轉變。Cloudflare 最近參與了 Project Glasswing，利用 Anthropic 的 Mythos Preview 來分析其超過五十個儲存庫（repositories）。其目標不僅僅是為了尋找漏洞，而是為了理解這些模型如何推理其可利用性（exploitability），以及如何建立在大規模部署時所需的基礎設施。
能力的飛躍：超越簡單的漏洞搜尋
根據 Cloudflare 的發現，Mythos Preview 代表了能力的根本性轉變，而非僅僅是對先前模型的改進。雖然通用型模型通常可以識別孤立的漏洞，但它們通常難以彌合懷疑存在缺陷與開發出可運行的漏洞利用程式（exploit）之間的差距。Mythos Preview 在兩個關鍵領域表現出色：
- 漏洞利用鏈構建（Exploit Chain Construction）： 真實世界的攻擊很少依賴單一漏洞。Mythos Preview 可以推理如何將多個低嚴重性的原語（primitives）串聯起來——例如將一個 use-after-free 漏洞轉化為任意讀寫原語——以劫持控制流並獲得完整的系統控制權。這種推理過程模仿了資深安全研究員的工作流程。
- 證明生成（Proof Generation）： 模型不會止步於推測。它可以編寫代碼來觸發漏洞，在 scratch 環境中進行編譯，並執行它。如果執行失敗，模型會分析錯誤，調整其假設，並不斷迭代直到建立起概念驗證（PoC）。
有機拒絕與雜訊的挑戰
即使在沒有標準商業防護措施的受控研究環境中，Mythos Preview 也表現出了「有機拒絕（organic refusals）」。模型偶爾會拒絕合法的安全研究請求，但這些拒絕是不一致的。在一個情境下被拒絕的請求，如果換一種表達方式或環境稍有變動，就可能被接受。
此外，Cloudflare 識別出一個持續存在的「信噪比（signal-to-noise）」問題。AI 模型通常存在尋找漏洞的偏誤，即使在不存在漏洞的地方也會尋找，且經常使用「可能」或「理論上可以」等模稜兩可的語言。這種雜訊會因程式語言而加劇；像 C 和 C++ 這種記憶體不安全（memory-unsafe）的語言比 Rust 這種記憶體安全（memory-safe）的語言會產生顯著更多的誤報（false positives）。
為何通用型編碼代理（Generic Coding Agents）在大規模應用時會失敗
Cloudflare 發現，僅僅將通用的編碼代理指向一個儲存庫是對於全面的漏洞研究而言是無效的。主要存在兩個瓶頸：
- 上下文限制（Context Limitations）： 編碼代理是為線性任務（功能開發或漏洞修復）而設計的。漏洞研究是並行且狹窄的。單個代理會話（agent session）通常在覆蓋不到攻擊面（attack surface）的一小部分之前，就已耗盡其上下文窗口（context window）。
- 吞吐量限制（Throughput Constraints）： 單流代理無法處理大型代碼庫所需的假設數量。無論模型的原始智能程度如何，交互模型本身就會成為瓶頸。
解決方案：多階段發現框架（A Multi-Stage Discovery Harness）
為了克服這些限制，Cloudflare 開發了一個結構化的框架（harness），用於管理多個專業化代理（agents）的執行。這種架構從聊天介面轉向了由狹窄且並行的任務組成的流水線（pipeline）：
| 階段 | 行動 | 目的 |
|---|---|---|
| Recon | 自上而下的儲存庫分析 | 建立架構文件與任務隊列，以防止「漫遊」。 |
| Hunt | 並行攻擊類別搜尋 | 50+ 個並行代理使用 scratch 目錄來尋找漏洞並生成 PoCs。 |
| Validate | 對抗性審查 | 一個獨立的代理會嘗試證偽其發現，以減少雜訊。 |
| Gapfill | 覆蓋率分析 | 重新將已接觸但未深入探索的區域重新排入隊列。 |
| Dedupe | 根因分析（Root cause collapse） | 合併具有相同原因的發現，以避免隊列膨脹。 |
| Trace | 可達性分析 | 確定攻擊者控制的輸入是否能從系統外部實際觸及該漏洞。 |
| Feedback | 閉環處理 | 可達性高的追蹤路徑會成為消費者儲存庫中的新搜尋任務。 |
| Report | 結構化輸出 | 透過預定義的 schema 轉換發現結果為可查詢數據。 |
對安全團隊的戰略意義
能夠更快地發現漏洞的能力，會讓安全團隊產生一種危險的誘惑，即縮短其 SLA（服務等級協議）。例如，有些團隊報告從 CVE 發布到修補的窗口期僅有兩小時。然而，Cloudflare 警告，單靠速度是不夠的。如果回歸測試（regression testing）需要一天，而兩小時的 SLA 要求跳過關鍵檢查，這往往會引入新的、更嚴重的漏洞。
與其僅僅關注修補的速度，重點應該轉向架構韌性（architectural resilience）：即使在存在漏洞時，也要讓漏洞利用變得更加困難。這包括實施防禦措施以阻止漏洞被觸及，設計系統組件之間嚴上的隔離，以及確保能夠立即在全球範圍內部署修補程式。
社群觀點
雖然技術框架很強大，但社群中的一些觀察者對結果的透明度提出了疑問。Hacker News 上的部分用戶指出，該文缺乏關於發現漏洞總數及其嚴重程度的原始數據。其他人則認為，長期的解決方案並非模型護欄（guardrails），模型護欄被他們視為徒勞無功，而是軟體開發方式的根本性轉變——假設每一行代碼都會被前沿 LLM 分析以尋找漏洞利用程式。