npm が「段階的リリース」を導入 — 盗んだトークン1枚ではもう公開できない のサムネイル

npm が「段階的リリース」を導入 — 盗んだトークン1枚ではもう公開できない

重要度: 中
⏱ 約 2 分 view 41 like 0 LOG_DATE:2026-05-22
目次 / TOC

度重なるサプライチェーン攻撃にさらされてきた npm が、ついに公開フローそのものに手を入れた。世界中の JavaScript プロジェクトが依存するこの巨大レジストリは、攻撃者にとって「一度の侵入で無数の被害者に届く」格好の標的であり続けてきた。2025年12月の大規模ワーム「Shai-Hulud 2.0」をはじめ、メンテナのアカウントや CI 用トークンを乗っ取って悪意あるパッケージを配る攻撃が後を絶たない。これを受け GitHub は、公開前に人間の確認を挟む新方式「段階的リリース(staged publishing)」を導入した。

「公開=即反映」をやめた #

これまでの npm は、npm publish を実行した瞬間にレジストリへ反映される設計だった。攻撃者にとっては理想的で、盗んだトークン1枚さえあれば、週に数千万回ダウンロードされる人気パッケージへ数秒でバックドアを仕込めた。配布の速さが、そのまま被害の速さに直結していたわけだ。

新方式は、公開までに一段のクッションを挟む。

1. ステージング
npm stage publish でパッケージを公開待ち領域へ送る。
2. 確認
メンテナが CLI や npmjs.com で中身・差分を点検する。
3. 承認
2要素認証を経て、明示的にリリースを許可する。
4. 公開
承認されて、はじめてレジストリに反映される。

肝は、トークンが漏れただけでは公開が完了しなくなった点だ。最終承認に人間の 2要素認証が必須となるため、CI トークンの流出やタイポスクワッティング経由で得た権限だけでは、悪意あるバージョンを世に出せない。自動化された CI/CD とも両立し、機械が待機列に積み、人間が最後に判子を押す運用になる。利用には npm CLI 11.15.0 以上が必要で、当面は既存パッケージが対象だ。

穴が完全にふさがったわけではない #

npm の段階的リリースの仕組み:盗まれたトークン1枚では公開できなくなった攻撃モデルの図解

ハッカー視点で見れば、これは「攻撃コストを引き上げる」施策であって万能薬ではない。メンテナのアカウントそのものを乗っ取られれば、承認権限ごと攻撃者の手に落ちる。確認が形骸化し、待機列のパッケージを中身も見ずに承認してしまえば、クッションは無いに等しい。それでも、最も悪用されてきた「トークン流出」という侵入口に一枚の壁を足した意義は大きい。OSS を管理しているなら、まず段階的リリースの有効化を検討したい。

Post Share LINE B!

COMMENTS 0

まだコメントはありません。最初のコメントを投稿しよう。

コメントを投稿