記事

npmにステージング公開が一般提供。CI公開でも人間の2FA承認が必須に、--allow-*でインストール元の絞り込みも

GitHubは2026年5月22日、npmにステージング公開（Staged publishing）を一般提供し、CIから公開されたパッケージでも人間のメンテナーによる2FA承認なしには公開されない仕組みを導入したと発表しました。あわせてnpm install時の取得元を細かく許可制にする--allow-file／--allow-remote／--allow-directoryフラグもnpm CLI 11.15.0で追加されています。

GitHubは2026年5月22日付の公式チェンジログで、npmのサプライチェーンセキュリティを強化する2つのアップデートを公開しました。1つはステージング公開（Staged publishing）の一般提供、もう1つはnpm installの取得元を制御する新フラグ群です。いずれもnpm CLIの11.15.0以降で利用できます。

GitHub Changelogのリリース告知イメージ

画像引用元: GitHub Changelog

ステージング公開の何が変わるのか

GitHubは、これまでのnpm publishが「実行した瞬間に利用者へ即座に公開される」モデルだったと整理しています。ステージング公開では、ビルド済みのtarballを一度ステージキューにアップロードし、メンテナーが明示的に承認するまでレジストリに反映されないという挙動になります。

ステージキューの内容はnpmjs.comとnpm CLIの両方から確認できるとしており、公開フローに人間のチェックポイントを挟む構造に変わります。

GitHubはステージング公開の狙いを「公開のたびに人間の存在証明（proof of presence）を強化すること」だと説明しています。非対話型のCI/CDワークフローやOIDCによる信頼公開（trusted publishing）から発生する公開でも、ステージされたパッケージのリリースには2FAチャレンジを通った人間のメンテナーの承認が必要になります。

信頼公開とstage-only設定

GitHubは、ステージング公開を**信頼公開（OIDCベース）**と組み合わせて使うことを推奨しています。信頼公開の設定をstage-only（ステージ専用）に絞ると、そのワークフローからのnpm publishは拒否され、npm stage publishのみが受け付けられるようになります。

この組み合わせにより、CIワークフローは非対話のまま回し続けつつ、最終リリースは信頼できる端末からメンテナーが承認するという運用が可能になります。GitHubは、npm stage publishはローカルからも実行できるとしつつ、もっとも価値が高い構成はCIから公開し、信頼できる端末で承認する形だとしています。

2026年2月に提供された一括の信頼公開設定とスクリプトセキュリティで既にまとめて管理されているパッケージは、その仕組みを使ってステージング公開へ移行できるとしています。あわせて、CIワークフローのnpm publishをnpm stage publishに書き換える必要があると案内しています。

新しいインストール元フラグ

もう1つの変更は、npm installの取得元を明示的な許可制にするフラグ群の追加です。npm 11.15.0で新たに3つのフラグが入りました。

--allow-file：ローカルのファイルパスやローカルtarballからのインストールを制御
--allow-remote：リモートURL（HTTPSのtarballなどを含む）からのインストールを制御
--allow-directory：ローカルディレクトリからのインストールを制御

既存の--allow-gitはnpm 11.10.0で導入されており、Gitソース（github:、gitlab:、git+URL、owner/repoの短縮形）からのインストールを制御します。

GitHubは、各フラグがall（現在の既定）かnoneを受け付け、.npmrcやpackage.jsonのconfigにも設定できるとしています。なお--allow-gitは次のメジャーバージョン（v12）で既定がallからnoneに変わる予定であることも改めて案内されています。新しい3フラグについても、noneに設定すれば今日からより厳しい挙動にオプトインできます。

CIから公開する現場への影響

ステージング公開とインストール元フラグは、公開と取得という、サプライチェーンの両端を絞り込む仕組みです。公開側では「CIが侵害されても、人間の2FA承認なしには公開できない」状態を作れます。取得側では、想定外のソース（外部リモートURLやGit直参照）から依存が引き込まれるのを既定で防ぐ運用が可能になります。

ただし、これらは導入と同時に万能になるわけではありません。GitHubが整理している通り、ステージング公開を活かすにはnpm publishからnpm stage publishへCIワークフローを書き換える必要があり、新フラグもnoneに設定して初めて効きます。すでに信頼公開を使っている組織はstage-only構成への移行が次のステップになります。

まとめ：CI公開でも「人間が必ず通る」モデルへ

今回の更新は、CI/CDの自動公開を維持したまま、最終リリースに人間の承認を必須化する設計です。OIDCによる信頼公開とステージング公開を組み合わせる前提が明確になっており、npm周辺のサプライチェーン攻撃対策が一段進んだ形になります。

GitHubは、ロールアウトの状況や質問はGitHub Communityのディスカッションで受け付けるとしています。CIから公開しているメンテナーは、CLIのバージョン更新とnpm stage publishへの切り替え、.npmrcでの--allow-*設定の見直しを順に進めるのがよさそうです。