背景與問題
開源軟體的安全修補長期依賴一套固定節奏：發現漏洞之後先私下修補，通知受影響的使用者，等修補準備就緒再發布公開安全公告。這套流程背後有一個關鍵假設，只要技術細節還沒公開，攻擊者就難以在修補釋出之前做出可用的利用程式。InfoQ 記者 Renato Losio 報導 Anil Madhavapeddy 的觀察指出，這個假設正在鬆動。Madhavapeddy 是劍橋大學電腦科學教授，也是 OCaml 編譯器的核心維護者，他從自己處理漏洞的經驗出發，說明 AI 代理如何改變整套揭露流程的時間感。
開 PR 之後幾分鐘就被探測
Madhavapeddy 敘述的案例是一個 path-traversal 漏洞，中文常譯為路徑穿越漏洞。這類問題出現在程式處理檔案路徑時沒有正確檢查使用者輸入，攻擊者可以透過刻意設計的字串，讓程式讀取或寫入原本不該碰到的檔案。他形容修補本身並不複雜，按照正常程序，安全流程應該是私下修好、告知受影響使用者，最後才發出公開公告。但這一次，他開出 PR 之後幾分鐘，就在自己對外服務的網站日誌裡看到探測紀錄，而且探測內容帶有完全相同的漏洞特徵。PR 是 pull request 的縮寫，也就是合併請求，是把修改提交給專案審查、準備納入程式碼的機制。換句話說，問題還沒對外公開，已經有人或某個自動化代理在找同一個弱點。
禁運期為何不再有效
傳統安全流程的關鍵機制是 embargo，可理解為揭露封鎖期，在修補完成前把漏洞細節限制在少數人手中。這套做法成立的前提是，取得細節所需要的人力與時間足以形成一道屏障。AI 代理正在拆掉這道屏障。一項研究顯示，在包含 15 個漏洞的基準測試中，GPT-4 代理在拿到 CVE 描述時能成功利用其中 87% 的漏洞，沒有描述時只有 7%。CVE 是 Common Vulnerabilities and Exposures 的縮寫，也就是通用漏洞揭露編號，用來識別與追蹤特定漏洞。這組數字的意義在於，只要有一份簡短的漏洞說明，代理就能大幅提高把線索變成實際利用程式的機率；而這份說明往往不需要完整細節。
Madhavapeddy 用 bugonomics 這個說法描述現在的處境，意思是漏洞經濟的誘因與成本結構已經對開源維護者不利。他指出，只要有一個人去搜尋某個問題類別，就足以提醒另一個人的代理，讓對方取得利用程式。這類線索未必來自正式的漏洞報告，可能只是郵件論壇上的一個提問、孤立分支裡一個看起來奇怪的提交，或任何形式的脈絡外洩。一個人搜尋、另一個人的代理接手，整條鏈不需要原始報告者現身，也不需要任何人真正理解漏洞的原理。
維護者的兩難
Chainguard 負責開發者關係的 Adrian Mouat 認為，這讓開源維護者陷入進退不得的位置。光是開出一個修補用的 PR，就可能把專案與使用者推向風險，因為攻擊者能在更新版本發布之前就建立並開始使用利用程式。使用者被暴露在風險中，卻沒有什麼能立即採取的行動。Mouat 指出，這種壓力可能迫使專案在相關原始碼之前就先發布版本，也就是先給出可用的修補產物，之後才揭露對應的程式碼變更。但這種做法會破壞開源的基本運作方式，因為開源的核心價值正是可檢視、可重製的原始碼，先發布成品再補上程式碼，等於把這個順序倒過來。
因應方向與限制
Madhavapeddy 提出三個方向，希望在完整修補到位之前先降低衝擊。第一是私下的漏洞討論，讓協調在不公開的管道中進行；第二是更快的持續發布，縮短從修好到釋出的時間差；第三是協定層的快速緩解，讓系統能在不更動每一個客戶端的情況下先擋住問題。前兩者大致可以在既有工作流程裡調整，第三個則需要架構層面的改變，才能遠端停用或限制有問題的操作。他建議的機制包括短時效憑證、可撤銷的能力，以及協定層控制。短時效憑證是指有效期限很短、過期即失效的存取憑證；可撤銷能力則是指系統能主動收回某項操作權限；協定層控制指的是在通訊協定本身設計開關，讓脆弱行為可以被限制或關閉。這些設計的特點是不必要求每一個客戶端立刻升級就能生效。
限制在於，這類能力必須事先設計與部署，無法在漏洞爆發當下臨時補上。對於已經廣泛佈署、缺乏集中控制點的系統，要加上撤銷與能力控制並不容易，而這些系統往往正是最需要保護的對象。換言之，三個方向之中最容易執行的是流程調整，最難落實的卻是最能改變結構的那一項。
數量壓力同時上升
揭露節奏改變帶來的不只是時間壓力，還有數量壓力。rclone 專案的創作者與維護者 Nick Craig-Wood 在 Hacker News 的討論串中指出，rclone 前十年大約收到 20 個透過 GitHub 進行的安全披露，但最近一個月就超過 40 個。他表示這占用了大量時間，即使借助 AI 工具進行分診、產生可供審查的修補，負擔依然沉重。分診指的是先判斷哪些通報需要優先處理、哪些可以先擱置。這類數量變化與自動化發現工具普及有關，維護者面對的是一條同時被壓縮又被放大的時間軸。同樣的壓力也出現在其他專案上，QEMU 便縮短了漏洞封鎖期，以因應越來越快、越來越自動化的漏洞發現。
影響與觀察
整個變化可以理解為揭露流程的順序被迫反轉。過去是「先修好、再公開」，因為公開被視為風險的來源；現在公開線索本身就可能觸發自動化研究，於是提早發布修補、甚至先發布可執行版本再補上原始碼，開始被當成選項之一。這對使用者的直接影響是更新視窗變短，對維護者則是協調成本與心理負擔同時上升。真正困難的地方在於，傳統流程把保密當成主要防線，而當線索能被獨立推導、代理能快速嘗試利用時，防線就得從保密轉向可撤銷、可遠端約束的設計。這不是單一專案能獨力完成的事，目前也還沒有通用解法，但從 OCaml、rclone 到 QEMU 的案例可以看出，開源社群已經開始調整長年沿用的揭露慣例。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。