在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和威脅情報源是為一個更緩慢、更靜態的世界設計的。是時候退一步，思考漏洞和漏洞利用之外的更廣泛影響，包括我們用於管理它們的流程以及對我們環境的影響。