對於許多 Junior 工程師來說，我們習慣的發佈流程通常很簡單：在 CI (持續整合) 管道中設定好 Token，一旦測試通過並合併到主分支，系統會自動執行 npm publish，套件隨即對全球使用者開放。
然而，這種「完全自動化」的流程隱藏著巨大的安全風險。如果 CI 環境被駭客劫持（CI Takeover），攻擊者可以輕易地發佈包含惡意代碼的更新版本，而維護者在發現之前，成千上萬的專案可能已經透過自動更新下載了這些毒藥。
為了對抗這種供應鏈攻擊（Supply Chain Attack），npm 最近正式推出了 Staged Publishing（分階段發佈） 功能。
什麼是 Staged Publishing？
簡單來說，Staged Publishing 將原本「一次到位」的發佈動作拆解為兩個獨立的階段：「上傳至暫存區 (Stage)」 與 「正式發佈 (Release)」。
在傳統流程中，npm publish 會直接將套件推送到 Registry 並立即讓所有人可安裝。而在 Staged Publishing 流程中，套件會先被上傳到一個「暫存隊列 (Stage Queue)」。這個狀態下的套件雖然已上傳，但尚未對外部使用者公開，因此無法被 npm install 安裝。
要讓暫存中的版本正式上線，必須由一名具有權限的人類維護者執行「核准 (Approve)」動作，且該動作強制要求通過 2FA (雙因素認證)。
核心技術流程與操作指令
要使用此功能，環境必須滿足以下最低版本要求： npm CLI: 11.15.0 或更高版本 Node.js: 22.14.0 或更高版本 前提條件: 該套件必須已經存在於 npm registry 中（不適用於首次發佈新套件）。
實作工作流 (Workflow)
維護者可以使用以下一組子指令來管理發佈週期：
提交至暫存區： npm stage publish 將預先構建好的 tarball 上傳到暫存隊列。此步驟不需要 2FA，因此可以完美整合進非互動式的 CI 管道中。
查看暫存清單： npm stage list 列出目前所有等待核准的暫存版本。
檢查暫存內容： npm stage view <stage-id> 在正式核准前，檢查該暫存版本中的具體內容。
核准並發佈： npm stage approve <stage-id> 將套件從暫存區推送到正式 Registry。此步驟會觸發 2FA 挑戰，確保操作者是真實的人類維護者而非自動化腳本。
拒絕發佈： npm stage reject <stage-id> 捨棄該暫存版本。
此外，該功能支援 --tag (標籤) 與 --provenance (來源證明) 等參數，其行為與原有的 npm publish 一致。
為什麼這對安全至關重要？
解決 CI 劫持問題 在現代開發流程中，我們傾向於使用 OIDC (OpenID Connect) 實現「信任發佈 (Trusted Publishing)」，避免在 CI 中儲存長效的 Token。GitHub 建議將 OIDC 配置限制為「僅限暫存 (Stage only)」。
這樣做意味著：即使駭客完全控制了你的 GitHub Actions 執行環境，他們最多只能將惡意版本推送到「暫存區」。由於他們無法通過維護者的 2FA 認證，這些惡意代碼永遠無法正式發佈給使用者。這有效地封鎖了整個類別的 CI 劫持攻擊路徑。
應對供應鏈事件 npm 推出此功能背景是近期頻發的供應鏈安全事件（如 Shai-Hulud 蠕蟲攻擊）。安全研究員 Adnan Khan 強烈建議所有發佈者立即啟用此功能，將「自動化上傳」與「人工核准」分離。
限制、爭議與工程判斷
儘管 Staged Publishing 提供了強大的防禦，但在工程社群中仍有不同看法：
「止痛藥」而非「治療藥」：部分開發者認為這僅僅是個補丁（Band-aid），並不能從根本上解決基礎設施的安全問題，而是一種「降低傳播率」的手段。 維護成本：這增加了一個人工操作步驟。如果維護者為了方便而忽視審核流程，或者單純將其視為形式，該功能的防禦效果將大打折扣。 生態系同步：目前 pnpm (11.3+) 與 Yarn 也已提供類似的 stage 指令以保持兼容。pnpm 甚至採取了更激進的防禦措施：預設延遲安裝極新版本的套件。
實務建議：工程師該如何採取行動？
如果你負責維護一個被大量依賴的開源套件或公司內部私有套件，建議採取以下做法：
升級工具鏈：將 CI 環境的 Node.js 與 npm CLI 升級至上述要求版本。 調整 CI 配置：將 npm publish 指令替換為 npm stage publish。 配置 OIDC 權限：若使用 GitHub Actions，請將 Trusted Publishing 的權限限制為 stage 權限，禁止直接 publish。 建立核准制度：定義誰負責執行 npm stage approve，並確保 2FA 裝置的安全。
總結
Staged Publishing 的本質是在「開發效率 (自動化)」與「安全性 (人工審核)」之間取得平衡。它承認了 CI 環境可能被攻破的現實，因此將最後一道防線交還給人類維護者。對於追求高安全等級的專案而言，這不再是一個選項，而是一個必須採取的標準實作。