🗂

npmサプライチェーン攻撃を受けて考える、開発環境の信頼と対策

に公開
npm
セキュリティ対策
Supply Chain
zennfes2025infra
tech

2025年9月上旬に発生した npmサプライチェーン攻撃 は、これまでの「依存関係を信頼して使う」という前提を根底から覆しました。
攻撃は広範囲に影響し、npm公式レジストリを利用する多くの開発者・組織がリスクにさらされました。

私も対応策を色々と検討している中で見えてきた、攻撃の詳細、被害状況、対策の考え方、そして個人として意識すべきポイントを整理します。

1. 今回の攻撃の詳細について

攻撃の発端は、npmレジストリを管理する一部メンテナアカウントへの標的型フィッシングでした。
攻撃者は権限を奪取した後、人気パッケージの更新に見せかけて、自己増殖型マルウェアを混入させました。

このマルウェアは、パッケージインストール時に実行される prepare や postinstall スクリプトを悪用して、
開発環境やCI上にある 認証情報やSSH鍵を外部送信 する挙動を持っていました。

npm公式の発表によると、影響を受けたパッケージは500件以上に及び、
一部のパッケージでは悪意あるスクリプトが挿入され、認証情報などの機密情報を窃取する挙動が確認されました。[1]

また、今回の攻撃は npmに限った話ではありません。
同様の供給経路（サプライチェーン）を持つ他のパッケージエコシステム（PyPI、RubyGems、NuGet、Go Modulesなど）でも、
同様の手口で攻撃が成立し得る構造的リスクを示しています。

さらに重要なのは、今回の事象が単なる脆弱性混入ではなく、サプライチェーンモデルそのものの侵害だったという点です。
つまり、信頼の基盤である「レジストリ」「メンテナ」「署名・配布経路」といった全体の信頼構造が狙われ、
その一部を突破されてしまったことが、これまでとの決定的な違いです。

2. 被害状況

調査の結果、影響範囲は非常に広く、週あたり26億回以上 ダウンロードされるパッケージ群に感染が及びました。
具体的には以下のような被害が報告されています。

  • 開発環境からの情報漏洩
    APIキー、トークン、SSH秘密鍵などが外部に送信。
  • コードの流出や改ざん
    GitHub上でビルド済みバイナリやワークフローにマルウェアが混入。
  • 実害の発生
    一部の企業では、暗号通貨の不正送金やインフラ侵害の被害も発生。

攻撃経路が「パッケージ更新」に見えるため、通常の運用フローで防ぎにくいという点が問題を深刻化させました。

3. 対策方針検討

(1) 100%防ぐ手立ては存在しない

まず認識すべきは、サプライチェーン攻撃を完全に防ぐ手段は存在しないということです。
npmエコシステムの特性上、依存関係が多段に連鎖しており、どれか一つでも汚染されれば影響が波及します。

したがって、「被害をゼロにする」ではなく、「被害を最小化し、早期に検知・隔離する」という考え方が現実的です。

(2) 入口と出口の多層防御

対策は大きく 「入口対策」 と 「出口対策」 に分けて検討するのが有効です。

入口対策：安全な依存取得の仕組み

  1. クールタイムの設定（24〜48時間）
    新規または更新されたパッケージを即時導入せず、24〜48時間の検証期間（クールタイム）を設けることで、
    コミュニティやセキュリティベンダーからの報告を待つ余裕を作ります。
    この考え方は、pnpmが導入した minimumReleaseAge 設定[2]や、
    セキュリティベンダーによるリスク分析[3]を参考にしています。

  2. サンドボックス環境での検証
    最新バージョンを取得する際は、本番環境と切り離したサンドボックス環境でテストします。

    • 静的解析：コード差分・署名・依存関係の解析
    • 動的解析：実行挙動やネットワークアクセスをモニタリング
      これにより、マルウェア混入を早期に発見できます。

出口対策：感染後の被害最小化

  1. 内部プロキシサーバーの導入
    社内から外部npmレジストリへ直接アクセスさせず、
    内部プロキシサーバー（例：VerdaccioやArtifactory）を経由する構成にすることで、
    すべての通信を検査・制御可能にします。

  2. 不正プロセスの検知と隔離
    プロキシ層でリクエストを解析し、異常な通信や不審なダウンロードを検知した場合に、
    対象パッケージを自動的にブロック・隔離します。
    これにより、マルウェアの外部送信や二次感染を防止できます。

4. エンジニア個人が意識すること

今回の攻撃は、組織のセキュリティ体制だけでなく、
開発者一人ひとりの依存管理意識にも影響を与えました。

  • 新しいパッケージを「すぐ導入しない」
    → 評価期間を置き、コミュニティでの報告状況を確認する。
  • postinstall / prepare など、実行スクリプトを持つ依存を警戒する。
  • npmトークンやSSH鍵の管理を最小化し、不要なスコープを削除する。

さらに今回の事例では、メンテナ本人がフィッシング被害に遭い、
アカウントを乗っ取られたことが直接の原因となりました。

そのため、個々のエンジニアも次の点を強く意識する必要があります。

  • npm・GitHub・各種クラウドの2段階認証（MFA）を必ず有効化する
  • 不審なメール・DM・コラボ招待への即応を避け、公式ドメインを確認する
  • npmトークンをCIやローカルに平文で保存せず、Secrets Managerや環境変数で管理する
  • 万一漏洩した場合に備え、トークンのローテーションポリシーを明文化する

つまり、「依存先を守る」だけでなく「自分自身も依存される立場」として守る という意識が重要です。
オープンソースエコシステム全体の安全性は、個々の開発者のアカウント防御から始まります。

「npm install は外部コードを実行する行為」
そして同時に、「自分のアカウントが外部攻撃の入口になり得る」という認識を
チーム全体で共有することが、再発防止の第一歩です。

5. まとめ：組織と個人、両輪での再発防止へ

npmサプライチェーン攻撃は、
オープンソースの恩恵とリスクが常に隣り合わせであることを明確に示しました。

再発防止に向けては、組織と個人がそれぞれの立場で対策を講じることが欠かせません。

組織としての取り組み

  • 内部プロキシ構築・通信経路監視による出口対策
  • サンドボックス検証とクールタイムによる入口対策
  • package.jsonのバージョン固定
  • 教育・ポリシー整備による継続的なリスク低減

個人としての意識

  • MFA・秘密情報管理の徹底
  • フィッシング・ソーシャルエンジニアリングへの警戒
  • 依存ライブラリの信頼性確認・即時導入を避ける姿勢

攻撃は防ぎきれなくても、被害は設計と意識で小さくできる。
この視点を共有し続けることが、今後の開発組織に求められる「持続的セキュリティ文化」です。

📚 参考情報

脚注

  1. “Our plan for a more secure npm supply chain” (GitHub Blog) ↩︎

  2. pnpm: Supply Chain Security — minimumReleaseAge 設定 (公式ドキュメント) ↩︎

  3. Socket.dev Blog: “pnpm 10.16 adds new setting for delayed dependency updates” ↩︎

Discussion