Trivyのサプライチェーン侵害（2026年3月）：CIでTrivyを使っている人がやること

Aquaは、2026年3月19〜20日のワークフローの実行記録を確認するよう求めています。アドバイザリが示す時間帯（UTC、カッコ内は日本時間）は次のとおりです。

• trivy-action：3月19日17:43ごろ〜3月20日5:40ごろ（3月20日2:43〜14:40）
• setup-trivy：3月19日17:43ごろ〜21:44ごろ（3月20日2:43〜6:44）
• Trivy v0.69.4：3月19日18:22〜21:42ごろ（3月20日3:22〜6:42）
• Docker Hubのイメージv0.69.5・v0.69.6：3月22日15:43〜3月23日1:40ごろ（3月23日0:43〜10:40）

GitHubの組織全体でワークフローが多い場合は、aquasecurity/trivy-action と aquasecurity/setup-trivy を参照しているワークフローを検索し、その実行履歴を時間帯で絞ります。

アドバイザリの判定は、版の番号より「どう参照していたか」で決まります。

• trivy-action：影響あり＝0.35.0以外のタグ（0.0.1〜0.34.2）で参照／時間帯に version: latest を明示していた／2025年4月9日より前のコミットにSHAで固定していた。影響なし＝0.35.0のタグ／2025年4月9日以降の安全なコミットへのSHA固定。
• setup-trivy：影響あり＝SHAで固定していなかった場合すべて。影響なし＝安全なコミットへのSHA固定。
• Trivy本体：影響あり＝v0.69.4（期間中の latest を含む。GitHub、deb、rpm、get.trivy.dev、GHCR、ECR Public、Docker Hub）とDocker Hubのv0.69.5・v0.69.6。影響なし＝v0.69.3以前／ダイジェスト（イメージの中身から計算した固有の値）で指定したイメージ／ソースからのビルド／Homebrewの公式フォーミュラ。

Aquaは、該当する版が動いた可能性が少しでもあるなら、そのパイプラインから読めた秘密情報をすべて漏れたものとして扱うよう求めています。対象は、クラウド（AWS、GCP、Azure）の認証情報、Gitの認証情報、コンテナレジストリの認証情報、SSH鍵、Kubernetesのトークン、環境変数などの自動化用の秘密です。

npmの公開用トークンは「実際に悪用されているもの」として扱うよう求めており、盗まれたトークンがnpmでの不正な拡散に使われているとしています。自分で管理するランナー（セルフホスト）の場合は、ランナーの上に置かれていたデータベースの認証情報、TLSの秘密鍵、VPNの設定なども対象として挙げられています。

これはTrivy自身の原因から引き出した手順です。Aquaによれば、3月1日のローテーションは一斉に行われず、数日にわたる入れ替えの間に、有効なままのトークンで新しい秘密まで持ち出された可能性があります。

対象の秘密を洗い出したら、まず古い鍵をまとめて無効化し、そのあとで新しい鍵を発行します。1本ずつ入れ替えると、まだ有効な古い鍵で、新しく入れた鍵を読まれる余地が残ります。サービスが一時止まる代償は、短い時間の停止として計画に入れてください。

Aquaは、持ち出しの代わりの経路が使われた場合に組織のGitHubアカウントに作られるリポジトリと、CIの外（開発者の端末など）でv0.69.4を動かした場合に端末に残るファイルを、確認項目として公表しています。該当する人は、下の出典にあるAquaの発表とアドバイザリの確認項目に沿って点検してください（本記事では痕跡の値は転載しません）。

Aquaが示す安全な版は、Trivy v0.69.2・v0.69.3、trivy-action v0.35.0、setup-trivy v0.2.6です。

アドバイザリによれば、trivy-actionの古いタグ（0.0.1〜0.34.2）は削除され、同じ名前では作り直せないため、頭に v を付けたタグ（例：v0.34.0）で元の正規のコミットを指すように公開し直されています（一部のタグは未復元）。古い版を使い続けている場合は参照を書き換える必要があります。

アドバイザリによれば、trivy-actionは2025年4月9日のプルリクエストで、中で使う部品の参照をSHA固定に変えました。それより前のコミットにtrivy-actionを固定していた人は、trivy-action自体は安全でも、その中でタグで呼ばれるsetup-trivyが不正な版になっていました。

複数の部品を組み合わせるアクション（composite action）を使っている場合は、固定したコミットの action.yml を開き、中の uses: がSHAで固定されているかを確認します。固定されていなければ、より新しいコミットに上げるか、中の部品を自分のワークフローで直接SHA固定して呼ぶ方法を検討してください。

GitHubは2025年8月、許可するアクションの方針にSHAでの固定を必須にする設定を加えました。企業・組織・リポジトリの単位で設定でき、SHAで固定していないアクションを使うワークフローは失敗します。同じ方針で、特定のアクションや版をブロックすることもできます。今回のような事案が起きたとき、該当する版を組織全体で止める手段にもなります。

アドバイザリによれば、Trivy v0.69.3とtrivy-action 0.35.0は、公開前にGitHubの「変更できないリリース（immutable releases）」を有効にしていたため書き換えを免れました。

一方でAquaは、書き換えられたタグの横にも「Immutable」の表示が出ていたとし、表示だけに頼らず、完全なコミットSHAでの固定が確実な対策だとしています。表示は、そのリリースを公開した時点の状態を示すにすぎません。

アドバイザリでは、ダイジェスト（@sha256:…）で指定したイメージは影響を受けていません。latest や版番号のタグだけで取得していると、公開期間中に不正な版を取り込みます。

Trivyのアドバイザリは、Sigstore（オープンソースの署名の仕組み）の署名と署名の時刻でバイナリやイメージを検証する手順も示しています。CIで取得するツールは、版を明示し、可能ならダイジェストかチェックサムで固定します。

Aquaによれば、不正なコードは正規のスキャンより先に動き、スキャンの結果はふだんどおりに見えたため、利用者が気づきにくいものでした。スキャンそのものに、クラウドやレジストリへの書き込み権限はふつう要りません。スキャンは、デプロイ用の秘密を渡さない別のジョブで動かし、permissions: は読み取りだけにします。

Aquaによれば、代わりの持ち出し経路は個人のアクセストークン（PAT）がワークフローに渡されている場合にだけ働き、既定の GITHUB_TOKEN では失敗するものでした。スキャンのステップに個人のトークンを渡していないかも確認してください。