ランタイムで牙をむくnpm偽パッケージ──indexed-btreeを軸に広がる供給網汚染の新手口

今日の深掘りポイント

• インストール時ではなく「実行時」に発火するマルウェアで、npmライフサイクルスクリプト無効化をすり抜ける設計です。
• 信頼を装うためにGitHubリポジトリを整備し、公開リポジトリ上の悪性コード露出を避ける手口が核にあります。
• 中心パッケージとされるindexed-btreeは週次約200万ダウンロード規模と報じられ、影響面での“母集団”が大きいです。
• 依存の導入＝発火ではなく、機能呼び出し時にのみ動くため、感染評価とインシデント対応の粒度がより難しくなります。
• CIでの--ignore-scriptsやロックファイル固定だけでは不十分で、実行時のふるまい監視・ネットワークEgress制御・SBOM可視化の三位一体が鍵です。
• 短期は依存棚卸と秘匿情報ローテーション、長期はプロベナンス/署名検証とポリシー実行（許可リスト・ドメイン制御）を工程に組み込みます。

はじめに

サプライチェーン攻撃の舞台は、いまや「開発時」から「運用時」へとシフトしています。今回報じられたnpmの悪性パッケージ群は、従来のpostinstallなどのライフサイクルスクリプトを悪用する常套手段から一段抜け出し、アプリケーションが通常どおり動きはじめた瞬間に牙をむく、いわば“ランタイム・トリガー型”です。対策の難しさは、CIの保護網をくぐり抜け、気づいたときには本番コンテキスト（本物の認証情報・実データ・到達可能な社内リソース）に触れている可能性がある点にあります。

本件は地理も業種も選ばない横断的な供給網汚染の典型で、国家支援型攻撃の足場としても利用し得る構図です。現場は「依存を止める」だけでなく、「どこまで踏み込まれたか」を冷静に分解し、ランタイムのふるまいから逆算して被害境界を定義する力が問われます。

参考として報道では、indexed-btreeを中心に10個のパッケージが関連し、合計で数百万回規模のダウンロードが確認されたとされています。また、攻撃者はGitHub上の体裁を整えて信頼性を演出し、悪性コードを公開面から隠す工夫をしています。詳細は末尾の参考情報をご覧ください。

深掘り詳細

事実（報道で確認できるポイント）

• npm上で悪性のJavaScriptパッケージが少なくとも10件見つかり、合算で数百万回ダウンロードされています。中心とされるindexed-btreeは週次約200万ダウンロード規模と報じられています。
• これらはnpmのライフサイクルスクリプト保護（インストール時の検知・ブロック）を回避し、通常のアプリ実行フェーズでのみ悪性コードが動く仕立てです。
• 攻撃者はGitHubリポジトリを用意し、公開の表側から悪性コードを見えづらくすることで信頼度を装っています。
• 推奨アクションとして、該当依存の即時利用停止、開発環境の再構築、すべての認証情報のローテーションが挙げられています。
• 出典（報道）: GBHackers: 10 Malicious npm Packages Linked to a Runtime Malware Campaign

インサイト（編集部の見立て）

• “ランタイム発火”の意味合い: CIで--ignore-scriptsやビルド環境のサンドボックスを厳格化していても、運用時のアプリ実行によってはじめて不審挙動が現れるため、従来のゲートキーピングだけでは防ぎ切れない構造になります。製品本番のネットワーク権限・トークン・ユーザデータに直接タッチできる分、被害の実質的な深刻度は高まりやすいです。
• 「見せGitHub」の効用: OSSの信頼は“リポジトリの見栄え”に左右されがちです。READMEやIssueの健全性、公開のsrcと配布物（tarball/dist）の差分、メンテナの履歴といった“周辺メタデータ”を整えることで、スキャナや人手のレビューをすり抜ける余地が生まれます。今回は、公開側から悪性コードを意図的に隠すことで、この心理的・運用的バイアスを突いています。
• 影響評価の難所: ライブラリを導入しただけでは動かず、特定の関数呼び出しや環境条件でのみ実行される場合、インシデントレスポンスは「依存があるか否か」ではなく「該当コードパスが通ったか」による分岐が必要になります。ログ・トレース・ネットワークフローの相関分析を前提に、より粒度の細かい“踏み込み境界（blast radius）”の確定が不可欠です。
• セキュリティ工学の示唆: 依存監査の“静的”偏重から、実行時ポリシー（例：外部ドメイン通信の強制制御、child_process/動的importの制約、暗号鍵ファイル領域へのアクセス制限）まで拡張する、エンドツーエンドのガバナンスが要請されています。SBOMやプロベナンスだけでなく、実行中のふるまいを縛る“負の権限設計（最小権限＋否認則）”の導入が実効的です。

脅威シナリオと影響

以下は、報道内容を踏まえた仮説シナリオです。個々の環境により異なるため、実ログに基づく検証を優先してください。

