TrivyのDocker Hubイメージ改ざんが示した、OSSスキャナ依存の盲点とCI/CD連鎖リスク

今日の深掘りポイント

• Docker HubのTrivy公式イメージがトロイの木馬化され、情報窃取と自己増殖ワーム拡散に利用された事案です。報道では0.69.4〜0.69.6が悪性化とされています。開発者端末とCI/CDのどちらも踏み台化し得るのが核心です。
• 脅威アクター「TeamPCP」を名乗るグループは、改ざんイメージを介して情報窃取→npmを使った自己増殖→Kubernetesクラスタ消去マルウェアという複合ペイロードを流通させています。
• スキャナは「安全な側にある」という前提が破られたことで、タグ運用、署名検証、ダイジェスト固定、プライベートレジストリミラーといった基本設計が問われています。特に“スキャナ用ネットワーク分離”の不備が被害拡大の起点になりやすいです。
• 供給網攻撃としては即応性が高く、運用の工夫で被害の分岐点を何層にも作れる領域です。逆に言えば、ひとつの“便宜”が多段の脆弱化に直結します。
• 日本企業の現場では、GitHub ActionsやGitLab CIのテンプレートにTrivyが埋め込まれているケースが多く、間接利用も含めた資産棚卸しが最優先課題になります。

はじめに

セキュリティスキャナを信頼の起点に置くことは、私たちが長らく共有してきた習慣です。今回のTrivy改ざんは、その“信頼の位置”が攻撃者にとってどれほど魅力的かを冷徹に突きつけました。開発者の机の上からCIランナー、さらにKubernetes本番まで、脅威が滑らかに横断できてしまう現代のソフトウェア供給網。その連結点をどう減速させ、どう分断するかが、今日の焦点です。

本稿では、公開情報を起点に事実を整理しつつ、運用のどこに「摩擦」を設ければ連鎖を止められるか、編集部としての視点を交えて掘り下げます。断定を避け、仮説はその旨を明示します。

深掘り詳細

事実関係（公開情報からの確認）

• 報道によれば、Trivyの供給チェーンが狙われ、Docker Hubを経由して悪意のあるTrivyイメージが配布されました。対象タグは0.69.4〜0.69.6とされ、開発者環境やCI/CDで実行されることで情報窃取と自己増殖の足がかりになりました。また、npmパッケージを用いたワーム挙動や、Kubernetesクラスタを消去する新たなマルウェアの投入も指摘されています。The Hacker Newsの報道に基づく情報です。
• 脅威アクターは「TeamPCP」を名乗り、関連する内部リポジトリの改ざん（説明文の書き換え）も報じられています。これらは攻撃の誇示や心理的圧力の常套手段と一致します。同報道が根拠です。

注記：上記は公開報道に基づく事実関係であり、技術的詳細（侵害経路の特定、IoC、改ざんの具体的仕組み）は、今後の一次情報の開示で更新される可能性があります。

インサイト（編集部の考察）

• “スキャナは特権”という構造的リスクです。TrivyはCI/CDの幅広い段で使われ、イメージスキャンやIaC、SBOM生成などに関与します。つまり、ネットワーク外部通信、リポジトリ読み取り、ビルドアーティファクトへのアクセスといった権限・到達範囲を持ちやすいです。その実行主体が改ざんされると、情報窃取のコストが一気に下がります。ここを「最小権限・最小到達範囲」に再設計できているかが分水嶺です。
• 供給網の“タグ主義”が招く脆弱性です。タグpullの利便性が、攻撃者にとっての“更新で一斉配布”という兵器化ポイントになります。Digest固定と署名検証は、単なる推奨ではなく“無効化しにくい摩擦”です。摩擦のない利便は、攻撃者の利便でもあります。
• “スキャナのネットワーク要件”の誤解です。脆弱性DB更新や外部レジストリへのアクセスなど、スキャナは外向き通信が必要になりがちです。だからこそ、出口の宛先制限（レジストリ/DBミラーのみ許可）とプロトコル制限で、二次ステージの取得を阻みやすくなります。多くの現場でここの制御が甘く、被害の拡張を許しがちです。
• 多段拡散の設計思想です。報道にあるnpmワーム化は「開発者→依存管理→CI/CD→本番」のベルトコンベアを逆用する発想です。1点の侵入が、多層の“自動化”により指数関数的に拡張します。自動化は善ですが、“自動化の境界”を設けることが守りの鍵です。

メトリクスから総合すると、即時性と実運用への関与度が高い一方、目新しさより“既存の弱点の合わせ技”という色合いが強いと見ます。裏を返せば、基本動作（署名検証・ダイジェスト固定・ネットワーク制御・権限最小化）を実直に積むことで、被害の分岐点を複数用意できる類型です。

脅威シナリオと影響

以下は現時点の公開報道に基づいた仮説シナリオです。詳細は一次情報の更新に応じて見直すべき前提で提示します。

• シナリオA（開発者端末）

  • きっかけ: 開発者がDockerでTrivy改ざんイメージを実行。
  • 動作: エントリポイントやラッパースクリプトが二段目のペイロードを取得し、ブラウザセッション、SSH鍵、クラウドCLI資格情報、GitHub/GitLabトークン、npmトークン等を窃取（仮説）。
  • 影響: 個人トークンを悪用したリポジトリ改ざん、社内npmレジストリへの汚染、他端末への拡散。

