現代依賴管理之脆弱性：來自 npm 生態系統的教訓

A 最近一篇諷刺文章，強調了 npm registry 中一場毀滅性的（假設性）供應鏈攻擊，引發了關於現代套件管理系統性漏洞的更廣泛討論。這項批評的核心在於 JavaScript 生態系統特有的「依賴地獄」：在這個世界裡，一個簡單的字串操作可能依賴於一個由匿名陌生人維護、深度達 40 層且未經審查的套件樹。

雖然這篇諷刺文章針對的是 npm，但其背後的現實對於任何依賴第三方 registry 的開發者來說，都是一個嚴重的安全疑慮。一個長期被遺棄的工具套件可以輕易地被劫持，進而將惡意代碼注入到數百萬個生產環境的構建中，這並非「天災」，而是我們管理軟體供應鏈方式所導致的後果。

問題的根源：信任與自動化

npm 生態系統的脆弱性通常歸因於幾個結構性缺陷：

• 過度的依賴深度： 使用小型、單一用途套件的傾向導致了龐大的依賴樹，使攻擊面呈指數級增長。
• 任意執行： 套件預設可以執行 postinstall 腳本的能力，使得惡意代碼在套件安裝的瞬間，就能在開發者的機器或 CI/CD 伺服器上執行。
• 「更新文化」： 一種總是使用套件最新版本的文化驅動力，且通常在沒有審查變更日誌（changelogs）或驗證新版本完整性的情況下進行。

雖然有人認為這僅限於 npm，但其他人指出 PyPI (Python) 和 RubyGems 也面臨過類似的危機。最近的 XZ Utils 後門嘗試進一步證明，即使是 Linux 生態系統中的底層系統工具也無法免於複雜的供應鏈攻擊。

實用的緩解措施與防護機制

社群討論提出了幾種技術與流程導向的策略，以減輕這些風險：

1. 實施「冷卻期」

最有效的即時防禦之一是使用「冷卻期」——忽略任何在過去 N 天內（例如 1 到 7 天）發布的套件版本。由於大多數惡意套件會在數小時內被偵測並移除，因此短暫的延遲可以防止大多數自動化的供應鏈攻擊。

"Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days..."

像 pnpm 這樣的工具已經開始納入這些預設設定，而其他工具如 depsguard 和 cooldowns.dev 則旨在將此功能帶入更廣泛的套件管理器。

2. 沙箱化與隔離

降低套件管理器的權限可以防止受損套件竊取環境變數或 AWS keys。使用像 Nix 這樣的工具，它採用沙箱機制來管理依賴，可以提供標準 npm install 所不帶有的保護層。

3. 廠商化與固定版本

對於高安全性要求的企業環境，「廠商化」（vendorizing）——將依賴直接檢查入版本控制系統（透過 git submodules 或類似方法）——可以消除在構建時對即時 registry 的依賴。這讓團隊能夠對代碼進行審查，並確保其不會發生非預期的變動。

4. 減少依賴足跡

目前有一股趨勢正朝向利用原生 Web APIs 和強大的標準函式庫（如在 Go 和 Rust 中所見）來減少對第三方工具套件的套件需求。透過掌握更多代碼並減少對陌生人「週末專案」的依賴，應用程式的整體風險概況會顯著降低。

文化差異

除了技術修復之外，對於不同生態系統的「文化」也存在爭議。有人認為 JavaScript 社群對微型套件（micro-packages）的依賴是更廣泛的專業知識缺乏或急於進行快速原型開發的徵兆。相比之下，Rust 等生態系統通常被認為在依賴管理與安全方面有更嚴謹的做法。

然而，最終的挑戰仍然在於：如何在快速開發的需求與供應鏈安全的必要性之間取得平衡。在套件管理器不再預設執行任意腳本，並實施更嚴格的加密驗證之前，業界將會持續處於下一次不可避免的入侵事件發生後的「祈禱與哀悼」循環中。