Linux 核心作為現代伺服器運算與雲端基礎設施的基石，其安全漏洞（CVE）直接影響到整個系統的穩定性與安全性。近期，Amazon Web Services（AWS）在 Linux Plumbers Conference 上的分享，揭露其內部團隊如何處理 EC2 基礎設施所使用的 Linux 核心 CVE，過程中結合自動化篩選、AI Agent 與人工審核三個階段，並提出了新的長期支援（LTS）核心升級策略。
AWS 維護的核心並非 Amazon Linux 或客戶在虛擬機器中執行的核心，而是專門為 EC2 基礎設施打造的內部版本。自 2024 年 2 月成為 CVE Numbering Authority 後，每天的 CVE 數量飆增，從升之前的每週約 2 個，到 2026 年 8 月單日即達 848 個。由於核心使用情境各異，官方文件強調使用者需自行判斷 CVE 是否影響其系統。
AWS 的處理流程分為三個階段。第一階段為純自動化篩選：系統會解析 CVE 記錄中的 JSON 格式資料，確認受影響版本範圍與來源檔案是否包含在 AWS 的核心映像中。若版本不符或相關檔案未被編譯，則直接捨棄。據估算，此階段可過濾掉約 70% 的 CVE，但過濾比例與核心配置有關。剩下的 CVE 會交由 AI Agent 進行分析。Agent 接收 AWS 的核心原始碼樹、各平台配置、環境描述與威脅模型，並根據嚴重性標準，產出受影響子系統、漏洞類型與攻擊向量等資訊表格。AWS 團隊特別忽略通用 CVSS 分數，因其不符合實際部署環境，僅將其視為分類工具。
審核方面，兩位工程師會審閱 AI 所產出的結果。AI 處理每個 CVE 僅需約 3.4 秒，遠快於人工判讀，但團隊強調審核步驟仍不可省略，因為不希望將整體安全策略全拖在一個 LLM Agent 上。據估算，AI 判斷結果中有約 5% 至 10% 存在問題，但這僅為非正式估計，未有正式評估方式。此外，AWS 也透過停用不必要的核心功能來降低 CVE 風險，但這項作法被稱為「Deceptively Difficult」，因核心配置選項超過 32,000 項，錯誤移除可能導致數月後出現效能衰退或 Bug。
另一大證據顯示，舊版 LTS 分支修補速度較慢且遺留 CVE 數更多。以 Linux 5.10 為例，中位數從主幹修補到 LTS 發佈需 31.8 天；而 6.18 僅需 18.1 天。2025 年 9 月時，5.10 分支仍有 1,709 個已知 CVE 未修補，相較之下 6.18 僅有 229 個。此外，自行 backport 修補也存在風險，因 CVE 記錄多僅列出最終修正提交，若未追蹤先決提交，可能導致修補後仍有漏洞。AWS 近年加快升級節奏：從 4.19 到 5.10 耗時兩年，5.10 到 6.18 僅需六個月。升級過程中，43% 的問題來自 userspace，因應舊核心行為所做的相容性處理。
AWS 並未公開其工具，但表示願意探索開放來源過濾工具。團隊也承認，由於 AWS 內部使用者需求明確，停用功能相對容易，但這與一般發行版有所不同。與會的微軟 Azure Linux 團隊也分享了類似管道，採用規則表進行 triage，並利用 Agent 協助 backport，透過 build-and-test 回饋機制將成功率從 50% 提升至 80%。而 Google DeepMind 的 CodeMender 則聚焦於撰寫修補程式，並由人工研究人員審核所有提交上游的 patch。
雲端基礎設施運維背後牽涉大量宿主機修補與 Linux CVE 處理，這些工作往往被忽略，但卻是維持系統安全的關鍵環節。AWS 的做法顯示，結合自動化與 AI 輔助，可以有效提升處理效率，但仍需依賴人工審核與謹慎評估，以避免過度依賴機器判斷所帶來的風險。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。