• 初期侵入（サプライチェーン）

  • シナリオ: 悪性npmパッケージ（例：indexed-btree）を依存として導入し、本番実行で該当関数パスが通過してコードが発火します。
  • ATT&CK仮説: Supply Chain Compromise（T1195）、Masquerading（T1036）。

• 実行・防御回避

  • シナリオ: ランタイムでのみ自動実行し、CIの--ignore-scripts等を回避。難読化や最小限の条件分岐でサンドボックス検知も逃れます。
  • ATT&CK仮説: Command and Scripting Interpreter: JavaScript（T1059.007）、Obfuscated/Compressed Files and Information（T1027）、Virtualization/Sandbox Evasion（T1497）。

• ペイロード取得・C2

  • シナリオ: HTTP(S)経由で追加ペイロードや設定を引き出し、恒常的な通信路を確立します。
  • ATT&CK仮説: Ingress Tool Transfer（T1105）、Application Layer Protocol: Web Protocols（T1071.001）。

• 情報収集・資格情報狙い（仮説）

  • シナリオ: 実行環境の環境変数・クラウドメタデータ・ローカル設定から機密を収集し送出します。
  • ATT&CK仮説: System Information Discovery（T1082）、Credential in Files/Unsecured Credentials（T1552系）、Exfiltration Over C2 Channel（T1041）。

• 横展開（仮説）

  • シナリオ: 取得したトークンや内部到達性を用い、CI/CD・レジストリ・ソース管理へ更なる侵入を試みます。
  • ATT&CK仮説: Valid Accounts（T1078）、Exploitation of Remote Services（T1210）、Trusted Relationships（T1199）。

影響の勘所としては、（1）本番ランタイムに結びつく実データと秘密情報、（2）組織境界を越える横移動の踏み台化、（3）“見た目は健全”な依存を通じての再感染リスク、の三点が中核です。報道の印象としても、緊急性・実行可能性が高く、既存の運用ガード（CI段階のスクリプトブロックや静的監査）だけではカバーしきれない構造が見て取れます。

セキュリティ担当者のアクション

短期（0–24時間）

• 影響棚卸と即応
  • SBOM/ロックファイルからindexed-btree等の該当パッケージ名を検索し、導入有無とバージョン範囲を特定します。
  • 利用停止・固定：該当依存を即時除去・置換、または影響版をピン止め回避します。CIは一時的に--ignore-scripts、ネットワークを閉じた検証環境で再ビルドします。
  • 資格情報ローテーション：アプリ・CI・開発端末のトークン/APIキー/クラウド資格情報を優先度順に更新します。
  • 予兆検知：該当期間のランタイムログ（外向きHTTP(S)先、DNS問合せ、child_process起動、filesystem書き込み先）を相関分析し、未知ドメインや非定常パターンを抽出します。

中期（1–2週間）

• 実行時防御の増強
  • ネットワークEgress制御：本番ワークロードからの外向き通信は“許可リスト”制に移行します（ドメイン/ASN/TLS SNI基準）。DNSログとフローを集約し検知ルールを常設します。
  • ランタイムポリシー：Node.js実行環境のchild_process、動的import、eval等の危険API使用を計測・制御し、逸脱時にブロック/隔離します。コンテナはseccomp/AppArmorで権限を絞り込みます。
  • アーティファクト厳格化：配布物（npm tarball）と公開リポジトリの差分検証を導入し、distのみの悪性混入を検出します。リリース工程でSBOM（依存・ハッシュ）を自動生成しアーカイブします。

長期（四半期）

• 供給網ガバナンスの制度化
  • プロベナンス/署名検証：パッケージの出自・ビルド由来を検証可能なプロベナンス（ソース→ビルド→発行のつながり）や署名の適用を標準化します。
  • 依存の政策管理：未審査のメンテナ/新規発行者による依存はステージング経由でのみ採用、重要領域は“許可レジストリ＋許可パッケージ”で閉域運用します。
  • レジリエンス演習：サプライチェーン起点のインシデントレスポンス演習を実施し、「発火条件の特定→被害境界の切り出し→ローテーション→再ビルド」の手順を定着させます。

運用ヒント

• 影響評価の精度を上げるには、「依存が存在する」かではなく「どのコードパスがいつ通ったか」を時系列で確定することが重要です。APM/トレースとネットワークフローを照合し、疑わしい時刻・ホスト・プロセスを絞り込みます。
• 依存リスクは“個別の悪性判定”より“実行時の逸脱ふるまい”で横断的に発見できます。未知ドメインへの外向き、急なchild_process発生、HOMEや認証ファイルへの急な書き込みなどの共通特徴に注目します。

参考情報

• 報道: 10 Malicious npm Packages Linked to a Runtime Malware Campaign – GBHackers

本件は、セキュリティ投資の焦点を「検知の早さ」から「実行時の制御力」へと押し広げる転換点にあります。サプライチェーンの信頼は、見た目の整合よりも、由来の検証とふるまいの拘束で担保する時代です。今日の一手を、明日の既定運用に育てていきたいです。