npm 開放「一個套件多組信任發布設定」：一包套件終於能從多條流水線安全上架【2026 實查】

GitHub 在 2026-09-03 公告 npm 的一項發布安全變更：一個套件可以設定多組「信任發布」（trusted publishing）設定，不再限制一組。 這對維護開源套件的人是實質鬆綁，對用套件的人則是供應鏈安全的小小加分。

一、先用白話解釋 trusted publishing 是什麼

以前把套件推上 npm，最常見的做法是產生一組 npm token，塞進 CI 的環境變數裡。問題很直白：那串 token 就是一把萬能鑰匙，外洩＝別人可以用你的名義發布套件。近年幾次知名的套件投毒事件，起點就是 token 被偷。

Trusted publishing 換了一種思路：不再存長期密碼，改成讓 CI 在發布當下出示一張「短效身分證」（OIDC token）。npm 事先記好「我只接受來自這個 repo、這條 workflow、這個 environment 的身分證」，對得上才准發布。沒有長期 token，也就沒有 token 可以被偷。

二、這次改了什麼

改動一：一個套件可以有多組設定。

過去是一個套件配一組 OIDC 設定，每組各自帶自己的 repository、workflow 與 environment 條件。官方原話是：「只要進來的 OIDC token 對上其中任何一組設定，該次 publish 或 stage 就會被授權。」維護者可以在套件設定裡自行新增、列出、移除這些設定。

聽起來很小，實務上解決的是真實痛點：

• 同一包套件由主 repo 與 fork／鏡像 repo分別發布
• 正式版走一條 workflow、預覽版（canary、nightly）走另一條
• 從舊 CI 遷到新 CI 的過渡期，兩邊都要能發，以前得先斷一邊
• 同一個 monorepo 裡不同 workflow 各自負責不同套件的發布

以前這些情況只能退回用 token，等於為了彈性放棄了安全性。現在不用二選一。

改動二：預設走「暫存發布」（staged publishing）。

所有設定預設是 staged publishing，要「直接發布」得逐組另外開啟。白話講就是：預設先進待審區、要人按核准，直接上架是例外而不是常態。

改動三：掃毒沒跑完，核准鍵按不下去。

官方說明：「套件還在掃描期間，核准按鈕會是停用狀態，掃描完成後才可以按。」這一條是在堵一個很現實的漏洞——人手快過機器，維護者常常在惡意程式掃描還沒結束前就按了核准。現在系統直接不讓你按。

改動四：版本歷程看得到了。

維護者可以在 npmjs.com 上查看更詳細的版本歷程，包含審核狀態與暫存資訊。

三、這對誰有影響

開源套件維護者：可以把 token 真正清乾淨了。過去因為「多條發布路徑」而被迫保留的 token，現在可以改成多組 OIDC 設定。建議順手做兩件事：把舊 token 撤銷、把直接發布的開關關掉只留暫存。

用套件的公司／團隊：你不用做任何事，但你依賴的上游套件被投毒的機率下降了一點。npm 生態的攻擊路徑裡，「維護者 CI token 外洩」長年排前幾名。

只是寫 code 的一般開發者：沒有動作。

四、我們的看法

這一則的重點其實不在「多組設定」這個功能本身，而在它把安全做法從「不方便」變成「可行」。

安全機制最常見的死法不是被破解，是被繞過——當唯一的安全做法會擋住正常工作流程，人就會退回去用 token，然後那把 token 會活五年。這次的調整把那個藉口拿掉了。

搭配「預設暫存」「掃描完才能核准」，可以看出 npm 在把發布流程往「預設安全、例外才快」的方向調。對 JavaScript 生態來說，這比任何一次功能更新都實在。

本文事實依據為 GitHub 官方 Changelog（2026-09-03），查核日 2026-09-07。設定步驟請以 npm 官方文件為準。開發工具的方案整理見我們的 GitHub Copilot 工具頁。