【脆弱性レポート】Trivy侵害にみるサプライチェーン攻撃の実態

この記事をシェア

2026年3月中頃～4月初頭、大手企業をはじめとした複数の企業で、内部開発環境に関する情報がリークされた可能性があるとする報道が相次ぎました。
今回の騒動の原因は、Trivy を悪用したサプライチェーン攻撃と広く指摘されています。

Trivy は多くの企業で CI/CD パイプラインに組み込まれているため、理論的には非常に多くの組織が影響を受ける可能性があります。
しかし、現時点で実際に被害が確認されているのは、一部の大手組織や公共機関に限られます。

そこで本記事では、自組織が影響を受ける可能性や、適切な対策が取られているかを確認するために、今回の Trivy で何が起きたのかを解説します。

背景
Trivy の配布経路が改ざんされ、大手企業の内部開発環境で認証情報が流出する可能性が指摘された出来事の経緯を解説。
仕組み・影響
CI/CD パイプラインで Trivy がどのように利用され、タグの改ざんでどのような影響が発生したかを解説。
防御・対策
同様のサプライチェーン攻撃に対する防御策や緩和策の考え方を紹介。
まとめ
「公式ツールだから安全」という前提が崩れることによる外部コードを信頼する開発モデルのリスクを整理し、組織として意識すべきポイントをまとめる。

1. 大手企業の開発環境への侵害と Trivy サプライチェーン攻撃
2. サプライチェーン攻撃の仕組みと影響
2-1. Trivy と CI/CD での動き
2-2. タグに紐づけされたコードが書き換えられた ― “昨日の v0.20.0” と “今日の v0.20.0” の違い
2-3. なぜタグに紐づけされたコードが書き換えられたのか？
2-4. 悪意ある Trivy を実行すると何が起きる？
3. サプライチェーン攻撃への防御と対策
3-1. このようなサプライチェーン攻撃は防げたのか？
3-2. 被害を最小化する緩和策：5つの対策
4. まとめ：今回の出来事が示したもの

1. 大手企業の開発環境への侵害と Trivy サプライチェーン攻撃

2026年3月中頃～4月初頭、世界的に広く使われる OSS 脆弱性スキャナ Trivy に対して大規模なサプライチェーン攻撃が発生しました。
攻撃者は Trivy の公式配布物や GitHub リリースを改ざんし、CI/CD パイプライン上で動作するコードに認証情報窃取の仕掛けを組み込んだとされています。

この Trivy 侵害による認証情報の窃取を起点に、ある大手企業においても内部環境への不正アクセスが報じられました。

複数の報道によると、今回のサプライチェーン攻撃で窃取された認証情報を悪用し、対象企業の内部開発環境への不正アクセスと情報窃取が行われた可能性が指摘されています。
これにはソースコードやクラウド環境に関連する認証キーが含まれるとの報道もあり広く注目されました。

具体的には以下のような情報が外部に流出した可能性があります：

内部開発リポジトリへのアクセス
ソースコードの窃取
AWS などクラウド認証情報の漏えい
顧客データを含む可能性のある情報へのアクセス

※企業側は一部内容について正式な確認をしていない、調査中との声明も出しています。

今回の攻撃の本質は、「セキュリティツールそのものを攻撃対象とするサプライチェーン侵害」であり、単純な脆弱性やミスではなく、信頼していた開発プロセスが侵害されたことにあります。
こうした攻撃は、ツールやライブラリを利用する側が意図しない形で悪意あるコードを取り込んでしまうおそれがあるため、従来の脆弱性管理や境界防御だけでは防ぎにくいという課題があります。

つまり、このようなリスクは特定の大手企業だけの問題ではなく、自社の開発環境においても十分に起こりうる事例です。
次節では、Trivy がどのように悪用されたのか、CI/CD における信頼の前提がどこで崩れたのかを具体的に整理していきます。

2. サプライチェーン攻撃の仕組みと影響

2-1. Trivy と CI/CD での動き

Trivy は Aqua Security 社が提供する脆弱性スキャナで、特に CI/CD パイプラインで自動的に脆弱性をチェックするツールとして利用されます。

ソフトウェア開発では、push や pull request のイベントをきっかけに、テストやビルドなどの一連の自動処理（ワークフロー）が実行されます。
このワークフローには脆弱性スキャンのステップが含まれ、PR 作成時やデプロイ前に Trivy が呼び出されます。

多くの場合、Trivy は GitHub Actions などの自動化ツールと連携して利用されます。
GitHub Actions は「コードの変更をきっかけに自動処理を実行する仕組み」で、例えば次の処理を自動化できます。

push したらテスト
PR を作成したらビルド
デプロイ前にセキュリティチェック

これらは YAML ファイルで“何を実行するか”を宣言的に定義することで、CI/CD に組み込まれます。

GitHub Actions の設定例

name: security-scan

on: [push, pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run Trivy
        uses: aquasecurity/trivy-action@v0.20.0
        with:
          image-ref: my-app:latest

重要なのはこの1行