npm供給連鎖の教訓：Axios侵害の技術解析と実践的CI/CD防御ルール

導入：なぜAxios侵害は重要か

2026年3月31日、広く利用されるJavaScript HTTPクライアントライブラリ「axios」のnpmパッケージに対して、攻撃者が不正なリリース（v1.14.1およびv0.30.4）を公開するサプライチェーン侵害が発生しました。これらのリリースは、インストール直後にクロスプラットフォームのリモートアクセス型マルウェア（RAT）を配布するための"plain-crypto-js"という悪性依存関係を導入していました。開発者やCI/CDパイプラインを経由して広範に拡散する可能性があったため、影響は非常に大きく即時の対応が必要とされました。

この事例は、攻撃者がパッケージのランタイムコードを変更せず、インストール時フック（install-time script）や偽装依存関係を用いることで監視や署名検証を回避する手口をとった点が特徴です。大規模な依存性を持つパッケージが侵害されると、1つの公開操作で数百万〜数千万のデベロッパー環境に影響が波及し得ます。

技術的解析：攻撃のチェーンと検出可能な痕跡（IOC）

攻撃の主な手順（概略）

• 攻撃者はnpmおよび/またはGitHub上のメンテナアカウントを乗っ取り、正規のリリースフローを経ない形で悪性バージョンを公開した。
• 不正なリリースは本体のソースをほぼ変更せず、代わりに新規依存パッケージ（plain-crypto-js）を追加した。その依存は実行時にimportされないが、postinstallやinstallスクリプトで二次ペイロード（RAT）をダウンロード・起動する。
• インストール直後にC2へ接続する振る舞いを見せ、OS（macOS/Windows/Linux）ごとに別個の二次ステージを配置したことが報告されている。

現場で確認すべきIOC（優先度順）

1. プロジェクトのnode_modules内に plain-crypto-js が存在するかどうか（最優先）。侵害報告では同パッケージが攻撃のトリガーとなっていた。
2. インストール時のスクリプトログ（npm/yarnの--verboseログ）、特に外部からバイナリをダウンロードするHTTP(S)接続や未知のドメインへの接続。
3. ビルド／開発マシンでの不審なネットワーク接続（短時間での大量コールホーム）、および異常なプロセス起動（RATの持続プロセス）。
4. パッケージの公開履歴とGitHubリリースフローの不整合（タグ無しでのnpm公開、OIDC/SLSAアテステーションの欠如）。

検出の難しさ
攻撃は「ランタイムコードを汚染しない」ため、単純な静的コード差分だけでは見つけにくい。さらに、インストール直後に痕跡を消去してクリーンなファイルで上書きする手法も確認されているため、ログとネットワークテレメトリが重要になります。

CI/CDに組み込むべき実践的防御ルールセット

以下は、実務ですぐ導入でき、Axios型の侵害（偽装依存／インストール時ペイロード）を効果的に検出・阻止するための具体的ルールです。各ルールはCIステップとして実装可能です。

必須ルール（高優先度）

• ビルド環境での"ignore-scripts"ポリシー：公開パイプライン（ビルド／テスト）では原則として npm ci --ignore-scripts を使い、インストール時フックの実行を禁止する（ただしネイティブモジュールが必要な場合は例外管理を行う）。この設定でpostinstall起点のペイロードを防げます。注：ネイティブ依存のビルドが必要なプロジェクトでは別途サンドボックス化したビルド専用ジョブを用意してください。
• SBOMと依存の差分検証：ビルドごとにSBOMを生成（e.g., CycloneDX）し、lockfileと照合して“新規依存”が発生した場合はブロックかつレビュー要求を出す。未承認の新規依存がmanifestに現れたらCIを失敗させる。
• 署名付きリリース／SLSAアテステーション必須化：パッケージの公開はSLSAレベルまたはOIDCを介した短期トークンでの署名済みワークフローからのみ許可する。直接npmトークンを使った手動公開は原則禁止。
• インストールログとネットワークテレメトリの収集：CIエージェントはインストール（npm/yarn）ログを保存し、外部接続を検出したらアラートを上げる。外部ホストへのPOST/GETを短時間に実行するプロセスは高リスク。

追加ルール（運用で強化）

• リポジトリ保護：パッケージ公開権限を最小化（Least Privilege）。複数メンテナでの共同レビューと2要素認証（2FA）を必須化。
• 署名ChecksumのCI検証：lockfileのintegrity（SHA）を再計算し、公開バージョンのchecksumと不一致の場合はパイプライン失敗。
• 依存性ポリシーの自動化：SBOM差分で新規依存が含まれる場合は自動的にペンディングフラグを付け、セキュリティチームが承認するまでデプロイを停止。
• レピュテーション/Riskスコアリング：npmパッケージの最近のpublish履歴、作者アカウントの作成日、ダウンロード量急増などでスコア付けし、閾値超過で手動レビュー。

CIジョブ例（擬似）

# 1. Install with ignore-scripts（検証）
npm ci --ignore-scripts
# 2. Generate SBOM
sbom-generator --output sbom.json
# 3. Check for new deps
sbom-diff --baseline sbom.lock --current sbom.json || exit 1
# 4. Verify lockfile integrity
npm ci --package-lock-only && verify-lock-integrity.sh || exit 1

上記は簡略化された例ですが、重要なのは「インストール時に任意のスクリプトを実行させない」「依存の変化をCIで阻止する」「ビルド公開時に署名と短期トークンを必須化する」ことです。これらの対策は今回のAxios事例で推奨された緩和策とも整合します。

対応手順（インシデント発生後）と実務チェックリスト

もし貴社/プロジェクトで影響バージョンを導入していた疑いがある場合、優先度に従って以下を実行してください。

1. 即時隔離：疑わしい開発機・ビルドエージェントをネットワークから切り離す。
2. IOCハント：node_modulesにplain-crypto-jsが含まれるか確認。含まれる場合は該当ホストを侵害済みとして扱う。
3. 証憑収集：npm/yarnインストールログ、CIビルドログ、ネットワークフロー（プロキシ/Firewallログ）、プロセスリストを収集。
4. 資格情報対策：該当マシンで使われたAPIトークン、SSHキー、クラウド認証情報を全てローテーション。CI用の長期トークンは無効化する。
5. 差分検証と再ビルド：クリーンな環境でlockfileを使い再ビルド。新規依存が発生していないかを確認。SBOMと署名を照合する。
6. フォレンジック：ホスト内に残存するバイナリ、永続化痕跡、C2アドレスの接続履歴を調査。可能なら外部IRベンダーと連携する。
7. 通知：影響範囲が広い場合は社内／顧客／法務と連携し、適切に通知する（供給連鎖インシデントは広範影響を生む）。

まとめ
Axios侵害は、依存関係管理とビルドフローの健全性がいかに重要かを再確認させる事件でした。攻撃者は従来のコード改変ではなく、インストール時のフックや偽依存を巧妙に使って拡散したため、SBOM、SLSA/OIDC、インストール時のスクリプト無効化、CIでの依存差分ブロックなど複層的な防御が必要です。今回挙げたCIルールセットと対応チェックリストを参考に、開発→ビルド→公開の各段階で侵害を防ぐ仕組みを実装してください。