• シナリオB（CI/CDランナー）

  • きっかけ: パイプラインでTrivyをDocker経由で実行（タグ指定）。
  • 動作: ランナー環境変数やマウントしたワークスペースからシークレット抽出、組織PATやデプロイトークン流出、npmパブリッシュの悪用（仮説）。
  • 影響: ビルドチェーン改ざん、成果物のバックドア化、内部レジストリの汚染で下流環境に連鎖。

• シナリオC（Kubernetesクラスタ）

  • きっかけ: 流出したクラウド/クラスター資格情報を用いた侵入、もしくはクラスタ内ジョブでTrivyを実行。
  • 動作: クラスタ内のリソース列挙と削除、データ破壊・ワイパー動作（報道あり）。バックアップ/スナップショットがなければ復旧困難。
  • 影響: サービス停止、SLO違反、事業継続に直結。

MITRE ATT&CK（仮説マッピング）

• 初期侵入: Supply Chain Compromise（T1195）、特にソフトウェア供給網の改ざん（T1195.002）と依存/開発ツールの妥協（T1195.001）。
• 実行: Command and Scripting Interpreter（T1059）、悪性コンテナ内スクリプト実行。
• 認証情報アクセス: Credentials from Web Browsers（T1555.003）、Unsecured Credentials（T1552）、Cloud Credentials（T1552.004相当の文脈）。
• 発見: Query Registry（T1012）やSystem Information Discovery（T1082）に準ずる環境探索。
• 横展開: Valid Accounts（T1078）、External Remote Services（T1133）。
• 防御回避: Obfuscated/Compressed Files and Information（T1027）、Signed Binary Proxy Execution（T1218）に近い“信頼されたツール悪用”の様相。
• 影響（破壊）: Data Destruction（T1485）、Resource Hijacking（T1496は目的次第で可能性）、Service Stop（T1489）等。

事業影響の観点では、機密流出（知財・顧客情報）、供給網汚染による下流顧客への責任、クラスタ停止による直接損失、復旧に伴う体制疲弊と信用低下が主要リスクです。スキャナは多くのパイプラインで“共通モジュール”ゆえ、露出人口が多い点が厄介です。

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

優先度順で、実務に落としやすい手順に絞ります。

• 影響確認と初動

  • 自社・委託先のCI/CD、開発端末、運用ジョブで“Docker版Trivy”の利用有無を棚卸しします。特に報道で言及されたタグ（0.69.4〜0.69.6）をpullした記録の有無を、Docker pullログ、レジストリプロキシ、CIログで確認します。
  • ヒットした環境は、侵害前提で資格情報の一斉ローテーション（GitHub/GitLabトークン、クラウドIAMキー、SSH鍵、npmトークン等）を即時実施します。端末は再イメージ化、CIランナーは使い捨て再構築を基本線にします。
  • ネットワーク観点で、ビルド/スキャン時の外向き通信ログから未知ドメインへの接続有無を確認し、該当通信の封じ込めとフォレンジック保存を行います。

• 運用ガードレール（恒久対策）

  • 署名検証とダイジェスト固定: すべてのサードパーティOCIイメージはタグ参照を禁止し、ダイジェスト固定を義務化します。署名検証（組織内の信頼ポリシーに沿ったベリファイ）を事前ジョブで強制します。
  • レジストリ戦略: パブリックからの直接pullをやめ、社内ミラー/キャッシュ経由に統一します。許可リポジトリのallowlistをAdmission Controllerで適用します。
  • スキャナ分離: スキャナ専用ネットワークセグメントを設け、外向きは脆弱性DBミラーや社内レジストリ等の限定宛先のみ許可します。スキャナのマウント権限とランナー権限も最小化し、長期資格情報は原則持たせません。
  • CIシークレット管理: OIDCによる短命トークンに置き換え、PATや長寿命デプロイトークンを廃止します。npm publish等の高リスク操作は別パイプラインに分離し、手動承認とSAST/署名付きアーティファクトをゲートにします。
  • ポリシー適用: OPA/GatekeeperやKyvernoで、署名未検証イメージのデプロイ拒否、タグ参照の拒否、未承認レジストリの拒否を強制します。

• 検知とハンティング

  • CI/CD: スキャンジョブ直後に発生した異常なgit操作、レジストリへの突発的なパブリッシュ、外向きHTTP(S)への多量接続を時系列で洗います。
  • 端末: ブラウザプロファイル、npm/ssh資格情報ストアへのアクセス痕跡、未知バイナリの常駐化を確認します。
  • Kubernetes: 連続的なdelete操作、cluster-admin権限での一括操作、普段使わないNamespace/CRDへのアクセスを監査ログで可視化します。etcdスナップショットとアプリバックアップの健全性も点検します。

• 組織的対応

  • 依存ソフト棚卸しの“継続運用化”です。SBOMを基盤に、CIテンプレートやDevContainer、社内ツールチェーンに含まれるスキャナ類のバージョンと取得元を常時可視化します。
  • サプライヤー/委託先のCI/CD要件に、署名検証・ダイジェスト固定・レジストリミラーの遵守を明文化します。
  • インシデント訓練では「スキャナ乗っ取り」を新たなシナリオに加え、資格情報ローテーションとレジストリ封鎖、バックアップからのクラスター復旧までを通しで演習します。

最後に、今回の事案は“安全のための道具が攻撃の踏み台になり得る”という痛い真実を示しました。けれど、私たちには選べる摩擦があり、積める分岐点があります。便利さと安全さの間に、適切な抵抗を設計していきたいです。

参考情報

• Trivy Hack Spreads Infostealer via Docker; NPM Worm; Kubernetes Wiper（The Hacker News）