解決 CVE 分流危機：為何確定性套件管理至關重要
解決 CVE 分流危機：為何確定性套件管理至關重要
網路安全領域正在發生轉變。隨著 Claude Mythos 等 AI 模型和 Google's Big Sleep 等工具的出現，CVE (Common Vulnerabilities and Exposures) 的發現速度正在加快。我們不再只是發現新漏洞；我們正在揭露那些在多個版本中持續存在數十年的漏洞，與此同時，AI 驅動的攻擊者正以空前的速度擴大其攻擊規模。
對於大多數組織而言，瓶頸不僅在於發現漏洞——而在於分流 (triage)。當一個新的套件 CVE 被披露時，立即的問題是：「我們在哪裡暴露了風險？」在傳統環境中，回答這個問題需要掃描每一個單一的構件 (artifact)、映像檔 (image) 和主機。隨著部署數量的增加，這會產生一個線性擴展問題，很快就會變得難以管理。
擴展問題：O(n) vs. O(u)
在傳統套件管理（使用 apt、dnf 或 npm 等工具）中，CVE 分流的過程通常是 O(n)，其中 n 是部署的數量。因為這些管理器是不可預測的 (non-deterministic)——這意味著相同的安裝指令可能會根據使用的鏡像站、快取狀態或執行時間而產生不同的結果——因此，在不掃描兩者的情況下，沒有可靠的方法可以證明兩個環境是相同的。
這導致了冗餘且耗費資源的工作流程：
- 獨立掃描每個環境。
- 在每個環境中識別脆弱套件。
- 手動驗證每個實例的修補程式。
透過確定性轉向 O(u)
確定性套件管理，特別是透過 Nix 和 Flox，改變了分析的單位。與其分析環境，不如分析閉包 (closure)——即用於產生環境的完整、遞歸套件與構建輸入集合。
因為 Nix 使用輸入定址的閉包，如果兩個環境解析到相同的 Nix store path，它們在密碼學上保證是相同的。這將分流轉銷為一個去重問題。如果你有 500 個環境 (n)，它們可以縮減為 50 個唯一的依賴集 (u)，那麼昂貴的分析只需執行 50 次。
工作流程從掃描轉向查詢：
- 映射每個環境到其依賴集（閉包）。
- 分組具有相同依賴集的環境。
- 分析每個唯一的依賴集一次。
- 重複使用整個群組的結果。
為何傳統的 Lockfiles 不夠用
許多開發者依賴 lockfiles（例如 package-lock.json 或 Cargo.lock）來防止版本漂移。雖然這些在特定生態系統中很有用，但它們並不是完整執行環境的宣告式描述。
一個 lockfile 通常不會捕捉基礎映像檔、原生函式庫、系統證書或環境變數。漏洞往往隱藏在這些遞歸依賴中——即那些沒有人刻意安裝但被套件或系統函式庫引入的東西。這就是為什麼供應鏈攻擊經常針對這些「不可見」層。
Nix 透過將一切視為具有宣告式輸入的構建配方，並將其持久化到不可變的 store paths 中來解決此問題。這會建立一個可查詢、可驗證的依賴圖，涵蓋整個堆疊，而不僅僅是應用程式層級的函式庫。
通往快速修復的途徑
當在確定性系統中識別出漏洞時，修復變得像是在進行資料庫查詢，而不是在進行搜救工作。
- 識別： 查詢哪些 lockfiles 或閉包包含受影響的套件。
- 映射： 識別所有引用這些特定閉包的環境。
- 更新： 編輯環境定義（例如，一個 Flox manifest）以選擇修補後的版本。
- 提升： 將新的環境引用（例如，一個 GitHub commit 或 FloxHub generation）推送到所有受影響的環境。
因為構建是隔離的 (hermetic) 且可重現的，在本地驗證過的修補程式保證能在生產環境中運作。這消除了經常困擾緊急安全修補的「在我的機器上可以運作」的不確定性。
權衡：隔離性 vs. 便利性
如果確定性管理對於安全性的提升如此顯著，為什麼它還不是產業標準？答案在於價值觀的基本差異。傳統套件管理器優先考慮便利性和快速構建時間。Nix 試圖優先考慮隔離性 (hermeticism)——將構建與主機的環境狀態完全隔離。
隔離性是有成本的。它需要更多的磁碟空間，並且可能導致較長的初始構建時間。然而，在儲存空間廉價且頻寬寬大的時代，磁碟空間的成本相對於災難性的安全漏洞或在冗餘的 O(n) 掃描上浪費的工程師小時數而言，微不足道。
AI 飛輪效應：一把雙面刃
人們有一種傾向，認為 AI 編碼代理 (coding agents) 會透過簡單地自動化掃描過程來解決 O(n) 問題。然而，依賴代理來 grep 遍歷數百個節點是一種對安全性的「差不多就行」的方法，這會引入其新的風險。
更令人擔憂的是 AI 的「病態飛輪」：當防禦者使用代理來修補漏洞，攻擊者則使用代理來尋找零日漏洞並設計可擴展的攻擊手段。在 CVE 發現與其被積極利用之間的窗口期正在縮短至趨近於零。在這種環境下，能力在全域基礎設施中即時識別並輪換所有受影響套件的脆弱實例，不再是一種奢侈，而是一種需求。