世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

2026-05-28

npmが2FA必須の公開制御を導入、サプライチェーン攻撃対策を強化

記事のキーポイント

npm に staged publishing が追加され、公開前に人間による 2FA承認 が必要になった
これにより、CI/CD からの自動公開でも「本当に人が関与したか」を確認しやすくなる
npm stage publish は npm CLI 11.15.0 以降 が必要
既存の -allow-git に加えて、非 registry 由来の install 元を制御する3つのフラグが追加された
いまソフトウェアサプライチェーン攻撃が増えているので、こうした防御はかなり重要

本文

npm と GitHub が、ソフトウェア供給網のセキュリティを強化する新しい仕組みを出しました。
ざっくり言うと、「npm パッケージを公開するときに、勝手に世に出ていかないようにする」ための対策です。

これ、地味に見えてかなり重要です。というのも、近年の攻撃者は「アプリ本体」よりも、開発者が日常的に使うライブラリやパッケージ管理の流れを狙うことが増えているからです。つまり、1つの悪意ある更新が入るだけで、多くの開発現場に一気に広がってしまうわけです。いや、怖いですよね。

staged publishing って何が変わるの？

今回一般提供になったのが staged publishing という機能です。

従来の npm publish は、公開コマンドを実行するとすぐにそのバージョンが npmjs.com で install 可能になりました。
でも staged publishing では、まず「ステージ用の待機場所」にアップロードされ、そのあと人間の maintainer が明示的に承認してから公開されます。

ここでのポイントは、承認時に 2FA（2要素認証） が必須なことです。
2FA は、パスワードだけでなく、スマホの認証アプリやセキュリティキーなど、もう1つの確認を求める仕組みですね。要するに、パスワードが漏れても即公開されにくいということです。

GitHub の説明では、これによって公開のたびに proof of presence、つまり「その場で人がちゃんと確認した証拠」を残せるようにする狙いがあるとのこと。
CI/CD（継続的インテグレーション/継続的デリバリー。自動でテストやビルド、公開まで回す仕組み）や、OIDC（OpenID Connect。外部サービスに安全に認証する方式）を使った trusted publishing からの公開でも、この考え方を適用できるのが面白いところです。

個人的には、ここはかなり良い方向だと思います。
自動化は便利ですが、公開だけは「最後に人が止められる」設計のほうが安心です。特にパッケージ公開は、一度出ると戻すのが大変なので。

使える条件は少しある

ただし、誰でもすぐ使えるわけではありません。記事によると staged publishing を使うには、次の条件があります。

その package に対する publish 権限を持っていること
その package がすでに npm registry に存在していること
- つまり、新規 package は staged にできない
アカウントで 2FA が有効になっていること

また、コマンドは npm stage publish。
使うには npm CLI 11.15.0 以降 へ更新する必要があります。

GitHub は、これに加えて trusted publishing with OIDC と組み合わせるのを推奨しています。
これは要するに、認証の仕組みを二重三重にして、怪しい自動公開を通しにくくするという考え方ですね。

install 元を細かく制御する新しいフラグ

今回の更新でもう1つ重要なのが、package の install 元を制御する新しいフラグです。
既存の --allow-git に加えて、次の3つが追加されました。

--allow-file
- ローカルの file path やローカル tarball からの install を制御
--allow-remote
- https tarball を含む remote URL からの install を制御
--allow-directory
- ローカル directory からの install を制御

GitHub の言い方を借りると、これで 「registry 以外の install 元すべてに、明示的な allowlist（許可リスト）方式を適用できる」ようになります。

ここも実務的にはかなり大事です。
npm って、基本は registry から入れるのが王道ですが、現場ではローカル file や remote URL から入れるケースもあります。便利な反面、「どこから入れたのか分かりにくい」状態になりやすい。攻撃者はまさにそういう曖昧さを狙います。

だから、
「この種類の install は許可する／それ以外は明示的にダメ」
と決められるのは、かなり健全な設計だと思います。

背景にあるのは、サプライチェーン攻撃の急増

この動きの背景には、オープンソースの ecosystem を狙う software supply chain attacks の急増があります。
つまり、攻撃者はアプリの脆弱性そのものだけではなく、開発途中で使う部品、配布経路、依存関係を狙っているわけです。

記事では、ここ数か月で open-source ecosystem を狙った攻撃がかなり増えていて、TeamPCP と呼ばれる犯罪グループが人気 package を大規模に汚染しているとも述べています。
「汚染」という表現がまさにしっくりきます。きれいに見える supply chain に1個混ざるだけで、下流が全部巻き込まれるので。

個人的には、今回の npm の変更は「攻撃を完全に防ぐ魔法」ではないけれど、現実的に効く防御を一段増やした点で評価したいです。
セキュリティは、派手な一発より、こういう「ちょっと面倒だけど効く」改善の積み重ねが強いんですよね。