OpenAI 分享 Patch the Planet 協調框架，介紹 PHP 嚴重漏洞應對

Patch the Planet：Agent 揭露重大漏洞，全球協調應對

過去兩個月，我們帶領由維護者、研究人員及網絡安全供應商組成的聯盟，處理 PHP 的嚴重漏洞。PHP 是一種用於執行網站及網絡應用程式的開源程式語言。Calif 在我們的 Patch the Planet⁠（在新視窗中開啟）計劃中，利用 GPT‑5.6 Sol 發現一項嚴重漏洞；Wiz 亦獨立發現並通報了兩項漏洞。PHP 維護者主導修復工作及版本發佈，我們的團隊及 Wiz、Cloudflare 等合作夥伴則提供研究、技術支援及協調工作，以便在漏洞披露前做好防護準備。

對於使用 PHP 的機構，當務之急是套用修復程式。我們以 Codex 技能形式分享 PHP 版本檢查工具⁠（在新視窗中開啟），協助營運人員識別可能存在漏洞的 PHP 版本，並參考 PHP 及相關供應商的指引，判斷適用哪些更新。

鑑於這些漏洞的嚴重程度及 PHP 的廣泛應用，我們認為這是近年來影響最深遠的安全問題之一。這顯示 AI 能夠揭露影響遍及互聯網的安全漏洞，但同樣的能力亦可協助攻擊者迅速開發攻擊工具及漏洞利用程式。

據我們所知，前沿 AI 在攻擊者之前發現了這些漏洞，為維護者及網絡安全供應商爭取到一個防禦者窗口，讓他們能在漏洞披露前準備修復方案及防護措施。

為協助更多防禦者運用這些能力，我們承諾透過 Daybreak 使用權及Daybreak for Frontline Defenders，提供 $1 billion 的補貼，重點支援安全資源有限、負責保障基本服務的機構。

這些漏洞影響重大，但只是我們已發現並正着手修復的多項重大漏洞之一；我們預計未來數月類似的發現會大幅增加。根據目前的經驗，我們分享一套建議方案，探討在 AI 時代如何應對廣泛使用軟件中的嚴重漏洞，並邀請安全社羣協助完善這套框架。這套方案結合我們的模型、安全專業知識及維護者的力量，協助把發現轉化為防護，並建立一套能隨 AI 能力發展而擴展的應對機制。

協調全球應對

要讓修復方案投入使用，可能需要將其調整至適用於舊版本、準備供應商緩解措施，並在眾多機構中更新系統。建立可重複執行的流程，有助相關團隊在發現更多漏洞時迅速採取行動。

透過 Patch the Planet，我們提供安全專業知識及模型使用權，支援 PHP 的應對工作，並與維護者及研究合作夥伴一同測試修復方案和準備指引。我們亦協助協調基礎設施供應商，為受影響系統準備防護措施，並聯絡政府網絡安全機構，協助將指引傳達給重要機構。這些工作支援了由維護者主導的應對行動，也協助其他防禦者做好準備。

就部分發現，研究人員可以直接與軟件維護者合作，調查問題並制定修正方案。其他問題則需要更廣泛的應對，因為它們影響多種產品，或是發行商和服務供應商需要時間（若前沿能力與廣泛可用的能力相差不遠，可供準備更新和防護措施的時間或會十分有限）作好準備。在這些情況下，建議框架可協助維護者確認哪些人士需要參與，並協調相關工作。應對工作可分為五個階段：

確認並修正上游漏洞。維護者、研究人員和必要的技術合作夥伴會確認發現、評估影響，並制定及測試修正方案。這個過程包括使用前沿模型進行對抗性測試，尋找繞過修補程式的方法，以及漏洞的相關變體。
給予受影響機構時間採取行動。我們提出一套框架，用以考慮哪些機構需要預先取得資訊，以便準備防護措施；維護者則決定邀請哪些機構參與。我們會協助聯絡各方、訂立資訊共享協議，以及協調不同團隊。發行商可能會為較舊版本調整修正方案；託管服務供應商可能會測試緩解措施；安全服務供應商則可能會準備偵測或防護措施，包括網頁應用程式防火牆（WAF）規則。
與政府合作夥伴協調，協助保護關鍵系統。政府機構在協調更廣泛的應對工作，以及協助將安全指引傳達給負責關鍵基礎設施和其他必要服務的機構方面，發揮重要作用。就 PHP 而言，我們與合作夥伴協作，聯絡美國政府多個部門，包括 White House’s Super Intelligence Force、Office of the National Cyber Director (ONCD)、Cybersecurity and Infrastructure Security Agency (CISA)，以及國際合作夥伴，以支援這項工作。
為受影響產品準備更新。當修正方案、指引和披露計劃逐漸定案後，維護者便可邀請更多發行商、託管及服務供應商、應變團隊和營運者參與，準備更新並處理覆蓋不足之處。
修補程式推出後，發布指引並支援部署。公開指引有助用戶評估自身受影響程度、尋找具權威性的更新或暫行緩解措施，並確認修正方案正在運作。應對工作會持續進行，直至營運者部署更新，並回報需要協助之處。

建議框架會考慮機構的防護角色，包括保護自身系統及客戶、採取行動所需的時間，以及處理敏感資訊的能力。相同準則亦適用於同類機構，由維護者決定在披露前邀請哪些機構參與。

每位參與者都會取得執行防護工作所需的資訊，內容由包含入侵指標的網絡記錄，到較敏感且可運作的概念驗證漏洞利用程式不等。即使是有限的細節也可能暴露漏洞，因此我們會權衡分享這些資訊的風險與其帶來的防護效益。

遵循此框架的團隊會與維護者合作，給予防禦者時間作好準備；若漏洞正在實際環境中遭受利用、發生資料外洩、公開的修補程式暴露漏洞，或補救工作停滯令用戶面對更大風險，團隊亦會重新評估時間安排。

