はじめに
本記事は、Trivy 公式ツールの侵害から始まった一連のサプライチェーン攻撃に関する第 3 弾の解説記事です。事件の発端および npm エコシステムへの波及については、以下の関連記事をご参照ください。
Trivy 関連のサプライチェーン攻撃は、機密情報の窃取にとどまらず、ついに Docker Hub への悪意あるイメージの混入や、Kubernetes（K8s）クラスターを破壊するワイパー（Wiper）攻撃へと被害を拡大させています。
参考: Trivy Hack Spreads Infostealer via Docker, Triggers Worm and Kubernetes Wiper
“Cybersecurity researchers have uncovered malicious artifacts distributed via Docker Hub following the Trivy supply chain attack, highlighting the widening blast radius across developer environments.”
（サイバーセキュリティの研究者は、Trivy のサプライチェーン攻撃に続いて Docker Hub 経由で配布された悪意のあるアーティファクトを発見し、開発者環境全体に及ぶ被害範囲の拡大を強調しています。）
https://thehackernews.com/2026/03/trivy-hack-spreads-infostealer-via.html
本記事では、被害がコンテナインフラそのものへ及んだ最新の手口を技術的に紐解き、システム管理者や SRE が直ちに実践すべきコンテナ環境のセキュリティ設定と多層防御のアプローチについて解説します。
- Docker Hub および開発元内部リポジトリに対する侵害の全容
- 露出した Docker API と Kubernetes を狙うワイパー攻撃の挙動
- Trivy バージョンの確認と Kubernetes の RBAC 最小化手順
- FortiGate 等を活用したネットワークレベルでの多層防御策
攻撃の全容と被害の拡大（Docker Hub と内部リポジトリ侵害）
GitHub Actions のタグポイズニングを起点とした攻撃は、窃取された認証情報を悪用することで、コンテナ開発の基盤となるプラットフォームへ直接的な被害をもたらしました。
Docker Hub への悪意あるイメージ（タグ 0.69.5 / 0.69.6）の混入
公式の Docker Hub における Trivy の最後のクリーンなリリースは、バージョン 0.69.3 です。しかし 2026 年 3 月 22 日、対応する GitHub リリースが存在しないにもかかわらず、悪意のあるイメージタグ 0.69.5 および 0.69.6 が Docker Hub にプッシュされました。
これらのイメージには、以前の攻撃段階で確認されたものと同じ TeamPCP のインフォスティーラー（情報窃取マルウェア）が含まれており、開発者が誤って最新タグを取得（docker pull）するのを待ち構えるトラップとして機能していました。
奪取されたボットアカウントによる Aqua Security 内部リポジトリの暴露
さらに脅威アクター（TeamPCP）は、Aqua Security の内部コードをホストする GitHub 組織（aquasec-com）に侵入し、44 個すべての内部リポジトリを改ざん（デフェイス）して一般公開する暴挙に出ました。これにより、Tracee のソースコードや内部の CI/CD パイプライン構成などが流出しました。
この壊滅的な被害の根本原因は、過去のインシデントで窃取された単一のサービスアカウント（Argon-DevOps-Mgt）のトークンにあります。
参考: Trivy Hack Spreads Infostealer via Docker, Triggers Worm and Kubernetes Wiper
“The Argon-DevOps-Mgt service account — a single bot account bridging two orgs with a long-lived PAT — was the weak link.” （Argon-DevOps-Mgt サービスアカウント
（長期有効な PAT を持ち、2 つの組織を橋渡しする単一のボットアカウント）が弱点でした。）
https://thehackernews.com/2026/03/trivy-hack-spreads-infostealer-via.html
長期間有効な Personal Access Token（PAT）を持ったボットアカウントが、公開用と内部用の両方の組織に対して過剰な権限（書き込み・管理者アクセス）を持っていたことが、被害を劇的に拡大させる「最弱の環」となりました。
Kubernetes 環境を狙う破壊的マルウェア（ワイパー）の挙動
脅威アクターは、情報の窃取にとどまらず、クラウドインフラそのものを破壊するワイパー（Wiper）マルウェアを展開する能力を獲得しています。
露出した Docker API（ポート 2375）と SSH キーの悪用
TeamPCP は、ローカルサブネット内で保護されずにインターネットや内部ネットワークへ露出している Docker API（ポート 2375）を探索し、悪用します。さらに、窃取した SSH キーを用いてネットワーク内を横展開（ラテラルムーブメント）し、次々とコンテナホストを侵害していきます。
特権 DaemonSet によるクラスターの破壊とワーム感染の分岐
Kubernetes（K8s）クラスターに到達した新たなペイロードは、コントロールプレーンを含むすべてのノードに特権コンテナとして DaemonSet を展開します。
参考: Trivy Hack Spreads Infostealer via Docker, Triggers Worm and Kubernetes Wiper
“Iranian nodes get wiped and force-rebooted via a container named ‘kamikaze.’ Non-Iranian nodes get the CanisterWorm backdoor installed as a systemd service. Non-K8s Iranian hosts get ‘rm -rf / –no-preserve-root.'” （イランのノードは「kamikaze」という名前のコンテナを介してワイプされ、強制再起動されます。イラン以外のノードには、CanisterWorm のバックドアが systemd サービスとしてインストールされます。K8s 以外のイランのホストは「rm -rf / –no-preserve-root」を実行されます。）
https://thehackernews.com/2026/03/trivy-hack-spreads-infostealer-via.html
このスクリプトは、CanisterWorm と同じ ICP カニスターを利用してシステムを識別し、特定の地域（今回はイラン）のシステムであればデータを完全に消去して強制再起動させる破壊的（kamikaze）な動作を行います。それ以外のノードに対しては、永続的なバックドアとして CanisterWorm を密かに展開し、さらなる感染拡大の踏み台として利用します。
コンテナ環境を守るための具体的な実践手順
このような高度なサプライチェーン攻撃と破壊的マルウェアから自社のインフラを守るためには、CI/CD から実行基盤に至るまでの各フェーズで厳格な統制が必要です。
影響を受ける Trivy バージョンの排除とコンテナイメージの署名検証
まずは直近のパイプライン実行履歴を監査し、侵害されたバージョン（0.69.4、0.69.5、0.69.6）が使用されていないか確認することが急務です。
これをシステム的に防ぐためには、Cosign などのツールを活用してコンテナイメージの暗号署名を検証し、信頼できるメンテナーから正式にリリースされたイメージ（タグ）のみを pull して実行する仕組みを CI/CD パイプラインに組み込むことが必須となります。
Kubernetes における RBAC の最小化と Pod Security Standards の適用
今回のワイパー攻撃は、クラスター全体に特権（Privileged）を持った DaemonSet を展開することで成立しています。
この種の攻撃を無効化するためには、Kubernetes の RBAC（ロールベースアクセス制御）を見直し、サービスアカウントに対してクラスター全体への権限（ClusterRoleAdmin など）を過剰に付与しないことが大前提です。さらに、Pod Security Standards（PSS）や OPA Gatekeeper 等のポリシーエンジンを導入し、特権コンテナの起動やホストファイルシステムへのマウントを強制的にブロックする設定を適用することで、万が一ノードに侵入されても破壊活動を未然に防ぐことができます。
FortiGate 等を活用したネットワークレベルの多層防御
Kubernetes や Docker ホスト上の設定ミス（API の露出など）は、ネットワーク境界での多層防御を組み合わせることで、被害のリスクを大幅に軽減できます。
API エンドポイントの露出制限と C2 サーバーへの通信遮断
コンテナ環境を標的とする攻撃の多くは、管理用ポートの無防備な公開から始まります。
FortiGate（NGFW）などのファイアウォールを用いて、インターネットや信頼できないネットワークからの Docker API（ポート 2375 や 2376）および Kubelet API へのアクセスを厳格に遮断することが不可欠です。また、Web フィルタリングや DNS フィルタリング機能を活用し、判明している脅威アクターの C2 サーバー（ICP カニスターの URL や関連ドメイン）へのアウトバウンド通信をネットワークレベルでブロックすることで、マルウェアの活動やデータの持ち出しを物理的に封じ込めることができます。
ネットワークポリシーによる横展開（ラテラルムーブメント）の防止
内部ネットワークに侵入された後の被害拡大を防ぐため、ゼロトラストの原則に基づいたマイクロセグメンテーションが有効です。
FortiGate の内部セグメンテーションファイアウォール（ISFW）機能や Kubernetes の NetworkPolicy を組み合わせ、コンテナノード間の不要な SSH 通信（ポート 22）や API 通信をデフォルトで拒否（Deny All）し、必要なトラフィックのみを許可する設計を実装することで、ワイパー等の横展開（ラテラルムーブメント）をシステムレベルで阻止します。
まとめ
本記事では、Trivy 関連のサプライチェーン攻撃から波及した Docker Hub へのマルウェア混入と、Kubernetes クラスターを破壊するワイパーの脅威について解説しました。
- Trivy（脆弱性スキャナー）の権限漏洩が、Docker Hub へのマルウェア混入や内部ソースコードの暴露に発展した。
- マルウェアは露出した Docker API や SSH を悪用し、特権コンテナを利用してクラスターを破壊（ワイプ）する。
- 防御策として、コンテナイメージの署名検証や Kubernetes の RBAC 最小化、Pod Security Standards（PSS）の適用が不可欠である。
- FortiGate 等を用いたポート 2375 の遮断や C2 サーバーへの通信制御により、ネットワークレベルの多層防御を実装する。
以上、最後までお読みいただきありがとうございました。
