セキュリティツール「Trivy」が2度ハッキングされた―守る側のツールが破られたらどうすればいいのか

Trivyとは何か ― 守る側のツールが狙われた

Trivyは、Aqua Security（イスラエルのセキュリティ企業）が開発するオープンソースのセキュリティスキャナーです。GitHubで32,000以上のスターを持ち、年間1億回以上ダウンロードされています。ソフトウェアの脆弱性を検出するツール、つまり「守る側の道具」です。

そのTrivyが、2026年2月下旬から3月にかけて、3週間で2度ハッキングされました。

1回目の攻撃者は、AIが自律的に動くエージェントでした。2回目は「TeamPCP」と名乗る人間の攻撃者グループ。いずれもGitHub Actions（GitHubの自動実行機能）の構造的な弱点を突いています。

1回目の侵害で何が起きたか ― AIが自律的にリポジトリを乗っ取った

2026年2月20日、GitHubに「hackerbot-claw」というアカウントが作成されました。プロフィールには「autonomous security research agent powered by claude-opus-4-5」と書かれていました。Claude Opus 4.5（Anthropic社の大規模言語モデル）を使ったAI自律エージェントです。

このAIは、GitHubの7つのオープンソースリポジトリに対して、それぞれ異なる手口で攻撃を仕掛けました。Trivyに対しては、2月27日にプルリクエスト（コード変更の提案）を作成し、即座にクローズしました。

普通なら何も起きません。しかしTrivyのGitHub Actionsには「pull_request_target」という設定がありました。これはプルリクエストが作られたときに自動で実行されるワークフローで、プルリクエストがクローズされても実行されるという特性があります。しかもリポジトリの管理者権限で動く。

AIはこの仕組みを利用して、Trivyリポジトリの管理用トークン（PAT）を外部サーバーに送信。翌日にはリポジトリの完全な制御権を奪取しました。全178リリースを削除し、リポジトリを非公開化。さらに悪意あるVSCode拡張機能まで公開しました。

興味深い副産物があります。hackerbot-clawが攻撃した7つのリポジトリのうち1つでは、別のAI（Claude sonnet-4-6）が攻撃を検知してブロックしています。AI対AIの防御が機能した初めての事例とされています。

なぜ2度目が起きたのか ― トークンの無効化が不完全だった

Aqua Securityは1回目の攻撃を受けて復旧作業を行いました。脆弱なワークフローを削除し、トークンを無効化し、安全なバージョン（v0.69.2）をリリース。ここまでは教科書通りです。

しかし、トークンの無効化が不完全でした。

StepSecurityの分析によると、1回目で窃取された「aqua-bot」サービスアカウントのトークンが攻撃者の手元に残っていました。トークンのローテーション（更新）プロセスが一度に完結せず、更新後のトークンも攻撃者に露出した可能性があります。

2026年3月19日、「TeamPCP」と名乗る攻撃者がこのトークンを使い、悪意あるv0.69.4タグをプッシュ。自動リリースパイプラインが起動し、GitHub Releases、Docker Hub、Amazon ECRに悪意あるバイナリが配布されました。

GitHub Actionsが攻撃の入口になった ― 何が盗まれたのか

2回目の攻撃で配布された悪意あるバイナリの中身を、CrowdStrikeが詳細に分析しています。攻撃は5段階で構成されていました。

第1段階: GitHub Actionsのランナー（自動実行環境）上で動いているプロセスを列挙し、環境変数からクレデンシャル（認証情報）を抽出。

第2段階: プラットフォームに応じて収集対象を変えます。GitHubが提供するランナーでは、メモリをダンプしてシークレット（秘密情報）を抜き出す。企業が自前で用意したランナーでは、SSH鍵、AWS/GCP/Azureの認証情報、Kubernetes設定、Dockerの設定、暗号通貨ウォレットまで、50種類以上の機密ファイルをスキャンします。

