OpenAI 將一場 250 人安全衝刺轉化為持續運作的 AI 防禦工廠
OpenAI 表示，其網絡模型協助修復數百個系統的漏洞，促使公司推出持續運作、以智能體為基礎的防禦計劃。
文章目錄 · 11
OpenAI 表示，公司動員超過 250 名員工，在數百個系統中尋找並修復漏洞，並使用 Codex 及專門的網絡模型支援發現、分流、修復和驗證工作。公司現已公開這場內部安全衝刺所發展出的架構及運作流程，並將所得系統稱為其「Defense Factory」。
這次披露包含罕見地具體的營運成果。OpenAI 表示，團隊在衝刺首日處理了 53 個緊急或高優先級問題；將發現事項轉交負責人時，取得 90.6% 的接納率；將 37% 的發現事項歸類為重複；而在動態驗證後，將誤報率降至 0.81%。
這些數字描述的是一項內部防禦計劃，而非已披露的外部入侵事件。OpenAI 並未指出受影響服務、公開漏洞總數或嚴重性分布，亦未提供每個已報告比率所依據的分母及量度期間。因此，外界無法根據已公開資料獨立重現其結果。這次披露的重要之處，反而在於其運作模式：安全工作正被重組為持續運作的智能體工作流程，而非一連串定期掃描及人工交接。
一、安全衝刺涵蓋逾 100 個服務範疇
OpenAI 將原有工作描述為一次內部「code red」，集合了其 Security、Applied 及 Research 組織。超過 250 人參與，工作涵蓋逾 100 個服務範疇，涉及數百個系統。
這次衝刺開始時，OpenAI 尚未擁有這些系統的完整地圖。Codex 協助建立資產清單，同時團隊將現有安全發現事項匯入共用待辦清單。服務負責權資料、部署設定、雲端紀錄、原始碼及已公開端點逐步連接，讓智能體可判斷每項發現事項應交由哪個團隊處理。
OpenAI 報告指，這個流程取得 90.6% 的責任歸屬接納率。人工審核人員繼續處理模糊個案，而緊急修復工作在資產清單完成前已經展開。這種並行方式讓團隊在首日處理了 53 個緊急或高優先級問題。
智能體亦會依據嚴重性評估準則評估發現事項。OpenAI 表示，早期分類並不一致，且對提供給模型的指示相當敏感。公司因此為提示詞及評估準則建立版本管理，加入可重複進行的評估，記錄審核人員預期的優先次序及理據，並保留人工抽查。
去重亦成為另一個明確關卡。OpenAI 曾暫停自動轉派，直至該流程有所改善，最終判定其檢視的發現事項中有 37% 屬於重複。這點十分重要，因為一個只會產生更多報告的智能體系統，可能增加安全工程師的負擔，卻未必能降低風險。
動態驗證用於區分可重現的漏洞與靜態分析雜訊。智能體會取得指定服務的可執行版本，並嘗試在受控環境內重現疑似問題。OpenAI 表示，經過此階段後的誤報率為 0.81%，但未披露經驗證樣本的規模或組成。
二、Defense Factory 採用五階段智能體迴圈
Defense Factory 並非被描述為單一模型或漏洞掃描器。它是一個參考架構，連接現有原始碼控制系統、安全掃描器、問題追蹤工具、開發環境、公司特定脈絡及 AI 智能體。
其工作流程有五個循環階段：清點、發現、動態驗證、責任歸屬分派及已驗證修復。
清點智能體會核對雲端資源、部署設定、原始碼、已公開端點及服務負責權紀錄。發現智能體其後把該清單與威脅模型、安全政策、原始碼，以及從 Snyk 或 Wiz 等工具匯入的發現事項結合。輸出結果仍是一個候選漏洞池，而非已確認缺陷清單。
在動態驗證期間，智能體會檢視相關程式碼，並嘗試在可執行應用程式中重現每個候選項目。OpenAI 的規格說明指出，單靠靜態追蹤並不足夠：已驗證漏洞必須包括重現證據。被證偽及未有定論的發現事項仍會附於紀錄，而在追蹤系統建立問題則需要批准。
責任歸屬智能體會將已驗證的發現事項，連接至資產清單、程式碼擁有人檔案、提交紀錄、內部通訊及問題追蹤工具。OpenAI 區分了分派與確認接納，避免將自動轉派的工單視作已被接納的工作。
在最後階段，Codex 會準備修補程式，並在可重現環境中檢查其行為。經人工審核及獲授權部署後，另一項檢查會重新測試生產環境中的修復。一個已合併的 pull request 或已移動的工單，並不視為修復證明；驗證失敗或未有定論，會令問題保持開啟。
共用的 SECURITY.md 檔案會在各個週期之間承載系統特定知識。每次運行均可重用對應關係、責任歸屬資料、調查證據及先前驗證檢查，而無須重新建立這些脈絡。公司表示，具重要後果的變更仍會接受人工審核，而已部署的修復會獨立驗證。
三、隔離與存取控制屬於安全邊界的一部分
OpenAI 的架構將控制平面與資料平面分開。控制平面管理工作負載編排、政策執行及憑證存取。資料平面則提供隔離的開發環境，讓智能體可運行應用程式、重現漏洞及測試修補程式。
這些環境旨在做到短暫存在：每次運行均由全新環境開始，其狀態其後會被丟棄。這可降低一項調查污染另一項調查的風險，並使重複驗證更可靠。
該架構亦將原始碼控制、秘密資料儲存、成品登錄庫及模型端點置於組織的私有網絡之內。資產清單及發現事項資料庫會保存工作流程狀態，而主機監控、基礎設施安全及智能體稽核系統會監督整條流程中的活動。
OpenAI 表示，公司逐步提高自主程度。它先以小批次及人工審核開始，然後在結果變得更可靠後，移除重複出現的人工步驟。授予智能體的權限，與其可進行的分析工作量維持分離。
這個區分在修復期間尤其重要。OpenAI 表示，智能體在衝刺中產生了每一個修補程式，並將修復描述為「100% Codex-based」，但人員仍負責具重要後果的審核及獲授權部署。已報告的回退修復率為 0.53%，但公司尚未公開該百分比所代表的原始修補程式數目。
後續檢查亦發現，修復已合併與其覆蓋所有已部署系統之間存在落差。OpenAI 擴展了部署後驗證，但在研究如何區分修復失敗與正常部署延遲期間，最初仍停用了自動重新開啟功能。
四、可轉移的成果是驗證流程，而非人數
OpenAI 的核心主張是，防禦方可在攻擊者取得相若存取權之前，運用私有程式碼、部署脈絡、責任歸屬紀錄及更強的前沿模型。其 Defense Factory 的設計目標，是將這項優勢轉化為發現與已驗證修復之間更短的週期。
Cloudflare 另行描述了一個可比較的多智能體漏洞工具組。其流程採用不同智能體處理偵察、搜尋、對抗式驗證、去重、依賴關係追蹤及修補程式準備。它要求生成的修復在進入生產環境前須經人工批准，並將可重現測試視為關卡，而非相信模型的書面評估。
這個獨立實作支持了相關工作流程模式，同時亦說明其成本。Cloudflare 表示，大型掃描可能需時數小時，需要由 50 至 200 名工作者組成的資源池，並將營運瓶頸由找出缺陷轉移至審核及安全部署修復。持續的智能體活動並不會消除對應用程式擁有人、可靠測試環境、發布工程或安全判斷的需要。
對考慮採用 OpenAI 設計的組織而言，最具體的改變在於程序。候選發現事項必須在交給工程師前完成去重及重現；責任歸屬必須連繫至現行營運紀錄；修補程式必須通過迴歸檢查；而修復必須在部署後驗證。若欠缺這些關卡，加入智能體可能只會加快報告產生，而非減少漏洞。
對底層模型的存取亦並不一致。OpenAI 公開的架構列出包括 Astra、Sol、Terra 及 Luna 的通用模型，以及 Daybreak Blue 和 Daybreak Red 安全模型。較寬鬆的網絡能力會透過 Daybreak 提供予已驗證的防禦方，並配合更嚴格的身分驗證、範圍控制、監控及監督。
因此，已公開資料是一個參考架構及內部個案研究，並非證明任何組織都能立即重現 OpenAI 的結果。OpenAI 提供了效能指標及工作流程細節，但未有提供足夠的漏洞層面資料，以便將其系統與傳統安全計劃比較，或獨立評估偵測覆蓋範圍。
常見問題
OpenAI 是否正回應一宗已確認的外部入侵事件？
不是。OpenAI 將這項工作描述為內部安全衝刺，並未表示 Defense Factory 公告涉及新的外部入侵。
Defense Factory 的作用是甚麼？
它將資產清點、漏洞發現、運行時驗證、責任歸屬轉派、修補程式生成及部署後驗證，連接成持續循環、由智能體協助的工作流程。
AI 智能體有否在未經人工批准下部署修復？
OpenAI 表示，Codex 生成了修補程式，但具重要後果的變更仍須經人工審核及部署授權。生產環境修復其後會獨立重新測試。
OpenAI 找到了多少個漏洞？
OpenAI 尚未公開總數。公司報告稱首日處理了 53 個緊急或高優先級問題，但未披露完整發現事項數目或嚴重性分布。
任何組織都可以使用相同的網絡模型嗎？
不一定。OpenAI 指引獲授權的防禦方透過 Daybreak 申請；在該平台上，對功能更強或更寬鬆的網絡工具之存取，取決於驗證、範圍控制及監督。
參考來源
Share
分享這篇文章
