禁令的終結：AI 如何瓦解漏洞披露文化

最近的 "Copy Fail" 漏洞是一個網路安全範式轉移的深刻案例研究。當一名研究人員分享了一個 Linux 網路錯誤的修補程式時，他們遵循了傳統路徑：私下通知安全工程師，同時向公開儲存庫推送一個靜默修復。目標是在修復程式傳播的同時，讓漏洞的性質保持「禁令（embargoed）」狀態。然而，在幾小時內，其他研究人員注意到了該提交（commit），推斷出了安全影響，並公開了該缺陷。

此事件凸顯了兩種長期存在的漏洞披露文化之間日益增長的緊張關係——並表明隨著人工智慧的加速，這兩者都正變得過時。

衝突中的兩種文化

從歷史上看，安全社群一直根據兩種主要的漏洞披露哲學來運作：

協調披露（Coordinated Disclosure）： 最常見的企業做法。研究人員發現漏洞，私下通知廠商，並提供一個窗口期（通常為 90 天）來開發和部署修復程式，然後才公開細節。其前提是該窗口期足以讓廠商採取行動，但又夠短，可以防止研究人員隱瞞發現的內容。
「漏洞就是漏洞」（Bugs are Bugs，即 Linux 方法）： 在 Linux kernel 社群中很常見，這種哲學認為，如果程式碼正在做錯誤的事情，就應該立即修復。其希望是，透過不將修復程式明確標記為「安全修補程式」，使其能融入數千個其他提交的雜訊中，給予管理員更新的時間，而不會驚動攻擊者發現特定的漏洞。

為什麼 AI 會改變方程式

這兩種文化都依賴於一個特定的假設：發現漏洞——或從修補程式中推斷出漏洞——的成本足夠高，足以創造出有意義的時間緩衝期。AI 正在蒸發這種緩衝期。

「靜默修復」的終結

對於「漏洞就是漏洞」的文化，其假設是像 Linux kernel 這樣的大型專案中，信號與雜訊的比率太低，攻擊者很難找到每個與安全相關的提交。AI 改變了這一點。LLM 現在可以即時、廉價且有效地評估通過儲存庫的每一個提交。

正如一位社群成員所指出的，「人們不會注意到」的假設在 AI agent 可以被提示詢問「這看起來像是一個安全修補程式嗎？」並在幾秒鐘內得到正確答案時，便宣告失敗。靜默修復的假象已不復存在；任何併入主線（mainline）的操作現在都是透明的披露。

禁令的崩潰

協調披露的 90 天窗口期也在失效。在 Copy Fail 案例中，第二名研究人員在第一份報告發出僅九小時後，就獨立發現了同一個漏洞。隨著 AI 輔助掃描的普及，漏洞在除了其中一人之外對所有人保持未知狀態長達三個月的可能性正在驟降。

長期的禁令可能會實際上增加風險。它們可能為廠商提供一種虛假的安全感，並限制了能夠參與修復工作的專家數量。當窗口期過長時，第三方獨立發現漏洞的風險——且對方可能缺乏對 90 天禁令的耐心——就成為了一個關鍵的失效點。

超越披露：穩定性的第三種文化

雖然最初的討論集中在披露，但其影響也延伸到了我們如何維護軟體。第三種文化——「穩定版本」文化——也正受到威脅。許多組織優先考慮穩定性，延遲升級以避免破壞性變更（breaking changes）。然而，如果每個非最新版本的版本都可以被 AI 輕易地掃描並利用，那麼「緩慢且穩健」的方法將變得難以維持。

正如一位評論者所說，像 Debian 這樣以穩定性和舊程式碼庫為傲的專案，可能需要徹底改革其哲學。停留在舊版本的成本不再僅僅是技術債；它是一個向自動化攻擊利用的公開邀請。

邁向新的安全態勢

如果漏洞發現與被利用之間的時間正在縮減至零，產業必須將焦點從防止披露轉移到加速修復。

Token 的軍備競賽

我們正在進入一個安全是運算能力的軍備競賽時代。防禦者必須使用 AI 來修補程式碼，速度要比攻擊者使用 AI 來利用漏洞的速度更快。這需要軟體供應鏈的根本性轉變：

自動化修補週期： 從緩慢、手動的驗證流程轉向 AI 驅動的 CI/CD 流水線，使其能在幾小時而非幾個月內將漏洞報告轉為 QA-ready 的修補程式。
縮短禁令期： 朝向極短的披露窗口期發展，這反映了 AI 發現漏洞的實際速度。
依賴項「預熱」（Dependency Warmups）： 從「冷卻」期（等待觀察版本是否穩定）轉向「預熱」期（快速整合更新以保持在攻擊曲線的前端）。

結論

幾十年來，安全社群一直相信隱蔽性（obscurity）——無論是透過 90 天窗口期或靜默提交——可以爭取時間。AI 已經揭示了隱蔽性是一種我們再也負擔不起的奢侈品。唯一的防禦手段就是速度。目標不再是隱藏漏洞，並在 AI 在另一端發現它之前將其堵塞。