在AI和CI/CD時代重新思考漏洞管理

在AI和CI/CD時代重新思考漏洞管理

隨着AI輔助編程（即“氛圍編碼”）的興起，開發者不再逐行編寫代碼，而是指導AI代理構建軟件，這一趨勢已深刻改變了安全領域。即使是資深開發者，也因為速度和效率的提升而轉向這種模式，產出可增加十倍。其影響遠不止代碼編寫方式，更延伸至漏洞發現、跟蹤和修復的整個流程。下游過程必須隨之適應。

考慮一個場景：開發者向AI報告一個發現的漏洞。AI很可能掃描代碼庫，查找類似漏洞，並詢問是否一併修復。隨後，代碼庫會接受全面審查以消除該類漏洞。另一種可能是，代碼從製品重新生成，從而可能減少其他現有漏洞。模型或訓練數據可能已學到改進的軟件架構模式，例如零信任對齊和API安全增強。由於代碼正在重構，你旨在修復的漏洞可能連同之前未知的一整套漏洞一同解決。

這改變了我們應向CVE系統提出的問題。CVE長期以來一直是跟蹤和共享已發現漏洞的主要方法。與版本綁定的CVE有助於識別哪些漏洞不再適用。然而，CI/CD管道持續推送應用，其運作方式不同於傳統供應商提供更新由客户內部部署的模式。多年來，雲原生架構已採用不同模型在不影響客户的情況下補丁和修復漏洞。此外，決定哪些CVE應優先處理一直存在挑戰。

當整個代碼庫用更安全的語言和更新的架構模式重寫時，會發生什麼？現有漏洞可能被消除，也可能被新漏洞替代——理想情況下數量少得多。隨着時間的推移，隨着更老舊、更易受攻擊的軟件被現代語言、改進架構和AI驅動的軟件保證所淘汰，跟蹤漏洞的需求應會減少。

這提出了一個重要問題：如果一個漏洞在通過CI/CD管道管理的平台內被發現並修復，且你確認它已修復，那麼該CVE是否還應存在？CVE目錄的目的是協調跨供應商和運營商的認知與修復，他們可能仍處於暴露狀態。如果修復是確認的、自動的、可驗證的，且沒有受影響版本仍在運行，活躍的CVE還有何作用？將其作為歷史記錄保留對回顧分析有價值，但作為威脅情報中的實時信號，它變成了噪音。我們應開始考慮在高度動態環境中跟蹤漏洞的更好機制，其中新代碼和補丁可快速生成，工作負載可通過雲原生平台和CI/CD管道的彈性遷移到更新軟件。

這種變化速度不僅挑戰我們通過CVE跟蹤漏洞的方式，還重塑了使用CVSS評分漏洞嚴重性的方法。CVSS可能需要更充分地考慮運行環境。代碼在孤立環境中可能脆弱，但考慮環境控制後脆弱性如何？並非所有工作負載都在可信執行環境或安全圍籬中運行，但有些確實如此。此外，系統可驗證運行代碼的變化，快速檢測已知漏洞的利用，從而減少或阻止危害。忽略這些因素的靜態基礎評分越來越無法提供有價值的信息。

儘管許多報告暗示漏洞可能消失，但我們尚未達到那個階段。即使代碼廣泛用防止內存安全漏洞的語言編寫，風險依然存在。這些包括內部威脅植入惡意代碼，以及需要軟件或固件緩解的硬件漏洞（如Spectre和Meltdown）。AI可快速重寫軟件以繞過硬件缺陷，正如Spectre和Meltdown所展示的，它們利用硬件的推測執行。在這些情況下，硬件仍是限制因素。但在軟件方面，在短時間內將整個代碼庫遷移到提高內存安全的語言變得越來越可行。遺留代碼正在迅速消失，這一趨勢可能在未來幾年持續。

不要被動接受這些結果。應積極參與塑造伴隨軟件快速演進而來的流程變化。CVE、CVSS和威脅情報源是為一個更緩慢、更靜態的世界設計的。是時候退一步，思考漏洞和漏洞利用之外的更廣泛影響，包括我們用於管理它們的流程以及對我們環境的影響。