Patch the Planet 網站⁠（在新視窗中開啟）整合公開披露資料及指引，協助營運者識別受影響的系統、找到合適的更新，並確認更新後的軟件是否正常運作。至於 PHP，網站會連結至維護者提供的官方修補及升級指引，以及我們合作夥伴的技術研究。指引亦涵蓋暫行緩解措施、何時應尋求服務供應商或專家協助，以及備份和復原。暫行防護措施可以降低風險，但我們會清楚説明其限制及運作上的取捨。

營運者可參考 CISA 的優先排序及修復指引⁠（在新視窗中開啟），根據系統暴露程度、漏洞是否遭利用及潛在影響，評估應多快採取行動。這可能包括緊急修補、立即採取緩解措施，或按計劃更新；如有需要，亦可同步進行取證初步評估，判斷系統是否已遭入侵。隨着情況變化，應重新評估優先次序，並制定明確的長效修復方案。

為維護者提供應對所需的能力與資源

全球協作有賴維護軟件的人員。許多項目由小型團隊負責，他們除了日常開發，還要審查安全報告。這些團隊需要協助，才能分辨新問題與重複報告、評估影響，並在受支援的版本上測試修正。我們透過提供資金、使用高能力模型的途徑，以及實際工程支援，支持這些工作。

業界正不斷提升強大 AI 能力，我們預期 AI 在協助防禦者尋找漏洞、監察系統及應對威脅方面將發揮愈來愈重要的作用。我們正投資開發模型、工具及合作夥伴關係，協助防禦者運用這些能力。

我們的投資包括透過 Codex for OSS 向所有維護者提供訂閲服務，以及直接資助 Rust Foundation⁠（在新視窗中開啟）等項目，支持維護者及技術工作。各項目會自行訂定優先事項。可重複使用的測試及安全工作流程，有助減少處理日後發現問題所需的工作量。開源項目可申請參加 Patch the Planet⁠（在新視窗中開啟），以獲得實際支援。

我們亦正為 Daybreak 調校更多攔截分類器，以協助降低遭濫用的可能性。這涉及艱難的取捨：旨在防止濫用的安全措施，也可能阻礙正當的安全工作。廣泛提供高能力模型，以及有效防止濫用的措施，兩者都至關重要。我們的目標是在限制有害用途的同時，保留防禦者尋找及修復漏洞所需的能力。隨着能力提升，以及我們瞭解這些工具的使用情況，我們會繼續調整兩者之間的平衡。

建立更安全的軟件基礎

隨着模型能力提升，機遇不再限於尋找及修復個別漏洞。我們希望協助工程師從一開始便建立更安全的軟件。改進廣泛使用的元件，可以防止錯誤，或限制錯誤對眾多產品及服務造成的影響。

AI 可以協助工程師理解現有程式碼、準備修改及編寫測試；維護者和安全專家則會核實這些修改是否保留用戶所依賴的運作方式。我們在以下數個領域看到機遇：

從一開始就編寫安全程式碼。程式碼模型可以協助開發者選用更安全的預設設定、正確使用安全程式庫，並在編寫程式碼時找出有風險的模式。在開發期間預防漏洞，意味著維護者和用戶需要緊急修正的情況會減少。
記憶體安全軟件。將關鍵組件轉用記憶體安全語言，可以消除常見的記憶體錯誤類型。AI 可以協助進行遷移，並透過測試和專家審查，檢查程式行為及兼容性。
形式化驗證。數學證明可以證明，在指定假設下，關鍵組件符合指定的安全屬性。將這些方法應用於廣泛使用的組件，有助排除依賴這些組件的服務及關鍵基礎設施中某些類型的漏洞。
更強的隔離。系統需要防範尚未被發現或修復的漏洞。在嚴格受限的沙盒中執行會處理不可信檔案、圖片或媒體的軟件，可以在軟件遭入侵時限制損害。AI 可以協助工程師測試和強化廣泛使用的沙盒技術，從而加強許多應用程式的防護。

協助我們改進這個方案

我們公開這個方案，讓維護者、研究人員、應變團隊、服務供應商和營運者協助使其切實可行。我們希望瞭解這個方案在哪些方面有幫助、在哪些方面可能造成延誤或增加負擔，以及我們遺漏了甚麼。過往披露事件的例子尤其有用。

我們特別希望瞭解：

披露時限。維護者、營運者和防禦人員需要多少時間，才能準備和部署可靠的修正？甚麼證據應觸發提早披露，尤其是在部分用戶能比其他用戶更早獲得保護的情況下？
緊急修補。政府或其他營運者在失去管理員存取權後，是否應在任何情況下利用漏洞，修補其擁有或獲授權管理的系統？應採取哪些保障措施？我們可以想像一個最終狀態：在互聯網範圍內持續掃描已知漏洞，並在偵測到漏洞時通知網站擁有人，或直接修補系統。
預先通知。哪些人需要提前收到通知，才能採取有效的防護措施，包括我們可能遺漏的防禦人員？分階段通知何時會比一次過通知更廣泛的羣組有效？我們應如何權衡通知覆蓋範圍與洩漏風險？
**預設安全的軟件套件。**在上游修正尚未推出期間，我們可以如何協助找出並修復下游套件中的漏洞，或將修正回移至已不再獲得安全更新的舊版本？如果無法及時升級，需要進行哪些測試和維護，才能令這些套件成為可靠的選擇？

我們亦歡迎推薦獨立的安全專家，協助審查這個方案、質疑其假設並找出不足之處。您的意見將有助我們完善應對方案和安排支援優先次序。在此分享您的意見⁠（在新視窗開啟）。

作者

OpenAI