超越Fable：本地LLM能否取代雲端AI進行安全代碼審查？

在網絡安全領域，安全代碼審查是最有價值但也最勞動密集的服務之一。大型語言模型（LLM）已成為這一過程中的得力助手：它們能掃描數千行代碼，交叉引用CWE數據庫，並發現即使經驗豐富的審查員也可能遺漏的模式。然而，有一個問題：許多滲透測試接受方不希望將自己的源代碼分享給雲端託管服務，尤其是在金融、政府及關鍵基礎設施領域。將專有代碼發送給第三方LLM會導致保密性和數據駐留風險，僅憑與LLM提供商簽訂的合同保障無法完全緩解。

由此產生的困境是：最好的LLM是雲端託管的，而那些最需要安全審查的公司，往往因為顧慮而放棄使用這些領先能力。那麼，雲端託管模型的領先優勢到底有多大？我們着手回答一個實際問題：本地託管的開放權重模型能否產生與前沿雲端模型相當的安全發現？

我們的答案是：幾乎可以——但需要正確的框架。我們進行了一系列實驗，測試本地LLM的極限，發現它們與基於雲端的模型協同工作效果最佳，同時無需向雲端泄露源代碼：

一個僅有約30億活躍參數的Qwen3.6-35B-A3B模型，完全運行在Mac筆記本電腦上，源代碼不離開機器，在金融科技應用和投票應用上產生的發現集大小與前沿雲端模型（GLM-5、Claude Opus 4.6）相當，並且有一些自己獨有的發現。它不需要任何人工提示，每次代碼庫審查完成時間不到90分鐘。對於核心任務——閲讀代碼、發現漏洞、分類嚴重性、篩選CVE輸出——本地模型現在已與前沿模型處於同一水平。

需要注意的是，發現數量持平並不等同於能力持平。我們的觀點是，本地模型具有足夠的競爭力，可以作為管道的一部分發揮作用，並且其發現被專家認為具有相同的影響力。本研究側重於定量方面，但發現質量已通過滲透測試專家和開發團隊的驗證。

本地模型目前尚不擅長的是設計審查和整合結果。我們發現最有效的管道將這兩項編排任務委託給雲端前沿模型——但在兩個階段中，雲端都不會看到源代碼。我們稱之為“Source-local”：專有源代碼永遠不會離開機器。元數據（文件樹、模式、路由、依賴清單以及生成的步驟提示）會傳遞到雲端，這可能包含內部名稱、目錄結構和架構。準確的承諾是“沒有源代碼離開機器”，而不是“什麼都沒有離開”。

使這一方法起作用的框架由三部分組成：

1. 結構化分解和提示生成——雲端模型將審查分解為聚焦的步驟，並僅從元數據（文件樹、模式、路由——無源代碼）生成步驟提示。
2. 本地工具和LLM輸出——提示在本地執行，運行標準安全工具（如bundler-audit、npm audit、Semgrep、Brakeman），並將其JSON輸出提供給本地模型進行上下文篩選和額外漏洞搜尋。
3. 報告整合——雲端最終步驟將步驟級發現合併為可交付的報告。

第一部分和第三部分不需要向雲端暴露源代碼；第二部分完全在本地運行。由此產生的最佳實踐是：雲端用於提示工程，本地用於執行，雲端用於整合。雲端模型從不查看源代碼——它設計審查；本地模型不需要廣泛的架構推理——它執行針對打包文件的聚焦檢查。

利用Fable 5：基於雲端的編排層是模型無關的。第一和第三階段的編排器不必是無限前沿模型；具有網絡安全護欄的模型也能勝任。Claude Fable 5（2026年6月發佈）帶有精心設計的網絡限制，它設計審查提示並整合發現，沒有拒絕且質量不損失，完全匹配Claude Opus 4.8在這些角色中的表現。這並不令人驚訝：設計和整合防禦性審查是知識和結構工作，而非利用，且編排器從不接觸源代碼。

關鍵要點：

1. 沒有單一模型能發現所有問題。所有模型發現的並集顯著大於任何單個模型的輸出：每個模型發現了不同類別的漏洞：Claude擅長架構推理，GLM-5擅長數據流追蹤和工具集成，Gemma4擅長文件集內的行級代碼模式匹配，Qwen3.6擅長廣覆蓋和激進的嚴重性校準。對從業者的啓示：運行“第二意見”模型確實能擴大覆蓋面，即使使用更小的模型也是如此。
2. 提示工程比模型大小更重要。一個結構良好的流程使每個模型都變得更好。例如，Gemma4——在約38億活躍參數預算下運行——發現了三個更大的前沿模型遺漏的真實發現。它運行成本低但能力具有競爭力，這裏的差異不是原始能力而是提示設計。這需要準備：當跳過框架準備並給Gemma4一個單一提示時，它產生了不完整的結果並丟失了輸出指令。當相同的範圍被分解為六個聚焦的微任務，並附上明確的文件路徑和grep命令時，Gemma產生了可操作的發現，包含具體的行號和代碼證據。兩種情況下都沒有幻覺。這表明本地模型的質量上限比預期高——但達到它需要框架準備來引導搜索。我們發現這種準備工作本身可以自動化：Claude僅從文件樹（無源代碼）生成步驟提示，而Qwen執行這些自動生成的提示比任何雲端模型的單個提示審查發現了更多問題。重要的一點是：當Claude為更小的模型準備提示時，那個更小的模型比Claude負責整個測試時的審查發現更多。
3. 報告質量差異很大。較大和前沿模型的報告質量明顯更好，這再次表明它們在“Source-local”審查中仍有位置，其中本地模型執行實際測試：Claude Opus的報告最即時可用，但需要最多的人工提示（約6次提醒）；GLM-5產生了最全面的可交付成果集，但偶爾的幻覺輸出引用損害了報告質量；Qwen產生了結構良好的逐步報告，具有正確的CWE映射和沒有幻覺證據；Gemma4的輸出需要最多的後處理。
4. 審查編排器可以是任何有能力的模型——甚至受網絡限制的Fable。受網絡限制的前沿模型是一個稱職的編排器：Fable 5產生了完整的提示包和嚴格的整合，沒有拒絕，與Opus 4.8在這些角色中沒有明顯的質量差距。編排器的選擇會改變發現的內容：Fable的針對性提示可靠地恢復了已知的“哨兵”漏洞，但產生了更緊湊的集合，而Opus的更廣泛提示產生了更大且在某些方面更嚴重的集合——包括Fable分支從未提到的關鍵問題（負投票零成本投票、未經認證的選票塞入）——代價是錯過了它未特別針對的哨兵。與執行器一樣，並集優於任一編排器：Fable並不比Opus“更好”——它們最好並行運行。對從業者的啓示：編排應被視為管道中很大程度上模型無關的部分：你可以使用任何你有訪問權限的有能力雲端模型（受限或非受限）。並且為本地模型運行兩個提示設計會擴大覆蓋面，就像使用第二個執行器一樣。混合搭配以獲得最佳結果。

實驗設置：我們使用了兩個生產代碼庫，具有不同的技術棧和威脅檔案：Fintech Dashboard（Next.js / TypeScript / React）和一個投票應用。