過去幾個月，我們在自己的基礎架構上測試了一系列以安全為重點的 LLM。這些 LLM 能幫助我們找出自身系統中的潛在弱點，以便我們進行修補，同時也能讓我們看到攻擊者將能如何利用最新的模型。
在這些 LLM 中，Anthropic 推出的 Mythos Preview 最受矚目。幾週前，我們受邀參與 Project Glasswing，並獲准使用 Mythos Preview。我們很快地將它指向我們自己的五十多個程式碼存放庫——想看看它會發現什麼問題，也想瞭解它的運作方式。
這篇文章將分享我們觀察到的結果、模型的優缺點，以及為了能大規模使用這類模型，其架構與相關流程需要做出哪些改變。
在深入討論之前，有必要明確指出：Mythos Preview 確實是一大進步。我們已經在自己的程式碼上執行模型一段時間了，而從先前通用型前沿模型所能達到的水準，到現在 Mythos Preview 能做到的事，這之間的進步不僅僅是對既有技術的改良。
它更像是一種全新的工具，執行著不同類型的工作，因此很難與早期模型進行直接的對比評測。因此，與其試圖將 Mythos Preview 拿來與通用型前沿模型做基準測試，不如具體描述它的實際能力。在我們使用 Mythos Preview 的過程中，有兩大特點尤其突出：
漏洞鏈建構：真正的攻擊很少只依賴單一漏洞，而是將多個小型攻擊原語串聯成有效的攻擊鏈。例如，它可能將一個釋放後使用 (use-after-free) 漏洞轉化為任意讀寫原語，接著劫持控制流程，再利用返回導向程式設計 (ROP) 鏈完全掌控系統。Mythos Preview 能夠整合多個此類原語，並推理如何將其組合成有效的攻擊證明。其推理過程展現的思維深度，更像是資深研究員的成果，而非自動化掃描工具的輸出。
產生攻擊證明：找出漏洞與證明該漏洞可被利用是兩件不同的事，而 Mythos Preview 兩者都能做到。它會撰寫能觸發可疑漏洞的程式碼，在隔離環境中編譯該程式碼，並執行它。如果程式照模型預期的方式運作，那就得到了證明。如果沒有，模型會讀取失敗訊息、調整它的假設，然後再試一次。這個反覆嘗試的循環，與它找到的漏洞本身同樣重要，因為沒有實際可運作證明的可疑漏洞只能算是推測，而 Mythos Preview 能自行補足這個差距。
以上描述的一些功能並非 Mythos Preview 所獨有。當我們利用同一套測試框架對其他前沿模型進行測試時，它們也發現了不少相同的底層漏洞，在某些情況下，它們在推理方面甚至表現得比我們預期的更好。它們的不足之處在於「串聯環節」：模型可能識別出一個值得關注的漏洞，並詳細闡述其重要性，隨後便止步於此——既未完成實際的攻擊鏈，也未對該漏洞是否可被利用給出定論。Mythos Preview 帶來的改變在於，模型現在能夠擷取那些低嚴重性的漏洞（傳統上會被默默擱置在待辦事項清單中），並將它們串聯成一個單一、更嚴重的攻擊利用鏈。
Anthropic 提供的 Mythos Preview 模型（作為 Project Glasswing 的一部分）並未具備一般公開模型（如 Opus 4.7 或 GPT-5.5）所搭載的額外安全防護機制。
即便如此，該模型仍會自主地拒絕某些請求——就像其用於漏洞探尋的網路安全能力一樣，模型自身也產生了某種自發的防護機制，有時會對合法的安全研究請求表現出抗拒。但我們發現，這種自發的拒絕行為並不具有一致性：同一項任務，若以不同方式描述或置於不同的情境中，可能會產生完全不同的結果，如下方範例所示。
Mythos Preview 拒絕建構有效概念驗證的範例
例如，模型最初拒絕對某個專案進行漏洞研究，但在該專案環境經過一次不相關的變更後，卻同意對相同程式碼進行相同的研究。被分析的程式碼本身並無任何改變。
另一個案例是，模型在一個程式庫中發現並確認了數個嚴重的記憶體漏洞，隨後卻拒絕撰寫示範用的攻擊程式。相同的請求，換個說法，就能得到不同的回應；甚至由於模型的機率性本質，相同的請求在不同次執行中也可能產生不同的結果。語意上相同的任務，可能因為提交給模型的方式與時機不同，而產生相反的結論。
這點很重要，因為雖然模型自發拒絕行為/防護機制確實存在，但它們的穩定性並不足以單獨構成一個完整的安全邊界。正因如此，任何未來將公開釋出的強大網路前沿模型，都必須在此基礎行為之上，加入額外的安全措施——唯有如此，才能確保其在脫離 Project Glasswing 這類受控研究環境之後，依然能夠安全、恰當地應用於更廣泛的領域。
對安全漏洞進行分類整理時，最困難的部分之一就是判斷哪些漏洞是真實的、哪些是可被利用的，以及哪些需要立即修復。即使在 AI 時代之前，這也是個棘手的問題。AI 漏洞掃描器和 AI 產生的程式碼讓情況變得更糟，而在 Cloudflare，我們已經建立了多個後驗證階段來處理這個問題。
雜訊率主要受兩個因素影響：
程式設計語言：C 和 C++ 語言讓開發人員能直接控制記憶體，同時也帶來了緩衝區溢位、越界讀寫等漏洞類別。而 Rust 等記憶體安全語言則在編譯時期就消除了這些問題。我們從使用非記憶體安全語言編寫的專案中，持續觀察到更多的誤判。
模型偏差：優秀的人類研究人員會告訴您他們發現了什麼以及他們的信心程度。模型則不會。要求模型尋找漏洞，無論程式碼實際上是否有漏洞，它都會「找到」一些。其發現結果往往伴隨著「可能」、「潛在」、「理論上可以」等不確定的措辭，而這種模棱兩可的發現數量遠遠超過可靠的發現。對於一個探索性的工具來說，這是一種合理的偏差。但對於漏洞分類處理來說，這卻是災難性的，因為每一個推測性的發現都會耗費人力與詞元 (token) 去逐一甄別並駁回，這個成本在成千上萬個發現中會持續累加。
在這方面，Mythos Preview 帶來了明顯的改進，尤其是其串聯攻擊原語的能力——它能將多個漏洞組合成一個可運作的概念驗證，而不是單獨回報它們。一個附帶概念驗證的發現，是一個可以立即採取行動的發現，這意味著花在詢問「這到底是不是真的？」上的時間將大幅減少。
我們的測試框架經過了刻意調優，傾向於採取「過度報告」的策略，旨在盡可能多地捕獲潛在問題（從而減少遺漏）；但同時也帶來了更多雜訊。然而，在分類處理階段，Mythos Preview 的輸出明顯具有更高的品質：不確定的發現更少、重現步驟更清晰，並且能更快速地做出修復或駁回的決定。
當我們去年剛開始進行 AI 輔助的漏洞研究時，我們的第一直覺很顯而易見：把一個通用型的編碼智慧體指向一個任意的程式庫，然後叫它去發掘漏洞。從某種意義上說，這種方法確實「有效」——模型確實能產出一些發現；但它無法有效地涵蓋一個真實程式碼庫的全貌，也無法找出真正有價值的漏洞。主要原因有兩個：
脈絡侷限 – 編碼智慧體專注於單一、連貫的工作流程：開發一個功能、修復一個錯誤、撰寫重構程式碼。它們會攝入大量原始碼，一次只聚焦於一個單一的假設，並圍繞該假設進行迭代。這完全不符合漏洞研究的形態，因為漏洞研究本質上是細分且並行的。人類研究人員會挑選一個特定的事物來仔細調查。那個特定事物可能是一個單一複雜的功能、跨安全邊界的轉換，或是某個特定的漏洞類別（如命令插入，攻擊者的輸入最終會被當作 shell 指令執行）。然後他們會針對不同的功能、安全邊界或漏洞類別，在整個程式碼庫中重複這個過程數千次。一個單一的智慧體工作階段（即使有子智慧體）在面對一個包含十萬行程式碼的存放庫時，可能僅僅只能有效處理不到千分之一的程式碼範圍，然後模型的脈絡視窗就會被填滿，並會開始壓縮資料。然而，一旦啟動壓縮，模型就可能會把先前找到的重要漏洞給丟掉。
輸送量限制 - 單一串流的智慧體一次只能做一件事，但真實的程式碼庫需要同時針對許多元件提出許多假設，並能在發現有趣線索時進一步擴展探索。您可以更用力地驅動單個智慧體，但到某個臨界點，限制因素將不再是模型本身，而是互動模式的本質。對於人工調查，當研究員已有線索並需要第二雙眼睛時，直接在編碼智慧體中使用模型是可行的。然而，要達到高覆蓋率，這卻是錯誤的工具。一旦我們認知到這點，便不再強求 Mythos Preview 做不適合的工作，而是開始圍繞它建置測試框架。
在大規模執行這項工作的過程中，我們學到了四點教訓，每一條都指向了同一個需求：我們需要一個能管理整體執行的框架：
縮小範圍能產出更優質的發現：告訴模型「在這個程式庫中尋找漏洞」會讓它迷失方向。而告訴它「在這個特定函式中尋找指令插入，注意其上方的信任邊界，這是架構文件，這是先前對這個區域的分析報告」，則能讓它做出更接近研究員實際工作的行為。
對抗性審查降低雜訊：在初步發現與分類佇列之間加入第二個智慧體，該智慧體使用不同的提示、不同的模型，且沒有能力產生自己的發現，這樣做能夠篩除大量雜訊。這些雜訊往往是第一個智慧體僅憑自身力量進行自查時所無法察覺的。事實證明，刻意讓兩個智慧體之間形成「意見分歧」，遠比只告訴一個智慧體「要小心」來得更有效。
將分析鏈拆分給多個智慧體能產生更好的推理：「這段程式碼有漏洞嗎？」與「攻擊者是否真的能從系統外部觸及這個漏洞？」是兩個不同的問題。分開提問時，模型在回答每一個問題時的表現都會更加出色；因為相比於將兩者合併提問，拆分後的每一個問題都擁有更聚焦、更狹窄的範圍。
並行執行多個窄範圍任務優於依賴單一全能型智慧體：當部署多個智慧體分別處理範圍緊湊、聚焦明確的子任務，然後再對結果進行去重複時，分析涵蓋率會提升；這比要求一個智慧體做到詳盡無遺來得更好。
上述每一個觀察結論都關乎模型的行為；而將這些觀察匯聚在一起，所描述的已不再僅僅是一個「聊天互動介面」。這是一個能幫助達成最終目標的框架。建立框架的第一步很簡單，您可以請模型來幫忙，我們正是這麼做的。我們利用 Mythos Preview 來建立、調整並改進我們原有的框架，以充分發揮它的優勢。
以下將描述一個實際運作中的框架範例。
以下是我們的漏洞發現框架，按階段逐一說明。該框架被用來掃描我們在執行環境、邊緣資料路徑、通訊協定堆疊、控制平面以及我們所依賴的開源專案中的即時程式碼。
|
階段
|
有什麼用處
|
重要性
|
偵查
|
一個智慧體從上至下讀取程式庫，將工作分配給負責各子系統的子智慧體，並產出一份架構文件，內容涵蓋建構指令、信任邊界、進入點及可能的攻擊面。同時，它會為下一階段產生初始任務佇列。
|
為所有下游智慧體提供共用的脈絡。解決了模型漫無目標的問題。
|
搜尋
|
每個任務都包含一個攻擊類別和一個範圍提示。「搜尋者」（實際尋找漏洞的智慧體）並行執行，通常同時約有五十個，每個搜尋者再各自分派出數個探索子智慧體。每個搜尋者都能使用工具，可以在每個任務專屬的暫存目錄中編譯並執行概念驗證程式碼。
|
這是大部分工作發生的階段。許多目標明確的任務並行執行，而不是靠一個全面的智慧體。
|
驗證
|
一個獨立的智慧體會重新讀取程式碼，試圖反駁最初的發現。它使用不同的提示詞，且無法自行產出新的發現。
|
能捕捉到相當一部分雜訊，這是搜尋者進行自我審查時無法發現的。
|
填補空白
|
搜尋者會標記它們接觸到但未徹底檢查的區域。這些區域會被重新排入佇列，進行另一次掃描。
|
防止模型一直偏重於它已經找到過漏洞的攻擊類型。
|
去重複
|
將具有相同根本原因的發現合併為單一記錄。
|
變體分析是一項功能，而不是一種用重複項來擴充佇列的方法。
|
追蹤
|
對於共用函式庫中每個已確認的發現，一個「追蹤者」智慧體會進行擴展（為每個使用此函式庫的消費者程式庫建立一個執行個體），利用跨程式庫的符號索引，判斷攻擊者控制的輸入是否真的能從系統外部觸及該漏洞。
|
將「存在缺陷」轉變為「存在可觸及的漏洞」。這是最關鍵的階段。
|
回饋
|
可觸及的追蹤結果，會在實際上暴露了該漏洞的消費者程式庫中，成為新的搜尋任務。
|
形成閉環。整個流程會隨著執行而自我改進。
|
報告
|
一個智慧體會根據預先定義的結構描述撰寫結構化報告，自行修正任何與該描述不符的驗證錯誤，並將報告提交至接收 API。
|
輸出是可查詢的結構化資料，而非自由格式的文字敘述。
|
其他安全領導者對 Mythos Preview 最熱烈的反應，主要圍繞在速度上——掃描更快、修補更快、縮短回應週期。與我們交流過的多個團隊，現在正致力於達成「從 CVE 發佈到生產環境完成修補僅需兩小時」的 SLA。這種直覺是可以理解的：當攻擊者的時間線縮短，防禦者的時間線也必須隨之縮短。然而，僅僅「更快」是不夠的，我們認為，許多團隊即將耗費大量時間、精力和金錢來親自學到這個慘痛的教訓。
更快地修補漏洞，並未改變產生修補程式的整體流程。如果迴歸測試需要一天，那麼不跳過它就不可能達成兩小時的 SLA；而跳過迴歸測試所導致的程式錯誤，其嚴重性往往比試圖修補的原始漏洞更糟。我們也曾嘗試讓模型自行撰寫修補程式，並眼看著幾個修補程式在修正了原始漏洞的同時，卻悄無聲息地破壞了程式碼所依賴的其他功能，我們就學到了類似的教訓。
更困難的問題是，圍繞著漏洞的整體架構應該是什麼樣子。其原則是：即使漏洞存在，也要讓攻擊者更難加以利用，從而降低漏洞揭露後到完成修補之間的時間差所造成的風險。這意味著需要在應用程式前端部署防禦措施，阻止攻擊者觸及漏洞。這也意味著要設計應用程式，使得某部分程式碼的缺陷不會讓攻擊者有機會存取其他部分。這還意味著能夠同時將修補程式部署到程式碼執行的所有位置，而不是等待各個團隊分別部署。
我們也認知到，這個議題具有兩面性。幫助我們在自己程式碼中找出漏洞的相同能力，若落入壞人之手，同樣會加速對網際網路上每個應用程式的攻擊。Cloudflare 位居於數百萬個此類應用程式的前端，而上述的架構原則，正是我們的產品在建構時代表客戶採用的核心理念。未來幾週，我們將詳細介紹這對客戶而言意味著什麼。
如果您的團隊正在進行類似的工作，並希望交流意見，請透過 [email protected] 與我們聯絡。
我們對 Mythos Preview 的研究是在受控環境中針對自身程式碼進行的；所有透過此工作發現的漏洞，均已依照 Cloudflare 正式的漏洞管理流程進行分類、驗證，並在需要時進行了修復。
這項工作是團隊努力的成果。感謝 Albert Pedersen、Craig Strubhart、Dan Jones、Irtefa Fairuz、Martin Schwarzl 和 Rohit Chenna Reddy 對本篇文章背後的研究、工程與分析所做出的貢獻。