npm 12 正式發布，這次更新的核心目標是降低供應鏈風險。對於許多習慣於 npm install 就能完成所有環境配置的開發者來說，這次的變動會直接影響到日常的開發流程，尤其是那些依賴原生模組編譯或自動化安裝腳本的專案。
為什麼要禁用安裝腳本
在 Node.js 生態系中，許多套件會在 package.json 中定義生命週期腳本，例如 preinstall、install 和 postinstall。這些腳本允許套件在安裝過程中自動執行任意 shell 指令。
從安全角度來看，這是一個巨大的漏洞。如果一個被廣泛使用的第三方套件被駭客劫持（供應鏈攻擊），攻擊者只需在 postinstall 腳本中加入一行惡意指令，就能在所有執行 npm install 的開發者電腦上執行任意代碼，例如竊取環境變數中的 API Key 或安裝後門。
npm 12 的重大變更
為了截斷這個攻擊路徑，npm 12 將原本預設開啟的自動執行行為改為預設關閉（Opt-in）。
首先是禁用生命週期腳本。現在 allowScripts 預設為 off，這意味著上述的 preinstall 等腳本以及 implicit node-gyp（用於編譯 C++ 原生模組的工具）將不再自動執行。如果你的專案需要這些腳本才能運作，你必須明確地授權。
其次是限制外部依賴解析。為了防止攻擊者透過惡意 URL 誘導安裝不安全套件，npm 12 將 allow-git 與 allow-remote 預設設為 none。這表示除非開發者明確允許，否則 npm 不會解析來自 Git 倉庫或遠端 URL（如 https tarballs）的依賴項。
開發者該如何應對
當你升級到 npm 12 後，若發現某些套件因缺少安裝腳本而無法運作，你不能再簡單地用參數強行開啟，而應採取審核機制。
建議的流程是執行 npm approve-scripts --allow-scripts-pending。這個指令會讓你審查哪些腳本請求執行，確認安全後，npm 會將這些信任的腳本記錄在 package.json 的白名單中。接著將此變更提交至版本控制系統，讓團隊其他成員在安裝時也能共享這份信任清單。
強化認證機制與 Token 管理
除了安裝端的安全，npm 12 同時針對發布端的權限管理進行了大幅縮減，主要針對 GATs（Granular Access Tokens，細粒度存取令牌）。
過去部分 GATs 被設計用來繞過 2FA（雙因素認證）以實現自動化發布。但這種做法增加了 Token 洩漏後的風險。因此，npm 將限制繞過 2FA 的 Token 權限。這些 Token 將無法執行敏感操作，例如更改帳號密碼、管理組織成員、修改套件維護者或變更 2FA 配置。
在發布權限方面，這類 Token 將失去直接發布套件的能力。未來它們僅能讀取私有套件或將套件放入暫存區（Staging），最終必須由人類操作員通過 2FA 認證後才能正式公開。GitHub 建議開發者將自動化發布流程遷移至 OIDC（OpenID Connect，一種標準的身份驗證協議），實現 Trusted Publishing（信任發布），徹底擺脫長期有效的靜態 Token。
生態系的同步趨勢
這種強化安全意識的趨勢在其他工具中也同步發生。例如 pnpm 11.10 引入了新的 _auth 設定方式，將認證憑據與對應的主機 URL 綁定在一起。
這樣做的目的是防止一種常見的攻擊手法：攻擊者修改專案內的 .npmrc 或 pnpm-workspace.yaml 檔案，將合法的 Token 指向一個惡意的偽造 Registry（套件倉庫），從而誘騙開發者將 Token 傳送到攻擊者的伺服器。透過將憑據與主機綁定，pnpm 確保 Token 只能發送到正確的目標，封堵了憑據被盜取的路徑。
總結與實務建議
npm 12 的更新代表了 Node.js 社群從信任預設轉向零信任（Zero Trust）的轉型。對於工程師而言，這意味著安裝過程可能會變得稍微繁瑣，但換來的是更高的系統安全性。
建議開發者採取以下行動：優先升級至 npm 11.16.0 或更新版本以預覽警告訊息，逐步審核並將必要的安裝腳本加入白名單，並將 CI/CD 的發布流程從靜態 Token 遷移至基於 OIDC 的信任發布機制。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。