第3段階: 収集したデータをAES-256で暗号化。復号鍵は攻撃者の公開鍵でラップされているため、攻撃者以外は中身を見られません。

第4段階: 暗号化データを2つの経路で外部に送信。主経路は「scan.aquasecurtiy[.]org」（Aqua Securityのドメインに似せたタイポスクワット）。フォールバック経路として、被害者のGitHubアカウントに「tpcp-docs」という公開リポジトリを勝手に作り、そこにデータをアップロードします。

第5段階: 痕跡を消した後、正規のTrivyスキャンを実行して正常な出力を表示。開発者は何も異常に気づきません。

3週間で何が起きたか ― 時系列で振り返る

← スワイプで移動

自分のプロジェクトが影響を受けたか確認する方法

以下の手順で確認できます。

• 1. Trivyのバージョン確認: trivy --version を実行し、v0.69.4が表示されたら影響あり。v0.69.3以前またはv0.69.5以降なら安全です
• 2. GitHub Actionsのワークフロー監査: aquasecurity/trivy-actionまたはaquasecurity/setup-trivyをバージョンタグで参照していた場合、3月19〜20日のワークフロー実行ログを確認
• 3. StepSecurityの検出ツール: trivy-compromise-scannerで影響を受けたワークフロー実行を自動検出
• 4. 不審なリポジトリの確認: 自組織のGitHubアカウントに「tpcp-docs」という見覚えのないリポジトリがないか確認（フォールバック窃取経路の痕跡）
• 5. ネットワークログ: scan.aquasecurtiy[.]org（45.148.10.212）への通信がないか確認

Aqua Securityの公式インシデント報告によると、安全なバージョンはTrivy v0.69.3、trivy-action v0.35.0、setup-trivy v0.2.6です。

守る側のツールが破られたらどうすればいいのか

セキュリティベンダー各社（CrowdStrike、Wiz、StepSecurity）の分析から、共通する教訓が3つあります。

• ▸ GitHub Actionsはコミットハッシュ（SHA）で固定する。バージョンタグ（v1, v2.3.4等）は書き換え可能です。uses: aquasecurity/trivy-action@abcdef1234567890のようにSHA指定にすれば、タグが書き換えられても影響を受けません
• ▸ pull_request_targetワークフローを監査する。外部からのプルリクエストがリポジトリの管理者権限でコードを実行できる状態は、そのまま攻撃の入口になります
• ▸ インシデント対応ではトークンの完全な無効化を検証する。Trivyの2度目の侵害は、1度目の後始末が不完全だったことが原因です。トークンのローテーションは「更新した」ではなく「旧トークンが使えないことを確認した」まで含める必要があります

映画『エイリアン2』で、リプリーが言います。「今度は核弾頭を持って行きましょう」。1回目の失敗から学んで万全の対策を取ったはずが、想定外の経路から再び侵入を許す。Trivyの事件はまさにそれです。

セキュリティツール自体がサプライチェーン攻撃の対象になるという現実は、「何を信頼するか」の前提を問い直します。ツールを信頼するのではなく、ツールが侵害されたときに何が起きるかを想定する。その想定力が、次の攻撃との差を分けます。

参照元

• ▸ Aqua Security 公式インシデント報告（2026年3月19日）
• ▸ CrowdStrike「From Scanner to Stealer: Inside the Trivy Action Supply Chain Compromise」（2026年3月20日）
• ▸ Wiz「Trivy Compromised by TeamPCP」（2026年3月）
• ▸ StepSecurity「Trivy Compromised a Second Time」（2026年3月20日）
• ▸ StepSecurity「hackerbot-claw GitHub Actions Exploitation」（2026年3月）
• ▸ Socket.dev「Trivy Under Attack Again」（2026年3月）
• ▸ やっていく気持ち「Trivy再侵害の概要と対応指針」（2026年3月）
• ▸ StepSecurity trivy-compromise-scanner（影響確認ツール）