「2 週間に 2 度目」のサプライチェーン攻撃——npm パッケージの自動盗難ツール、Microsoft を狙う

npm レジストリに潜むセキュリティの脅威が、新しい段階へ進みました。73 個のパッケージに混入した自動複製マルウェアが、開発者環境にインストールされると同時に起動。しかも、この攻撃は「2 週間の間に 2 回目」という異常な頻度で発生しています。

何が起きたか——73 個のパッケージから credential stealer を検出

セキュリティ研究者が発見したのは、npm レジストリに登録された 73 個の悪意あるパッケージ。これらは以下の特徴を持ちます：

攻撃の仕組み

  1. パッケージのインストール時に自動実行 — npm install で依存パッケージをダウンロードする際、install スクリプトが自動的に悪意あるコードを実行
  2. 認証情報（credential）を盗難 — 開発者のローカル環境に保存された API キー、トークン、パスワードを抽出
  3. 自動複製機能 — 盗まれた認証情報を使って、別の npm パッケージに同じコードを拡散

ターゲット：Microsoft エコシステム

パッケージの命名規則から、攻撃の意図が明確です：

  • Microsoft 公式ツール関連のパッケージに似た名前
  • GitHub Actions、Azure DevOps などの開発ツールユーザーを対象
  • 企業の CI/CD パイプラインに組み込まれることを狙う

「AI エージェント」が狙われている理由

特に注目すべき点は、Ars Technica の記事タイトルにも反映されている「AI エージェントが開くとすぐに起動される」という設計です。

背景：エージェント AI の自動コード解析

生成 AI の発展により、開発者やセキュリティチームが自動化ツール（AI エージェント）を使用するケースが増加しています。これらのエージェントは：

  • コードを自動的に読み込む（依存パッケージの分析、脆弱性スキャン）
  • install スクリプトを実行トリガーとして使用（パッケージの動作検証）
  • 人間が目視せずに処理（スピード重視の自動ワークフロー）

つまり、攻撃者は「人間の開発者は気付かない、だが AI エージェントは必ず実行する」という脆弱性を狙っているのです。

「2 週間に 2 度」という異常な攻撃頻度

今回の 73 パッケージは、2 週間以内にほぼ同じ手法で 2 度目の大規模攻撃です。前回はより小規模でしたが、今回は：

  • 数が増加（パッケージ数、影響範囲）
  • 手法の最適化（自動複製機能を強化）
  • ターゲットの精密化（Microsoft エコシステムに特化）

これは「テスト段階から本番化への転換」を示唆しています。

開発者・企業が注視すべき点

即座の対応

  • npm パッケージのインストール時に、知らない package.json スクリプトが含まれていないか確認
  • CI/CD パイプラインで npm audit を継続実行
  • 疑わしいパッケージを検出した場合、npm に報告

根本的な脅威

このような攻撃の根本的な問題は、npm レジストリの「誰でも登録可能」というモデルにあります。

  • オープンソースの利点 — 低い参入障壁で多くの開発者が貢献
  • セキュリティの課題 — 悪意ある者も同じく参入可能

npm は既に以下の対策を強化しています：

  • パッケージの署名検証（experimental phase）
  • install スクリプトの制限（npm ci での実行防止オプション）

しかし、これらの対策が完全に浸透するまでは、攻撃のリスクは残ります。

AI 時代の新しいセキュリティ脅威

この攻撃が示すのは、自動化ツールが新しい脆弱性になった という現実です。

従来の防御が効かない理由

  1. 人間のコードレビュー — AI エージェントが自動化した処理は、人間の目を通さない
  2. スピードトレードオフ — セキュリティよりも自動化の効率が優先されやすい
  3. スケール — ツール化された攻撃に対して、手動の防御は追いつかない

開発者が「AI に任せる」範囲が広がるほど、サプライチェーン攻撃はより巧妙で危険になります。

次のステップ

npm、GitHub、Microsoft は共同で以下に取り組む必要があります：

  1. package.json の検証強化 — install スクリプトの自動実行制限
  2. AI エージェントのセキュア設計 — 自動化時の認証情報隔離
  3. デフォルトセキュリティ — オープンデフォルトではなく、明示的な許可型への転換

開発者側では、「自動化の利便性」と「セキュリティリスク」のバランスを、プロジェクトごとに判断する慎重さが今後ますます重要になるでしょう。