軟體現現代開發流程中，軟體供應鏈安全（Software Supply Chain Security）已成為 DevSecOps 的核心議題。當我們在專案中使用 npm 安裝第三方套件時，實際上是將對方的程式碼直接運行在我們的環境中。如果套件維護者的帳號被盜，或 CI/CD 流水線被入侵，攻擊者就能將惡意程式碼植入新版本並發佈，導致全球數以萬計的開發者在執行 npm install 時無意識地下載木馬。為了阻斷這種攻擊路徑，GitHub 近期為 npm 推出了兩項關鍵的安全更新。
分階段發佈機制與 2FA 驗證
傳統的 npm 發佈流程是直接將套件推送到登錄伺服器，一旦指令完成，使用者立即就能安裝新版本。這種模式在自動化部署（CI/CD）中非常方便，但風險在於：如果 CI/CD 的金鑰（Token）洩漏，攻擊者可以無需人工干預就發佈惡意版本。
為了解決這個問題，npm 推出了分階段發佈（Staged Publishing）。這項功能改變了發佈邏輯，將其分為上傳與核准兩個階段。開發者使用 npm stage publish 指令後，套件會先進入一個暫存隊列（Stage Queue），而非直接對外公開。在套件正式生效前，必須由一名具有權限的維護者通過雙因素驗證（2FA, Two-Factor Authentication）進行人工核准。
2FA 是一種要求使用者提供兩種不同類型的驗證憑據（例如密碼加上手機驗證碼）的機制，用來確保操作者的身份真實性。透過強制要求 2FA 核准，npm 實現了所謂的存在證明（Proof of Presence），確保每一次的發佈都有真實的人類維護者確認過，有效防止了自動化腳本被濫用來散播惡意程式碼。
使用分階段發佈的前提條件
並非所有套件都能直接開啟此功能，維護者必須滿足以下三個條件： 第一，帳號必須擁有該套件的發佈權限。 第二，該套件必須已經存在於 npm 登錄伺服器中，因此全新的套件無法直接使用分階段發佈。 第三，帳號必須已啟用 2FA。 此外，開發者需要將 npm CLI 工具更新至 11.15.0 或更新版本才能支援此指令。
為了達到最高安全等級，GitHub 建議將分階段發佈與 OIDC（OpenID Connect）信任發佈結合使用。OIDC 是一種身份認證協議，允許 CI/CD 平台（如 GitHub Actions）在不儲存長期靜態金鑰的情況下，透過短期臨時憑證與 npm 通訊，從根源上減少金鑰洩漏的風險。
精細化的安裝源控制
除了發佈端的保護，npm 同時強化了安裝端的控制。過去開發者可以使用 -allow-git 旗標來安裝非登錄伺服器來源的套件，但這在某些情況下會增加風險。
現在 npm 引入了三個新的安裝源旗標，讓開發者能採取明確的白名單（Allowlist）管理方式： allow-file 用於控制從本地檔案路徑或本地 tarball 壓縮檔安裝的行為。 allow-remote 用於控制從遠端 URL（例如 HTTPS 連結的壓縮檔）安裝的行為。 allow-directory 用於控制從本地目錄安裝的行為。
這項更新的重要性在於，它讓工程師能精確定義專案允許從哪些非官方渠道獲取程式碼，避免因設定過於寬鬆而導致惡意套件被意外引入。
總結與實務影響
這次更新的背景是近期針對開源生態系的供應鏈攻擊劇增，例如 TeamPCP 等駭客組織透過大規模污染熱門套件來獲利。對於 Junior 工程師來說，理解這套機制的關鍵在於：安全不能只依賴於信任，而必須建立在驗證之上。
透過分階段發佈，npm 將發佈權從單純的 Token 持有者轉移到了經過 2FA 驗證的人類維護者手中；而透過安裝源控制，則將安裝權從寬鬆的預設設定轉向精確的白名單管理。這兩者共同構建了一道防線，降低了開發者在享受開源便利時所承擔的風險。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。