JavaScript開発で広く使われているパッケージ管理サービスのnpmに、公開前の確認手順を追加する「段階的リリース」が導入されました。従来のnpmでは、公開権限を持つユーザーや自動化システムがパッケージを公開するとパッケージがnpmレジストリにすぐ反映される仕組みでした。段階的リリースではパッケージをいったん公開待ち領域に置き、メンテナーが内容を確認して承認してから一般公開される流れになります。

Staged publishing for npm packages | npm Docs

https://docs.npmjs.com/staged-publishing

Npm registry sets stage for more secure package publishing

https://www.theregister.com/ai-ml/2026/05/21/npm-registry-sets-stage-for-more-secure-package-publishing/5244527

npmはNode.jsなどのJavaScript環境で使われる部品を配布するための仕組みです。開発者はログ出力、日付処理、暗号化、UI部品などの機能を「パッケージ」としてnpmから取り込み、開発中のソフトウェアに組み込みます。つまり、広く使われているnpmパッケージが改ざんされると、パッケージを直接使っている開発者だけでなく、パッケージを間接的に使っている多数のソフトウェアにも影響が広がる可能性があります。

近年問題になっているのが、ソフトウェアサプライチェーン攻撃です。サプライチェーン攻撃とは最終製品そのものではなく、開発や配布の途中で使われる部品やアカウント、配布経路を狙う攻撃を指します。npmの場合、攻撃者がパッケージのメンテナーアカウントや公開用トークンを乗っ取ることで、正規のパッケージに見える悪意あるコードを配布できる恐れがあります。

npm開発元であるGitHubは2025年12月、ソフトウェアパッケージが侵害されたShai-Hulud 2.0キャンペーンを受けて、npmパッケージ公開者向けのセキュリティ強化策を発表していました。今回導入された段階的リリースは発表されていた対策の1つで、GitHubは2026年5月20日にnpm CLIに「npm stage」を取り込み、段階的リリースの手順を説明するnpm公式ドキュメントも更新しました。

毎週200万回以上ダウンロードされる人気の@ctrl/tinycolorパッケージが高度なサプライチェーン攻撃「Shai-Hulud」によって40以上のNPMパッケージとともに侵害を受けていると発覚 - GIGAZINE



段階的リリースを使う場合、開発者は従来の「npm publish」で直接公開する代わりに、「npm stage publish」というコマンドでパッケージを公開待ち領域へ送信します。公開待ち領域に送られたパッケージはまだ一般公開されません。メンテナーはCLIまたはnpmjs.com上でパッケージを確認し、2要素認証を経て明示的に承認します。承認が完了して初めて、パッケージがnpmレジストリで利用可能になります。

2要素認証はパスワードに加えてワンタイムコードなど別の確認手段を要求する仕組みのため、攻撃者がパスワードや公開用トークンを入手しても、追加の確認を突破できなければ公開操作を完了しにくくなります。

npm公式ドキュメントによると、段階的リリースの利用にはnpm CLI 11.15.0以降とNode.js 22.14.0以降が必要とのこと。さらに、対象パッケージへの公開権限を持っていること、パッケージがnpmレジストリにすでに存在していること、npmアカウントで2要素認証が有効になっていることも条件となっています。新規パッケージを初めてnpmへ登録する用途では段階的リリースを利用できません。

メンテナーは「npm stage list」で確認可能な公開待ちパッケージを一覧表示でき、「npm stage view」で詳細を確認できます。さらに「npm stage download」を使うと、公開待ちパッケージのtarball、つまりパッケージ一式をまとめた圧縮ファイルをダウンロードして中身を調査可能。npmjs.com上では「Staged Packages」タブから公開待ちパッケージを確認し、内容を見たうえで承認ボタンを押す流れです。



段階的リリースが特に効果を発揮するとみられているのが、自動公開のワークフローです。「継続的インテグレーション／継続的デリバリー(CI/CD)」と呼ばれる自動化環境では、コードのテストやビルド、パッケージ公開までを自動で実行することがあります。一方で、自動化環境では人間が毎回2要素認証を行うことが難しく、公開用トークンに依存しがちでした。

公開用トークンはパスワードの代わりにシステムがnpmへアクセスするための鍵のようなもので、長期間有効なトークンが流出すると、攻撃者が正規の公開権限を持つシステムになりすましてパッケージを公開できる恐れがあります。段階的リリースにより、自動化環境でパッケージを公開待ち領域へ送り、人間のメンテナーが後から2要素認証で承認する運用が可能になるというわけです。

GitHubはCI/CDプロバイダーとnpmの信頼関係を、外部サービスが正当な実行環境であることを確認するための認証技術であるOpenID Connectで確立する「信頼済み公開」も提供しています。npm公式ドキュメントによると、信頼済み公開を使う場合でも、段階的リリースを組み合わせることで、公開前にメンテナーが内容を確認して承認する流れを追加できます。

ただし、段階的リリースはすべての攻撃を自動的に防ぐ万能策ではありません。公開待ち領域に置かれたパッケージをメンテナーが十分に確認しなければ、悪意あるコードを見逃す可能性は残ります。また、攻撃者がメンテナーのアカウントと2要素認証の両方を突破した場合、承認手順そのものが悪用される恐れもあります。

それでも、公開操作を即時反映から承認制へ変えることで、トークン流出や自動化環境の侵害がそのまま公開事故につながるリスクを下げられるようになっています。今回の件を報じたThe Registerは、開発者が段階的リリースと信頼済み公開を利用すれば、ソフトウェアサプライチェーンを以前より防御しやすくなると述べました。