OpenAI

2026年10月21日

安全防護產品

Patch the Planet:隨著 AI 代理發現重大漏洞,協調全球應變行動

過去兩個月,我們帶領由維護者、研究人員與資安服務供應商組成的聯盟,處理 PHP 的重大漏洞。PHP 是用於執行網站與網頁應用程式的開源程式語言。Calif 在我們的 Patch the Planet⁠(在新視窗中開啟) 計畫中,使用 GPT‑5.6 Sol 找出了一項重大漏洞;Wiz 也獨立發現並通報了這兩項漏洞。PHP 維護者主導修補與版本發布工作,我們的團隊及 Wiz、Cloudflare 等合作夥伴則提供研究、技術支援與協調,協助在漏洞公開前備妥防護措施。

對使用 PHP 的組織而言,目前最優先的工作就是套用修補程式。我們以 Codex 技能的形式分享 PHP 版本檢查工具⁠(在新視窗中開啟) ,協助維運人員辨識可能存在漏洞的 PHP 版本,並搭配 PHP 與各自服務供應商的指引,判斷應套用哪些更新。

考量這些漏洞的嚴重程度,以及 PHP 的普及程度,我們認為這是近年來影響最深遠的資安問題之一。這凸顯了 AI 能找出影響遍及網際網路的資安漏洞,但同樣的能力也能協助攻擊者快速開發攻擊工具與漏洞利用程式。

據我們所知,前沿 AI 比攻擊者更早發現這些漏洞,為維護者與資安服務供應商開啟了防禦者的應變窗口,讓他們能在漏洞公開前準備修補程式與防護措施。

為協助更多防禦者運用這些能力,我們承諾透過 Daybreak for Frontline Defenders 計畫,提供總額 10 億美元的 Daybreak 使用補助,重點支援資安資源有限、肩負保護必要服務責任的組織。

這些漏洞雖然影響重大,卻只是我們已發現並正著手修復的多項重大漏洞中的一部分。我們預期,未來幾個月類似的發現將大幅增加。根據迄今累積的經驗,我們提出一套適合 AI 時代的方法,用以因應廣泛使用軟體中的重大漏洞,並邀請資安社群協助完善這套框架。這套方法結合我們的模型、資安專業與維護者的力量,協助將研究發現轉化為實際防護,並建立能隨 AI 能力進步而擴展的應變機制。

協調全球應變行動

要讓修補程式實際發揮作用,可能需要將其調整為適用於舊版軟體、由供應商準備緩解措施,並更新眾多組織的系統。隨著更多漏洞被發現,一套可重複採用的流程能協助這些團隊迅速行動。

透過 Patch the Planet,我們提供資安專業與模型使用權限,支援 PHP 的應變工作,並與維護者及研究夥伴合作測試修補程式、準備指引。我們也協助與基礎設施供應商協調受影響系統的防護措施,並聯繫政府資安機關,協助將指引傳達給關鍵組織。這些工作支援了由維護者主導的應變行動,也協助其他防禦者做好準備。

