當我們在討論軟體安全時，許多工程師習慣於處理單一的漏洞，例如修正一個導致遠端程式碼執行（RCE, Remote Code Execution）的錯誤行數。但現在我們面臨的是一個完全不同的維度：AI 正在改變攻擊者的遊戲規則。
目前的威脅不再是單一的漏洞，而是 AI 能將數十個原本看似無害、甚至是被 SAST（靜態應用程式安全測試，一種透過分析程式碼而不執行的掃描工具）標記為低風險的微小問題，像拼圖一樣精準地串聯在一起，形成一個極其複雜且致命的攻擊鏈。這種能力就像是圍棋中的 Move 37，是一種跳脫傳統邏輯的創造性攻擊。
開源供應鏈的結構性崩潰
對於 Junior 工程師來說，最需要意識到的是：我們目前依賴開源軟體的方式（Consumption Model）在根本上已經失效了。現代應用程式是由層層疊加的依賴項目（Dependencies）構成的，這意味著底層的一個小漏洞可能會像骨牌一樣影響整個技術棧。
目前的開源生態系統存在三個核心痛點：
第一，維護者的負荷過重。許多支撐全球網路運行的關鍵軟體，僅由一兩名志願者在業餘時間維護。他們每天被 AI 產生的低品質漏洞報告淹沒，且沒有任何合約或 SLA（服務水準協議）保證漏洞會被修復。
第二，修補速度跟不上發現速度。傳統的協調漏洞披露（Coordinated Vulnerability Disclosure）機制，是建立在漏洞發現需要數週專家分析的假設上。但現在 AI 可以在一夜之間發現數百個漏洞，現有的通報與修復流程完全無法負荷這種量級。
第三，修補過程本身具有風險。在壓力下匆忙更新補丁，若缺乏嚴謹審查，可能會不小心安裝了偽裝成修補程式的惡意軟體，導致情況比原漏洞更糟糕。
面對危機的兩套方案
既然傳統模式失效，我們需要一套 Plan A 與 Plan B 並行的策略。
Plan A 是建立大規模且可信的協調披露機制。我們需要一個統一且受信任的第三方組織，負責對漏洞報告進行審核，並將經過驗證的補丁直接推送給維護者。這樣可以避免維護者被大量雜訊干擾，確保真正關鍵的修補程式能被優先處理。但即便如此，這最多可能只能解決 50% 的專案。
Plan B 則是針對那另外 50% 無法修復的專案，建立最後的維護者（Maintainer of Last Resort）機制。在開源世界中，我們有 Fork（分支）的權利，即複製一份程式碼並獨立維護。當原作者失聯或無法修復漏洞時，需要一個中立且受信任的中心化機構來接手這些關鍵專案的 Fork 版本，並提供安全更新，讓使用者不必在碎片化的各個分支中掙扎。
三條可能的發展路徑
未來我們可能會走上這三條路之一：
天真的路徑：假設所有維護者都能在 24 小時內修復漏洞，所有公司都能在補丁發布當天完成更新且不產生回歸錯誤（Regression）。這在現實中是不可能的。
混亂的路徑：每個雲端供應商或安全廠商都各自 Fork 一套關鍵函式庫並自行修補。結果就是開發者必須面對多個不同版本的同一套工具，且無法確定哪個版本修復了哪些 CVE（常見漏洞披露），這將導致極大的維運災難。
艱難的分支（The Hard Fork）：這是一個痛苦但必要的決定。我們必須建立全新的信任基礎設施，包括統一的披露管道以及一個受信任的中心化 Fork 維護體系。
這將是軟體工程史上最艱難的一次 Hard Fork，因為我們不是在 Fork 一個專案，而是在構建一套能維護數千個專案的工業化基礎設施。諷刺的是，造成這場危機的 AI 能力，也正是讓我們能夠在短時間內實現大規模維護的唯一工具。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。