npm v12 Breaking Changes: Security-First Defaults for Install Scripts and Dependencies

npm v12 透過將多項自動行為轉變為明確的選擇性加入（opt-in）要求，為 npm install 引入了安全優先的方法。這些變更旨在封閉供應鏈攻擊中常用的常見程式碼執行路徑，將預設立場從「允許所有」轉變為「預設拒絕」。

Install Scripts Now Require Explicit Approval

從 npm v12 開始，npm install 將不再自動執行來自依賴項的 preinstall、install 或 postinstall 腳本。此變更包括原生 node-gyp 建置；包含 binding.gyp 檔案的套件將會被封鎖，因為 npm 會為其執行隱含的 node-gyp rebuild。此外，來自 Git、檔案或連結的依賴項之 prepare 腳本也會被封鎖。

為了管理這些權限，npm 提供了一套新的允許清單（allowlist）系統：

  • Identification: 使用者可以執行 npm approve-scripts --allow-scripts-pending 來識別目前被封鎖的套件。
  • Approval: 使用 npm approve-scripts 來啟用受信任的套件。
  • Denial: 使用 npm deny-scripts 來明確地封鎖不受信任的套件。
  • Persistence: 生成的允許清單將儲存在 package.json 中，且應提交至版本控制系統以確保跨環境的一致性行為。

Restricted Resolution of Git and Remote Dependencies

為了防止在依賴項解析階段進行未經授權的程式碼執行，npm v12 限制了外部來源的處理方式：

Git Dependencies

npm install 將不再解析 Git 依賴項（無論是直接還是傳遞性的），除非使用了 --allow-git 旗標。這可以防止一種特定的攻擊向量，即 Git 依賴項的 .npmrc 檔案可能被用來覆蓋 Git 執行檔，即使在忽略腳本的情況下，這種風險仍然存在。

Remote URLs

從遠端 URL 解析的依賴項（例如 HTTPS tarballs）現在預設為停用。這些必須使用 --allow-remote 旗標來明確啟用。請注意，--allow-file 和 --allow-directory 旗標將維持其目前的預設值，在 v12 中不會改變。

How to Prepare for the v12 Upgrade

開發者可以透過升級到 npm 11.16.0 或更高版本來開始為 2026 年 7 月的發佈做準備。在此版本中，新的安全行為會在警告提示下提供。建議的遷移路徑如下：

  1. 升級到 npm 11.16.0+。
  2. 執行標準安裝程序並查看產生的警告。
  3. 執行 npm approve-scripts --allow-scripts-pending 以查看待處理的腳本。
  4. 核准受信任的套件，並提交更新後的 package.json。

Community Perspectives and Technical Analysis

此公告在開發者之間引發了關於這些變更的有效性與時機的重大討論。

Supply Chain Security

一些社群成員指出，這些變更解決了長期存在的漏洞。一位使用者指出，這項發佈解決了一個早在 10 年前就已報告的漏洞，而其他人則評論說，這種轉變是為了回應過去兩年內積極利用的供應鏈漏洞增加的情況。

Comparison to Other Package Managers

幾位評論者觀察到，npm 是在採用其他工具（特別是 pnpm）已經建立的模式，pnpm 在更早之前就實施了類似的腳本封鎖預設值。

Critical Counterpoints

並非所有開發者都將這些變更視為完整的解決方案。社群中提出的一些論點包括：

"What a pointless change. If you force every user to just use '--enable-unsecure-feature', guess what will happen? This is not about improving security. This is about shifting blame."

其他疑慮也包括 package.json 中的允許清單是否會鎖定到特定的套件版本，或者僅鎖定到套件名稱，以及這些預設值是否也會套用至套件的全域安裝。

Proposed Alternatives

對於進一步安全改進的建議包括：實施沙盒（sandboxes）或模擬執行（simulation runs）以在執行前預覽腳本活動，以及更嚴格的發佈要求，例如發佈者必須透過智慧型手機應用程式進行強制性多因素驗證，以及發佈者需提供經過驗證的政府身分證件。

Sources