對某些漏洞,研究人員可以直接與軟體維護者合作,調查問題並開發修補程式。另一些漏洞則需要更廣泛的應變行動,因為它們影響許多產品,或是發行商與服務供應商需要時間準備更新及防護措施。如果前沿 AI 的能力並未大幅領先普遍可用的 AI,這段準備時間可能相當有限。在這些情況下,我們提出的框架可協助維護者確定哪些單位需要參與,並協調相關工作。應變行動可分為五個階段:

  • 驗證並修復上游漏洞。維護者、研究人員與必要的技術夥伴確認發現、評估影響,並開發及測試修補程式。這個過程包括使用前沿模型進行對抗性測試,尋找繞過修補程式的方法,以及漏洞的相關變體。

  • 給受影響的組織時間採取行動。我們提出一套框架,用來評估哪些組織需要提前取得資訊以準備防護措施,而由維護者決定邀請哪些單位參與。我們協助聯繫相關單位、處理資訊分享協議,並協調各團隊。發行商可能會調整修補程式,使其適用於舊版軟體;託管服務供應商可能會測試緩解措施;資安服務供應商則可能準備偵測或預防措施,包括網頁應用程式防火牆(WAF)規則。

  • 與政府夥伴協調,協助保護關鍵系統。政府機關在協調更廣泛的應變行動,以及協助將資安指引傳達給負責關鍵基礎設施與其他必要服務的組織方面,扮演不可或缺的角色。以 PHP 為例,我們與合作夥伴共同聯繫美國政府多個單位,包括白宮超級智慧工作小組、國家網路總監辦公室(ONCD)、網路安全暨基礎設施安全局(CISA),以及國際夥伴,以支援這項工作。

  • 為各項受影響產品準備更新。當修補程式、指引與公開計畫逐漸底定,維護者可邀請更多發行商、託管與服務供應商、應變團隊及維運人員參與,準備更新並補足防護缺口。

  • 修補程式一旦可用,就發布指引並支援部署。公開指引有助於使用者評估自身暴露於風險的程度、找到權威來源的更新或暫時性緩解措施,並確認修補程式已生效。在維運人員部署更新並回報需要協助之處的同時,應變工作也會持續進行。

我們提出的框架會考量組織承擔的防護角色,包括保護自身系統與客戶、採取行動所需的時間,以及處理敏感資訊的能力。性質相近的組織將適用相同標準,並由維護者決定在漏洞公開前邀請哪些單位參與。

每個參與者都會取得執行防護工作所需的資訊,從含有入侵指標的網路紀錄,到更敏感、可實際運作的概念驗證漏洞利用程式。即使有限的細節也可能暴露漏洞,因此我們會權衡分享資訊的風險與其能帶來的防護效益。

採用這套框架的團隊將與維護者合作,讓防禦者有時間準備;若出現漏洞已在實際環境中遭到利用、資訊外洩、公開修補程式暴露漏洞細節,或修復停滯導致使用者風險升高等情況,就會重新評估時程。

Patch the Planet 網站⁠(在新視窗中開啟)彙整已公開的漏洞資訊與指引,協助維運人員辨識受影響的系統、找到合適的更新,並驗證更新後的軟體是否正常運作。針對 PHP,網站提供維護者的官方修補程式與升級說明,以及合作夥伴的技術研究連結。指引也涵蓋暫時性緩解措施、何時應請供應商或專家介入,以及備份與復原。暫時性防護措施能降低風險,但我們也會清楚說明其限制,以及維運上必須做出的取捨。

維運人員可參考 CISA 的優先順序與修復指引⁠(在新視窗中開啟),根據暴露程度、漏洞利用情況及潛在影響,評估採取行動的急迫性。這可能意味著緊急修補、立即採取緩解措施,或安排更新;必要時也應進行初步鑑識評估,判斷系統是否已遭入侵。應隨情勢變化重新評估優先順序,並確保有明確途徑達成長期有效的修復。

為維護者提供應變所需的量能與資源

全球協調有賴軟體維護者的投入。許多專案由小型團隊營運,他們必須在日常開發工作之餘審查資安通報。這些團隊需要協助,才能區分新問題與重複通報、評估影響,並在各個支援版本中測試修補程式。我們透過資金、強大模型的使用權限,以及實際的工程協助來支援這些工作。

整個產業的 AI 能力正持續增強,我們預期 AI 在協助防禦者找出漏洞、監控系統與因應威脅方面,將扮演越來越重要的角色。我們正投資模型、工具與合作關係,協助防禦者將這些能力付諸實用。

我們的投資包括透過 Codex for OSS 為所有維護者提供訂閱,以及直接贊助 Rust 基金會⁠(在新視窗中開啟)等專案,支援維護者與技術工作。各專案自行決定優先事項。可重複使用的測試與資安工作流程,能減少日後處理新發現所需的心力。開源專案可向 Patch the Planet 提出申請⁠(在新視窗中開啟),取得實作支援。

