Trivyサプライチェーン侵害が自己拡散「CanisterWorm」を誘発——npmトークン連鎖と分散C2が示す新たな系統リスクです

今日の深掘りポイント

• セキュリティツール（Trivy）自体のサプライチェーン侵害を足がかりに、npm発行トークンを媒介として自己拡散する「ワーム的挙動」が実装されている点が本件の本質です。開発者端末とCIランナーの両方が感染増幅器になり得ます。
• C2にICP（Internet Computer）の「カニスター」を使う設計は、停止耐性・検閲耐性を志向した分散インフラをC2に転用する潮目を示唆します。従来のドメインブロックやホスティング凍結が利きにくくなります。
• npmトークンは権限と発行範囲の最小化が甘いと「自己増殖の燃料」になります。ローテーション・短命化・スコープ制限・発行元固定（provenance）で燃料を枯渇させる設計転換が急務です。
• 依存パッケージ汚染は「アップストリーム→CI→ダウンストリーム」の三段跳びで拡散します。検出は多層（入手元検証・ビルド時検証・実行前健全性検証）の三重化で臨むべきです。

参考情報: The Hacker Newsの初報

はじめに

Trivyの配布経路に対するサプライチェーン攻撃を起点に、自己拡散型の「CanisterWorm」が47のnpmパッケージへ連鎖したという報が入りました。C2にICPカニスターを用い、感染ホストからnpmトークンを回収して新規パッケージ改ざんや再公開に使うとのことです。編集部としての最大の懸念は、従来の「単一C2・単一侵害面」を前提にした封じ込め設計が、分散インフラC2と開発者トークンの横持ち拡散により、現場の回収力を上回る速度で破られることです。
以下、初報ベースの事実関係と、SOC/CTI/DevSecOpsの視点からの示唆を整理します。

深掘り詳細

事実関係（初報に基づく整理）

• Trivyスキャナーを狙ったサプライチェーン攻撃により、改ざんバイナリが公開され、そこから自己拡散型マルウェア「CanisterWorm」への感染が発生したと報じられています。
• CanisterWormはC2通信にICPカニスターを使用し、感染ホストに新ペイロードを配信する仕組みです。
• npmトークンを窃取・悪用して自己拡散し、開発者端末やCIパイプラインを通じた追加感染を引き起こす可能性が強調されています。
• 47のnpmパッケージが影響を受け、@EmilGroup配下の28パッケージ、@opengov配下の16パッケージが含まれるとの情報があります。
  出典はいずれも初報: The Hacker News です。

注: 上記は現時点の報道ベースであり、公式アドバイザリやI/O指標が追加されれば評価が変わる可能性があります。

編集部のインサイト（なぜ拡散が速いのか）

• 自己拡散の「燃料」はトークンです
  npmトークンはしばしば長寿命・広権限・広範囲スコープで運用されます。ワームは「~/.npmrc」「環境変数」「CIのシークレットストアや実行時環境」からトークンを刈り取り、既存パッケージの小刻みなバージョン更新やpostinstallスクリプト改ざんで連鎖させます。攻撃者が脆弱性ではなく「発行済みトラスト（トークン）」を踏み台にするため、パッチ適用や署名検証だけでは遮断しきれないのが要点です。
• 分散C2は「封鎖コスト」を攻撃者有利に傾けます
  ICPのような分散実行基盤をC2に用いると、インフラの停止や名前解決の無効化による一撃必殺が難しくなります。これにより、初動封じ込めのゴールが「1つのC2ドメイン停止」から「分散C2の観測・特性化・トラフィック抑制の組み合わせ」に変質します。
• 「セキュリティツールの供給鎖」は攻撃者にとって“最短経路”です
  開発・ビルド・デプロイの全行程で呼ばれるスキャナーは、ほぼ全てのパイプラインに挿まるため、1つの改ざんが広い面へ伝播します。検出器そのものを検証する“二重化”が必要になります（例: 異種スキャナーの冗長運用や、署名・プロヴナンス・透過ログの整合チェックの併用）です。

脅威シナリオと影響

以下は現時点の情報から導く仮説シナリオです。MITRE ATT&CKは仮説マッピングであり、確定ではありません。

• シナリオA（開発者端末の踏み台化）

  • 入口: 改ざんTrivyの取得・実行（Supply Chain Compromise: T1195）
  • 実行: Node/JS実行によるペイロード起動（Command and Scripting Interpreter: JavaScript T1059.007）
  • 認証情報: ~/.npmrcや環境変数からトークン収集（Credentials in Files: T1552.001、Steal Application Access Token: T1528）
  • C2: ICPカニスター経由のHTTP/HTTPS（Web Protocols: T1071.001 / Web Service: T1102）
  • 横展開: 盗んだトークンでnpmに不正公開（Valid Accounts: T1078、Use Alternate Authentication Material: T1550）
  • 影響: メンテナが保有する複数パッケージへ一斉汚染、利用者側にpostinstall経由で拡散です。

