記事

GitHubがnpmに「ステージング専用トークン」を追加——自動化の直接公開権限を分離

GitHubはnpmの粒度アクセストークンに「Read and write (stage only)」権限を追加したと発表しました。自動化ワークフローがバージョンを直接公開できないようにしつつ、レビュー担当者が二要素認証で承認する運用が可能になります。

GitHubは公式Changelogで、npmの粒度アクセストークン作成時に「Read and write (stage only)」という新しい権限を選べるようになったと発表しました。この権限を持つトークンは、自動化ワークフローがパッケージのバージョンをステージング(公開待ち状態)に置くことはできても、npmレジストリへ直接公開する権限は持ちません。CI/CDパイプラインを人手のレビューなしに公開まで走らせてしまうリスクを減らす、サプライチェーンセキュリティ強化の一環です。

ステージングと承認を分離する仕組み

新しいステージング専用トークンを使うと、ワークフローはnpm stage publishコマンドでバージョンを申請するところまでを担当します。実際の公開はパッケージメンテナーが内容をレビューし、二要素認証(2FA)で承認して初めて行われます。従来、自動化のために2FAをバイパスするよう設定されたトークンであっても、ステージング専用トークンでは直接公開の試み自体をnpm側が拒否する仕組みになっています。

盾とロック、2つのパッケージボックスをつないだセキュリティのイラスト

画像引用元: GitHub Blog

一方で、ステージング専用トークンにもdist-tagsの付け替えやバージョンの非推奨化(deprecate)など、他の書き込み系権限は引き続き付与されます。GitHubは「他の書き込みトークンと同様の注意を払って保護してほしい」と注意を促しており、公開権限がないからといって完全に無害というわけではない点は留意が必要です。

2027年1月の方針転換に向けた移行パス

この機能は既存トークンの挙動を変えないオプトイン方式で提供されます。背景にあるのは、npmがすでに予告している「2027年1月をめどに、2FAをバイパスするトークンによる直接公開を廃止する」という方針です。理想的にはtrusted publishingへの移行が推奨されますが、まだトークンベースの自動化から移行できていないプロジェクトにとって、ステージング専用トークンは中間的な移行手段として位置づけられています。

移行の具体的な手順は次の通りです。

必要なパッケージに対して「Read and write (stage only)」権限を持つ粒度アクセストークンを作成する
ワークフローの公開用トークンを差し替え、npm stage publishを使うようにする
メンテナーがステージングされたバージョンを2FAでレビュー・承認する

この機能を使うには、対象パッケージへの公開権限、npmアカウントでの2FA有効化に加えて、npm CLI 11.15.0以降とNode.js 22.14.0以降が必要です。既存のnpmパッケージでもそのままステージング公開の仕組みを利用できるとされています。

npmのサプライチェーン対策の一環として

今回の機能は単独の施策ではなく、GitHubが継続的に進めてきたnpmのサプライチェーンセキュリティ強化の延長線上にあります。過去のChangelogでも、npmアカウントのリカバリーコードによるセキュリティホールドの全アカウントへの拡大や、GitHubホスト型レジストリへのDependabotの自動アクセス、trusted publishingの複数設定対応といった発表が続いており、公開時の認証情報を狙う攻撃(トークン窃取やアカウント乗っ取りを経由した悪意あるバージョンの公開)への対策が段階的に積み上げられてきました。ステージング専用トークンは、この一連の取り組みの中でも「自動化用トークンが漏洩しても、レビューなしに公開まで到達させない」という最後の防波堤にあたる位置づけといえます。

開発チームへの影響

CI上で自動パッケージ公開を行っているチームにとっては、トークン漏洩時の被害範囲を「勝手に世界中へ公開されてしまう」から「承認待ちのステージングに置かれるだけ」に縮小できる点が大きなメリットです。特にオープンソースのライブラリを多数メンテナンスしている組織では、公開ワークフローに関わるコントリビューターの数が多くなりがちで、トークンの管理範囲を絞れる恩恵は小さくありません。次にワークフローの認証情報を棚卸しするタイミングで、直接公開トークンをステージング専用トークンに置き換えられないか確認しておく価値がありそうです。