我們也正為 Daybreak 校準更多用於攔阻的分類器,以降低遭到濫用的可能性。這涉及艱難的取捨:旨在防止濫用的安全措施,也可能阻擋正當的資安工作。讓更多人能使用強大的模型,以及有效防範濫用,兩者都至關重要。我們的目標是在限制有害用途的同時,保留防禦者尋找及修復漏洞所需的能力。隨著能力進步,以及我們從工具的實際使用情況中累積經驗,我們將持續調整兩者之間的平衡。

打造更安全的軟體基礎

隨著模型能力增強,我們能做的已不僅是找出並修復個別漏洞。我們希望協助工程師從一開始就打造更安全的軟體。改善一個廣泛使用的元件,就能在眾多產品與服務中預防程式錯誤,或限制其影響。

AI 可協助工程師理解現有程式碼、準備修改並開發測試,再由維護者與資安專家驗證,確保這些修改不會改變使用者所依賴的運作方式。我們看見以下幾個領域的機會:

  • 從一開始就編寫安全的程式碼。程式設計模型可協助開發人員選擇更安全的預設設定、正確使用安全性函式庫,並在撰寫程式碼時找出高風險模式。在開發階段預防漏洞,就能減少維護者與使用者日後需要處理的緊急修補。

  • 具備記憶體安全性的軟體。將關鍵元件改用具備記憶體安全性的語言編寫,可以消除常見類別的記憶體錯誤。AI 可協助遷移,再透過測試與專家審查確認運作行為及相容性。

  • 形式驗證。數學證明可用來確認,關鍵元件在明確的假設條件下符合指定的安全性質。將這些方法應用於廣泛使用的元件,有望協助依賴這些元件的服務與關鍵基礎設施排除整類漏洞。

  • 更強的隔離防護。系統也需要防範尚未被發現或修復的漏洞。將處理不受信任檔案、圖片或媒體的軟體放在嚴格受限的沙箱中執行,可在軟體遭入侵時限制損害範圍。AI 可協助工程師測試並強化廣泛使用的沙箱技術,提升眾多應用程式的防護能力。

協助我們完善這套方法

我們分享這套方法,希望維護者、研究人員、應變團隊、供應商與維運人員能協助提升其實用性。我們想了解它在哪些情況下能發揮幫助、在哪些環節可能造成延誤或增加負擔,以及有哪些我們遺漏的事項。過去漏洞公開的實例尤其有參考價值。

我們特別關注以下議題:

  • 公開前的準備期。維護者、維運人員與防禦者需要多少時間,才能準備並部署可靠的修補程式?出現哪些證據時,應提前公開漏洞,尤其是在部分使用者能比其他人更早獲得保護的情況下?

  • 緊急修補。政府或其他維運單位失去系統管理存取權後,是否有適當情況可利用漏洞,修補其擁有或獲授權管理的系統?如果有,是什麼情況?應採取哪些安全保障措施?我們可以想像,最終能對整個網際網路持續掃描已知漏洞,一旦偵測到漏洞,就通知網站擁有者或修補系統。

  • 提前通知。哪些人需要提前收到警示,才能採取有效的防護行動?其中是否包括我們可能遺漏的防禦者?在什麼情況下,分階段通知比一次通知更多對象更有效?我們又該如何權衡涵蓋範圍與資訊外洩風險?

  • 預設即安全的軟體套件。在等待上游修補程式期間,我們能如何協助找出並修復下游套件中的漏洞,或將修補程式回移至已不再接收安全性更新的舊版本?當無法及時升級時,需要哪些測試與維護工作,才能讓這些套件成為可靠的選項?

我們也歡迎推薦獨立資安專家,協助審查這套方法、質疑其假設,並找出缺口。您的意見將協助我們完善應變機制,並決定支援工作的優先順序。請在此分享您的意見⁠(在新視窗中開啟)。

作者

OpenAI