• シナリオB（CIランナーの感染増幅器化）

  • 入口: CIがキャッシュやArtifactsから改ざんTrivyを取得（Supply Chain Compromise: T1195）
  • 認証情報: ランナーの環境変数・シークレットからNPM_TOKEN等を収集（T1528、T1552.001）
  • C2/更新: 分散C2から新ペイロード取得（Ingress Tool Transfer: T1105、T1102）
  • 横展開: 組織スコープの多数パッケージへ自動発行・微小更新（T1078、T1550）
  • 影響: 組織単位での大規模再公開、下流プロジェクトのロックファイル更新やCI実行で二次感染です。

• シナリオC（下流利用者への段階的汚染）

  • 入口: 依存解決で改ざんnpmパッケージを取得（Trusted Relationship/Dependency: T1199やT1195.002の様態）
  • 実行: package.jsonのscripts（preinstall/postinstall）を介したコード実行（T1059.007）
  • 認証情報/拡散: 開発者環境や別CIから追加トークン回収（T1528、T1552.001）
  • 影響: 連鎖的に別組織のパッケージ公開機能が攻撃者に“肩代わり”され、汚染がジワジワ広がる形です。

業務影響の射程は、単に「感染パッケージを使っているか」に留まりません。CIのトークン・キャッシュ・Artifacts・ビルドコンテナ全般が攻撃の横持ち面になり得るため、「ソフトウェアが動く場所」すべてが資産・責任範囲だと再定義する必要があります。

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

緊急度が高い順にまとめます。現場で“すぐ回せる順番”を意識した優先度付けです。

• 直ちに実施（0–24時間）

  • npmトークンの一斉ローテーションと棚卸しです。不要トークンは削除し、必要トークンもスコープ最小化（特定パッケージ/組織のみに限定）、発行目的ごとに分割します。
  • CI環境の秘密情報を再発行します（NPM_TOKEN、GitHub/GitLabのPAT、クラウドキー等）。PR由来のビルドで秘密に触れない設計を再確認します。
  • 直近でTrivyを取得・更新・使用した全ジョブと端末を棚卸しし、当該期間のビルド成果物を一時的に信頼しない前提で隔離・再ビルド方針を決めます。
  • 組織スコープのnpm公開履歴を全件監査し、不審なバージョンの即時unpublish/Deprecateと告知準備を進めます（影響バージョン、対策版、ロールバック手順のテンプレート化）です。

• 数日以内に実施（24–72時間）

  • トークン短命化と発行経路の見直しです。長寿命の静的NPM_TOKENを廃止し、可能な限りOIDC/ワークフロー限定・環境限定・IP制限で短命化します。
  • GitHub Actions等のサプライチェーン強化です。ActionsはコミットSHAでピン留め、外部アクションのAllowlist化、Fork/PRコンテキストでのSecrets無効化、セルフホストランナーのネットワーク分離（インターネット直通の最小化）を徹底します。
  • npmパッケージ公開のプロヴナンス（provenance）を強制し、組織内で「provenanceのないリリースはビルドに取り込まない」ポリシーを定義します。ローカル発行をやめ、CI経由の署名付き発行に一本化します。
  • egress監視とDLP的アラートを強化します。CI/開発端末からの不審な外向きHTTP(S)、特に分散型C2に相当するエンドポイントへの到達と、npm publish・whoami等の実行パターンを相関検知します。

• 設計の抜本見直し（1–2週間）

  • 二重の検証線を引きます。セキュリティツールの取得経路とバイナリ検証（署名/透過性ログ/チェックサム）を“別実装の仕組み”で二系統化し、どちらかが改ざんされてももう一方で検知できる構造にします。
  • 依存関係の固定と健全性検証です。ロックファイルの厳格運用（npm ci）に加え、postinstall等の実行系スクリプトを禁止または明示許可式にし、不意の実行経路を断ちます。
  • 組織内npmレジストリ（プロキシ/キャッシュ）の導入・改修を検討し、外部レジストリからの直接取得を減らします。取り込み前検査（静的解析・YARA・既知悪性ドメイン参照等）を挟みます。
  • インシデント演習を行い、「トークン連鎖型汚染」を想定した封じ込め手順（トークン失効、影響版Deprecate、ユーザ告知、強制ロールバック）を一日で回せるよう標準業務化します。

• ハンティングの糸口（具体の観測ポイント）

  • 開発端末/CIでの新規npm publish・dist-tag変更・パッケージ権限変更の監査ログ異常です。
  • ~/.npmrc更新やNPM_CONFIG_*環境変数の不審な設定変化、CIログにおけるwhoami実行の増加です。
  • CIからの外向きHTTPで、通常のアーティファクト配信・公式ミラー以外への到達が短時間に集中していないかを確認します。
  • package.jsonのscripts（preinstall/postinstall/prepublishOnly等）への差分混入と不可解なネットワーク呼び出し（curl/wget/HTTPクライアント）の混入です。

最後に、今回のような「トラストを踏み台にする連鎖」は、個々のCVE対応の外にあります。鍵は「誰が、どこから、どうやって“信頼された”リリースを作り、広げているか」を可視化し、トークンと発行経路のトラスト境界を細く短く設計し直すことです。スキャナーに限らず、全ての“よく使う便利ツール”が同じ攻撃面を抱える以上、二重検証と短命トークン化を“標準装備”にすることが、次の連鎖を止める最短距離です。

参考情報

• The Hacker News: Trivy Supply Chain Attack Triggers Self-Spreading ‘CanisterWorm’ Infecting 47 npm Packages