Red Hat NPM 事件：供應鏈安全的教訓

最近與 Red Hat 雲端服務相關的多個 NPM 套件遭到入侵，這在開發者社群中引起了不小的波瀾。這次事件是一個嚴峻的提醒：即使是成熟的企業級組織也無法免於供應鏈攻擊。當一個受信任發佈者的管道遭到入侵時，現代軟體開發的信任模型——即我們自動拉取數千個依賴項的模型——將面臨根本性的挑戰。

事件經過：信任的破裂

根據包括 SafeDep 詳細分析在內的報告，大約有 32 個共享相同發佈管道的套件受到了影響。這次入侵讓攻擊者能夠將惡意代碼注入到開發者和組織所依賴的 Red Hat 服務套件中。

雖然入侵的確切途徑仍處於調查中，但社群推測有幾種可能性，從透過 IDE 擴充功能（例如 NX VS Code extension）入侵開發者的筆記型電腦，到 CI/CD 管道安全失效。無論進入點為何，結果都是一樣的：惡意代碼透過受信任的官方管道進行了分發。

NPM 的系統性漏洞

圍繞此事件的討論大多集中在 JavaScript 生態系統的內在風險上。一個主要的爭議點是 postinstall 腳本的使用。這些腳本允許套件在安裝後立即執行任意代碼，為惡意軟體提供了一個完美的傳遞機制。

"一個我從未理解過的事情是，為什麼 NPM 允許套件在安裝後立即執行代碼。那樣做有什麼用途？一個套件應該只是你可以在執行時呼叫的某些代碼。"

這種「功能」實際上將每個 npm install 命令變成了潛在的遠端代碼執行（RCE）事件。當結合缺乏限制性的作業系統權限模型時，這些腳本可以掃描家目錄、竊取環境變數並外洩 Token——通常是以執行該命令的使用者所擁有的完整權限進行。

實用的緩解策略

儘管存在系統性風險，開發者和安全團隊仍可以實施幾層防禦來保護其環境。

1. 依賴項冷卻期 (Dependency Cooldowns)

討論中最有效且低摩擦的策略之一是實施「冷卻期」。這涉及在允許新套件版本進入生產環境之前，將其安裝延遲一段設定的時間（通常為 1-3 天）。由於大多數惡意版本會在幾小時內被檢測到並從註冊表（registry）中移除，短暫的延遲可以防止最災難性的影響。

• pnpm: 現在預設包含 1 天的冷卻期。
• Yarn 4: 提供選項來防止安裝在近期發佈的套件。
• 第三方工具: 像是 depsguard 和 cooldowns.dev 等工具提供了 CLI 包裝器，可以在各種套件管理器中強制執行這些延遲。

2. 沙盒化與隔離 (Sandboxing and Isolation)

為了限制入侵的「爆炸半徑」，開發者應避免在主機作業系統上執行安裝命令。

• Dev Containers: 使用 VS Code Dev Containers 或類似的沙盒環境，可以確保如果套件遭到入侵，攻擊者的存取權限會被限制在容器內，而非使用者的整個家目錄。
• CI 中的權限分離: 在 GitHub Actions 中，將構建/測試階段（執行 npm install）與發佈/簽署階段分開。這可以確保在安裝期間執行的代碼無法輕易地存取用於發佈的機密資訊（secrets）。

3. 加固發佈管道 (Hardening the Publishing Pipeline)

對於套件維護者而言，重點從消費端轉向了分發端。社群正敦促採用更強大的發佈保護措施：

• 發佈時使用 MFA: 要求每次發佈時都進行多因素驗證。
• 受信任的發佈者 (Trusted Publishers): 使用基於 OIDC 的發佈方式（例如 GitHub Actions）來消除對靜態、長期有效憑證的需求。
• 分階段發佈 (Staged Publishing): 一個較新的功能，允許維護者在套件從 CI 推送之後、但在註冊表正式上線之前，透過 MFA 批准發佈。

結論

Red Hat 事件是更龐大且更脆弱系統的一個徵兆。雖然像 Project Lightwell（由 Red Hat 和 IBM 宣布用於檢測供應鏈漏洞的工具）這樣的工具代表了向前邁進的一步，但根本問題仍然在於我們對第三方代碼的信任。透過結合冷卻期、沙盒化和嚴格的發佈要求，一起邁向更具韌性的軟體供應鏈。