構建你自己的漏洞檢測框架

幾周前，我們發佈了Project Glasswing的初步發現，探討了將前沿安全模型應用於企業代碼庫時會發生什麼。我們還研究了防禦結構如何適應以保護基礎設施和客户免受前沿AI的威脅。此後，AI生態系統繼續快速變化——圍繞單一模型構建的開發者已經體驗到當該模型不再可用或被更強大的模型取代時的後果。這些市場變化強化了我們的核心論點：無論當前哪個底層模型領先，代理工作流的未來都不會存在於獨立模型、提示或單代理會話中。

從本地化的安全“技能”轉變為持續的全艦隊掃描管道需要一種架構，其中模型被視為可互換的組件。依賴單一模型本質上限定了防禦範圍，因為同一系統傾向於通過完全相同的視角查看代碼路徑。為了應對這一點，應該頻繁交換和交叉測試模型。通過在管道中變化模型——例如使用一個模型進行初始發現，使用完全不同的模型進行驗證——我們可以確保漏洞被不同的邏輯集交叉檢查。此外，真正的企業級框架必須超越孤立的倉庫，跨倉庫依賴關係追蹤漏洞，最終將數千個原始候選過濾為可信的、經過分類的可操作修復隊列。

本文作為構建該模型無關層的實用指南，重點介紹我們如何管理狀態控制、消除誤報以及協調端到端的分類。

首先，我們要解決兩個可能的反對意見。第一個是：“為什麼不使用子代理而不是框架？”子代理很有用，是一個好的起點。但安全分析需要數百個獨立的調查，這些調查需要在運行之間持續存在，不共享上下文窗口，並且可以稍後重新調整範圍和交叉引用。它需要持久性、去重、可恢復性，以及最終的全艦隊依賴追蹤。這是一個編排問題，提示無法解決。第二個是：“這篇博文只是前沿模型的廣告嗎？”不。我們的方法以框架為中心，而不是模型。在漏洞發現方面，我們使用當前最適合我們需求的前沿模型。當我們將不同模型指向同一目標時，它們各自發現不同比例的漏洞。框架是持久的。如果你構建自己的系統，請從一開始就設計成模型無關的。

一切都始於一個技能。我們從約450行的安全審計技能開始，在單個倉庫上運行，並調整提示直到發現真實漏洞。後來，我們添加了編排，成為整個系統的管道。真正價值在於提示本身，我們的提示幾乎未改變地保留了初始技能的威脅場景、漏洞類別和反模式檢測。該技能在一個會話中執行7階段審計：三個並行研究代理進行偵察並寫入architecture.md；一個獵人代理按攻擊類別運行，試圖破壞代碼而不是審查；對抗性驗證器試圖反駁每個發現；倖存者被編寫為人類可讀的漏洞報告；它們也按模式輸出為findings.json，並通過機械檢查驗證文件；最後，一個全新的代理獨立重新驗證每個發現。

該技能直接映射到後來的框架。但它迅速暴露了侷限性：單次運行只發現約一半的漏洞，且偏向於較簡單和較不微妙的漏洞。我們遇到了三大牆壁：上下文耗盡、持久性和跨倉庫推理。我們通過完全外部化狀態、將LLM視為無狀態計算引擎來打破上下文瓶頸。持久性通過每個階段寫入SQLite數據庫來解決，任何階段都可以恢復、重試或納入後續運行。跨倉庫推理通過追蹤依賴關係圖，確保在消費者倉庫中捕獲跨倉庫漏洞。

將該技能編纂為管道：從第一次斜槓命令運行到覆蓋128個獨立倉庫的艦隊掃描器花費了大約六週。編纂主要是機械性的：我們將每個階段提升為自己的代理，後面放一個數據庫，前面放一個編排器。映射幾乎是一對一的。整個艦隊在一個統一的框架上運行，無需針對語言進行調優，並追蹤倉庫間的依賴關係。

漏洞研究工作流基於兩階段操作框架：漏洞發現框架（VDH）和漏洞驗證系統（VVS）。VDH作為發現引擎，主動掃描代碼庫以發現潛在安全問題。漏洞進入VVS後，經歷去重、判斷和修復階段。我們在VDH中使用一個模型，在VVS中使用完全不同的模型，因此模型相互雙重檢查。強制模型B判斷模型A的輸出，確保發現由完全不同的邏輯權重和訓練數據評估，作為無偏見的對抗第三方。

VDH包括偵察、狩獵、驗證、補缺、去重、追蹤、反饋和報告階段。階段四到八作為持續的生產者-消費者循環運行。隨着初始狩獵的進行，補缺、反饋和追蹤代理生成新任務；去重將重疊的發現摺疊在一起；循環繼續消耗隊列。這種拆分確保了嚴格的狀態控制：每個代理的任務超聚焦，將上下文使用保持在總窗口的25%以下。持久性需要在並行化之前考慮：每個階段寫入SQLite數據庫，鍵為(run_id, repo, stage)。任何階段都可以恢復、重試或納入後續運行，而無需重做工作。發現結果實時流式保存，因此崩潰只丟失進行中的任務。