GitHubは2026年5月22日、npmのサプライチェーンセキュリティを強化する更新として、Staged publishingの一般提供開始と、新しいインストール元制御フラグを発表した。いずれもnpm CLI 11.15.0以降で利用できる。

• Staged publishing and new install-time controls for npm - GitHub Changelog

Staged publishingは、パッケージのバージョンを直接レジストリへ公開するのではなく、事前にステージング領域へ送信し、メンテナーが明示的に承認してからインストール可能にする仕組み。事前にビルドされたtarballはステージキューへアップロードされ、2要素認証（2FA）を伴うメンテナーの承認が終わるまで、利用者がインストールできる状態にはならない。

利用するには、公開したい場面でnpm publishの代わりにnpm stage publishを使う。npmのStaged publishingドキュメントでは、npm CLI 11.15.0以降とNode.js 22.14.0以降に加え、公開権限を持つこと、対象パッケージがすでにnpmレジストリに存在すること、npmアカウントで2FAが有効になっていることを前提条件としている。新規パッケージを初回公開する用途では使えない。

ステージキューはnpm CLIまたはnpmjs.comで確認できる。npm CLIではnpm stage list [<package-spec>]、npm stage view <stage-id>、npm stage download <stage-id>で一覧表示、詳細確認、tarballのダウンロードを行う。最終的な公開はnpm stage approve <stage-id>またはnpmjs.com上のApprove操作で行い、この承認時に2FA確認が求められる。承認しない場合は、npm stage reject <stage-id>でステージング済みパッケージを取り下げられる。

Staged publishingは、Trusted publishingと組み合わせる構成も推奨されている。Trusted publishingはOIDCを使ってCI/CDワークフローからnpmパッケージを公開する仕組みで、長期有効なnpmトークンへの依存を減らせる。Staged publishingと組み合わせる場合、信頼済み発行者の設定をステージング専用に限定できる。この設定では、そのワークフローからのnpm publishは拒否され、npm stage publishだけが受け付けられるため、CIは非対話でステージキューへ送信し、人間のメンテナーが後から承認する流れになる。

あわせて、npm CLI 11.15.0ではインストール時の依存解決元を制限する--allow-*系フラグも追加された。2026年2月に追加された既存の--allow-gitに加え、今回の更新では--allow-file、--allow-remote、--allow-directoryを使えるようになった。追加された3つは、ローカルファイルパスやローカルtarball、リモートURL、ローカルディレクトリからのインストールを制御するためのフラグとして扱われる。

これらのインストール元制御フラグは、.npmrcやpackage.jsonのconfigにも記述できる。まず確認しておきたい指定値は、すべて許可するall（現行の既定値）と、許可しないnone。詳細はChangelogからもリンクされているinstallリファレンスとconfigリファレンスで確認できる。

既存の--allow-gitは、npm CLI v12でデフォルトの値がallからnoneへ変わる予定。今回追加された3つのフラグも、現時点でnoneを指定すれば、レジストリ以外から取得する依存をより厳しく制限できる。

こうした更新は、npmパッケージを対象にしたサプライチェーン型の攻撃を緩和するための措置といえる。関連する動きとして、npmの公式Xアカウントは2026年5月20日、Mini Shai Huludのパターンに沿った攻撃を防ぐため、2FAを迂回する書き込み権限付きのgranular access tokenを無効化したと案内している。該当する自動化で保存済みトークンを使っている場合は、トークンを更新し、ワークフローを再実行するよう呼びかけている。続く投稿では、こうしたトークンへの依存を減らす方法として、Trusted publishingの利用も挙げている。