2026 年 5 月 12 日、gihyo.jp が npm ワーム攻撃「Mini Shai-Hulud」により TanStack など 160 以上のパッケージがマルウェアに感染 を報じました。Mini Shai-Hulud は 「感染したパッケージのメンテナ環境を踏み台に、そのメンテナが管理する他パッケージにも自動感染する」自己複製型 npm ワームで、Mistral・TanStack を含む 160 以上のパッケージに感染が拡大しています。
これまで弊社では pnpm 11 受託サプライチェーン や npm install は任意コード実行受託 DevSecOps で 「予防策」 を扱ってきましたが、本記事は 「すでに侵入された後の対応」 に焦点を当てます。中堅企業の受託案件で、TanStack を依存している → 感染している可能性があるという状況に直面したとき、インシデント対応をパッケージ化した受託サービスが必要です。
なぜ「自己複製ワーム」が中堅企業の最大級の脅威か
| 構造 | 従来攻撃との違い |
|---|---|
| 自己複製 | 1 パッケージ感染が同メンテナ全パッケージに伝播 |
| メンテナ環境侵害 | パッケージ単体スキャンでは検出困難 |
| 時間差発症 | postinstall でなく実行時に発症するケースもある |
| 影響範囲の不確定性 | 160+ パッケージへの依存追跡が必要 |
| メディア露出による信頼失墜 | 顧客への説明責任が即発生 |
これらは 「予防」だけでなく「発症後の対応速度」が事業継続性を左右する領域です。受託会社にとっては 24〜72 時間以内の初動を契約として約束できる体制が、顧客への提案価値そのものになります。
Mini Shai-Hulud が変える 3 つの構造
構造 1: 「単発パッケージ監査」から「メンテナ環境監査」へ
これまでの監査は 「このパッケージは安全か」 でしたが、Mini Shai-Hulud 以降は 「このパッケージのメンテナの他パッケージは安全か」 まで広げる必要があります。SBOM だけでなく 「メンテナグラフ」 の管理が必須です。
構造 2: 「postinstall 監視」から「実行時挙動監視」へ
postinstall フックでマルウェアを実行する古典手法は eBPF / npm-audit で検出可能になりました。Mini Shai-Hulud は アプリ実行時に発症するため、ランタイムの環境変数アクセス・外部通信まで観測する必要があります。
構造 3: 「インシデント対応は内製」から「受託対応」へ
中堅企業のセキュリティチームは 24〜72 時間でのフォレンジック対応 に必要な人員・ツールを持たないケースが大半です。受託で対応キャパシティを買う選択肢が現実的になりました。
受託で組み立てる「npm ワーム・インシデント対応」5 フェーズ
フェーズ 1: 検出（0〜4 時間）
GitHub Advisory / Snyk / Socket.dev の 緊急通知を 24 時間監視し、顧客の依存ツリーに該当パッケージが含まれるかを pnpm why / npm ls / SBOM クエリで即時確認します。
フェーズ 2: 封じ込め（4〜12 時間）
該当パッケージを使うサービスを stop or 隔離 VPC へ移動し、外部通信を全遮断します。.npmrc で registry を限定し、追加感染を防ぎます。
フェーズ 3: フォレンジック（12〜48 時間）
CI/CD ログ、本番サーバの 環境変数アクセス痕跡、外部通信ログを eBPF / CloudTrail / VPC Flow Logs から収集し、漏洩可能性を範囲確定します。GitHub Personal Access Token、Anthropic API キーなど メンテナ環境で発症すると流出するシークレットを特定します。
フェーズ 4: 復旧（24〜72 時間）
クリーン版パッケージへの差し替え、全シークレットローテーション、監査ログのアーカイブを実施します。GitHub Secret Scanning × MCP Server 受託 と組み合わせて コミット履歴の浄化まで自動化できます。
フェーズ 5: 再発防止（1〜4 週間）
メンテナグラフ監査、実行時挙動監視、pnpm 11 の遅延ポリシー、Socket.dev / Snyk Code の常時スキャンを顧客環境に組み込みます。
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| 依存追跡 | Socket.dev + Snyk + GitHub Dependency Graph | OWASP Dependency-Check |
| SBOM 生成 | Syft + Grype | CycloneDX CLI |
| 実行時監視 | Falco + eBPF | Sysdig Secure |
| シークレットスキャン | GitHub Secret Scanning + TruffleHog | GitLeaks |
| ネットワーク監視 | Cilium Hubble + VPC Flow Logs | Suricata |
| フォレンジック保管 | S3 Object Lock + CloudTrail | Splunk |
| 通知 | PagerDuty + Slack | Opsgenie |
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| Node.js / TypeScript 系の本番運用 | バックエンドが Go / Rust / Java のみ |
| 依存パッケージ 100 件以上 | パッケージ依存ゼロ運用 |
| 個人情報 / 決済情報を扱う | 内部限定の社内ツール |
| OSS パッケージへの依存度が高い | 完全自社実装の極小 |
| 顧客向け SaaS を提供 | 完全社内利用ツール |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 初動 SLA | 検出から初動までの目標時間（4 h / 12 h / 24 h） | 業務影響の許容範囲 |
| 対応スコープ | 対象環境（本番のみ or 全環境） | 範囲外環境の責任 |
| シークレットローテーション | 対象キーの範囲と完了時刻 | 業務停止可能な時間帯 |
| 法務通知 | 監督官庁・顧客への通知の責任分界 | 通知作成権限 |
| フォレンジック保管 | ログ保管期間と開示先 | 監査要件 |
| 再発防止スコープ | スキャン基盤の構築まで含むか | 追加費用の上限 |
顧客側 ROI 試算（EC 事業者・年商 30 億円想定）
| 項目 | リテイナーなし | リテイナーあり | 差分 |
|---|---|---|---|
| 検出までの時間 | 3 日〜 | 4 時間 | 大幅短縮 |
| 漏洩可能性のあるレコード数 | 100 万件想定 | 1 万件想定 | -99 万件 |
| 監督官庁報告コスト | 800 万円 | 150 万円 | -650 万円 |
| ブランド毀損による解約 | 売上 4% 減 | 売上 0.5% 減 | -3.5% |
| 想定損失総額 | 1.5 億円 | 2,000 万円 | -1.3 億円 |
リテイナー年額（80 万円 × 12 = 960 万円）に対し、1 度の事故回避だけで投資回収可能な水準です。
ハマりやすい 5 つの落とし穴
落とし穴 1: 検出後に「sleep」する
「数日様子見」が 最も損失を拡大させる選択です。検出 4 時間以内に必ず封じ込めを開始してください。
落とし穴 2: 依存ツリー全体をスキャンしない
直接依存だけ確認しても 「孫依存に感染パッケージ」が混入していることが大半です。全依存ツリー深さ無制限スキャンが必須です。
落とし穴 3: シークレットローテーションを部分実施
「主要なキーだけローテーション」では 副次キー経由の再侵入が起きます。全シークレットの一括ローテーションを契約に明記します。
落とし穴 4: ステージング環境を忘れる
本番だけ封じ込めて ステージング環境のシークレット流出が継続する事例が多発しています。全環境一斉対応が原則です。
落とし穴 5: 報告書を経営層に出さない
技術チーム内で完結すると、次回予算化が止まります。経営層向け 1 ページサマリを必ず添付しましょう。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Day 0〜3 | 検出 + 封じ込め + フォレンジック |
| Day 4〜14 | 復旧 + 報告書 |
| Week 3〜6 | 再発防止スキャン基盤構築 |
| Week 7〜12 | リテイナー切り替え + 月次レビュー会立ち上げ |
まとめ — 「自己複製ワーム」の時代に受託の役割は「対応キャパシティを売る」に進化する
Mini Shai-Hulud は 「自己複製する npm マルウェア」という新カテゴリで、「予防だけでは間に合わない」時代を加速させました。中堅企業の受託パートナーには 「24〜72 時間でフォレンジックを終わらせる対応力」が求められます。
「TanStack が感染していないか不安」「24h 体制を内製で組むのは無理」というご相談は お問い合わせフォーム からお気軽にどうぞ。
