Linux Foundation 發起 Akrites 計畫：在 AI 加速漏洞武器化之前搶先修補開源軟體
Linux Foundation / akrites.org · 2026-06-25 | LWN.net 報導 · 2026-06-26
Linux Foundation 於 2026 年 6 月 25 日正式宣布成立 Akrites 漏洞緩解計畫，
聚焦於在漏洞公開揭露之前協調上游修補，防止攻擊者利用 AI 工具在第一時間將已知漏洞逆向武器化。
計畫由 Amazon Web Services、Anthropic、Cisco、Google、IBM、Microsoft & GitHub、NVIDIA、Red Hat 等近二十家企業聯合簽署支持，
同時獲得 CNCF、OpenSSF、OpenJS Foundation 及 PyTorch Foundation 等開源組織加入。
LWN.net 於 2026-06-26 刊出首篇詳細報導，說明其與現有安全機制的定位差異。
背景
開源軟體供應鏈安全危機的根本矛盾在於：漏洞一旦公開，就等同於將「武器設計圖」同步交給攻擊者。
傳統協調揭露（CVD）流程假設修補週期以「天」計，但 AI 輔助的逆向工程已將此壓縮至「分鐘」。
Akrites 開放信函直接指出：「一個廣泛部署套件中未揭露的缺陷，本質上就是一件武器（An undisclosed flaw in a widely deployed package is, in effect, a weapon）。」
現有機制（如 OpenSSF）側重最佳實務、工具鏈與教育訓練，
而 CERT/CC 等協調中心則提供漏洞回報的中繼服務。
兩者都無法系統性地在漏洞公開前確保關鍵基礎設施已完成修補部署，Akrites 正是要填補這個間隙。
核心改動
Akrites 的運作模式以「上游優先、保密協調、部署率為量尺」三原則為核心。
計畫不僅僅是一個漏洞資料庫或通報平台，而是直接與原始維護者合作修補漏洞，
確保修正進入 upstream 之後，再協助關鍵基礎設施營運者在公開揭露前完成部署。
成效指標不是「CVE 發布數量」，而是「修補程式實際安裝率」。
計畫承諾在必要時擔任「最後手段維護者（maintainer of last resort）」，
對於那些核心套件已無人積極維護的情況，Akrites 將介入維持維護責任，
確保漏洞修補不因缺乏維護者而擱置。
這直接回應了 CVE-2024-3094（XZ Utils 後門）事件所暴露的孤兒套件風險。
機密處理模型要求所有參與者在修補就緒之前對漏洞細節保密，
避免部分廠商提前獲悉而其他廠商仍曝險的不對稱窗口。
協調揭露的時機由「部署完整度」決定，而非固定的 90 天倒數，
這與 Project Zero 等現行時間線政策有明顯差異。
影響範圍
簽署方涵蓋雲端、電信、金融與 AI 領域的主要基礎設施提供者，代表著相當龐大的部署覆蓋面。
就開源生態系而言，CNCF 旗下的 Kubernetes、Containerd、Prometheus 等專案，以及 PyTorch、Node.js 相關套件，
都有可能納入 Akrites 的協調範疇。
OpenSSF 的參與意味著現有的 Scorecard
和 SLSA 框架將與 Akrites 互補運作。
從攻擊者角度看，AI 輔助的漏洞挖掘工具（如 LLM 輔助模糊測試）已顯著降低發現 n-day 漏洞利用的門檻。
當 patch diff 公開的瞬間，AI 模型可以在幾分鐘內生成 PoC exploit，
使得傳統「公開後儘速更新」的防禦節奏幾乎無效。
Akrites 嘗試透過「先部署後公開」重建時間優勢，但這同時也對參與組織的保密能力與信任機制提出了嚴格要求。
計畫目前處於啟動初期，尚未揭露具體的技術基礎設施（如漏洞資料庫架構、身分驗證機制或 SLA 要求）。
能否真正建立起可信賴的保密協調管道，將是 Akrites 落地成效的最關鍵變數。
後續觀察重點包括：第一個透過 Akrites 流程修補並揭露的公開 CVE 案例，
以及開放原始碼社群對於「非公開漏洞協調」治理透明度的反應。
受影響版本
Akrites 並非針對特定軟體版本，而是作為跨專案的協調機制。
目前信函未指定初始涵蓋的套件清單；預期優先納入的條件為：
- 被廣泛部署於關鍵基礎設施的套件（如 Linux kernel 元件、OpenSSL、curl、glibc 等）
- 活躍維護者少於 3 人且下載量超過一定門檻的套件
- 已進入 OpenSSF Scorecard 高風險名單的孤兒套件
修補與緩解
對於目前的開源維護者而言，Akrites 開放信函鼓勵各方透過 akrites.org 接觸計畫團隊，
表達參與意願。基礎設施營運者（尤其是金融機構與電信業者）可透過簽署支持聲明，
取得在漏洞公開前獲得修補程式的優先管道資格。
對於軟體供應鏈安全的實務防禦，Akrites 的成立也再次強調了以下既有建議的重要性：
- 持續追蹤 OSV.dev 與 GitHub Advisory Database 的漏洞告警
- 採用 SLSA Build Level 3 以上的供應鏈完整性驗證
- 部署 SBOM（軟體物料清單）以縮短受影響套件的識別時間
- 針對關鍵依賴項設置自動化 patch 部署管線，降低人工介入延遲
原始來源：Akrites Open Letter (Linux Foundation, 2026-06-25) ·
LWN.net 報導 (2026-06-26)