コンテナ脆弱性スキャンにTrivyが選ばれる理由｜GrypeやClairとの違い

コンテナや Kubernetes を本番で運用するようになると、「このイメージに既知の脆弱性が含まれていないか」「IaC の設定にセキュリティ上の穴がないか」を継続的に確認する仕組みが必要になります。とはいえ、いざセキュリティスキャナを導入しようとすると、Trivy・Grype・Clair など似たような OSS が並んでいて、どれを選べばよいのか判断がつかない、という方も多いのではないでしょうか。

特に、社内にセキュリティ専任がいない開発チームでは、「導入が重くないか」「既存の CI/CD に組み込めるか」「メンテナンスが続いているプロジェクトか」といった現実的な観点で比較したいのに、機能の一覧だけ並べられても採用判断には結びつきにくいものです。

本記事では、Aqua Security 社が開発する OSS スキャナ Trivy を題材に、何をスキャンできるツールなのか、基本的な使い方、CI/CD への組み込みやすさを整理したうえで、類似ツールである Grype・Clair との違いを比較します。最終的に「自分のプロジェクトに Trivy が向いているか」を自分で判断できるよう、選定の判断軸を提示することを目的としています。

なお本記事は実際の動作検証を行わず、公式 README・公式ドキュメント・公式サイトに記載された情報をもとに整理しています。コマンド例はいずれも公式の記載からの引用です。

Trivyとは何か｜コンテナ脆弱性スキャンを担うOSS

Trivy（トリビー）は、Aqua Security 社が開発・保守する OSS のセキュリティスキャナです。公式では「The All-in-One Security Scanner（オールインワン・セキュリティスキャナ）」と表現されており、コンテナイメージや Kubernetes、コードリポジトリ、クラウドなどに含まれる脆弱性・設定ミス・シークレット・SBOM を、1 つのツールで横断的に検出できる点が最大の特徴です（GitHub: aquasecurity/trivy）。

「コンテナ脆弱性スキャン」と聞くと既知の脆弱性（CVE）の検出だけを思い浮かべがちですが、Trivy はそれにとどまらず、IaC（Infrastructure as Code）の設定ミスや、ソースコードに紛れ込んだ API キー等のシークレットまでカバーします。複数のセキュリティ課題を 1 つのツールでまとめて扱える点が、後述する類似ツールとの大きな違いになります。

初見のエンジニアが採用を検討するうえで気になるのは、「そのプロジェクトが信頼でき、継続的にメンテナンスされているか」という点でしょう。Trivy の基本情報を整理すると次のようになります。

スター数は 36,000 を超えており、コンテナセキュリティ領域の OSS としては大規模なコミュニティを持っています。リポジトリは公開状態でアーカイブもフォークもされておらず（archived=false / fork=false）、最終更新も直近の日付であることから、現役で活発に開発が続いているプロジェクトであることが確認できます。ライセンスは商用利用しやすい Apache-2.0 です。

ただし、メンテナンス状況の健全性を判断するうえで、必ず把握しておきたい過去の重大インシデントが 1 件あります。2026 年 3 月、Trivy のエコシステム（GitHub Actions 連携の trivy-action / setup-trivy、および一部の配布バイナリ・Docker イメージ）が一時的にサプライチェーン攻撃を受け、認証情報を窃取するマルウェアが混入する事件が発生しました（CVE-2026-33634）。これは Trivy のスキャンが動く CI/CD パイプライン上でクラウドトークンや CI/CD のシークレットを盗み出すもので、CISA（米国サイバーセキュリティ・インフラセキュリティ庁）の KEV（既知の悪用された脆弱性）カタログにも登録された深刻なインシデントです（Aqua Security 公式アドバイザリ GHSA-69fq-xp46-6x23、Help Net Security）。

このインシデントはすでに復旧済みで、悪意のある成果物は各配布チャネルから削除されています。公式アドバイザリによれば、安全なバージョンは Trivy バイナリが v0.69.3 以前（攻撃を受けたのは v0.69.4 以降）、trivy-action が v0.35.0、setup-trivy が v0.2.6 とされています。攻撃の主な標的は GitHub Actions 連携部分であり、Trivy 本体（CLI ツール）の機能そのものに恒久的な欠陥が見つかったわけではありません。したがって、Trivy 自体は現在も健全に保守されているプロジェクトと判断できますが、後述するように CI/CD に組み込んで使う場合は、公式アドバイザリの確認とバージョンの固定が前提になる、という点は押さえておきましょう。

プロジェクトの最新情報や利用例は公式サイト（trivy.dev）にもまとまっており、採用検討の出発点として参照できます。

Trivyのスキャン対象とスキャナーの全体像

Trivy を理解するうえで押さえておきたいのが、「ターゲット（何をスキャンするか）」と「スキャナー（何を見つけるか）」という 2 つの軸で設計されている点です。この 2 軸の組み合わせで、Trivy が自分のプロジェクトの対象範囲をカバーできるかを照合できます。

スキャン対象（ターゲット）— 何をスキャンできるか

Trivy がスキャンできる主なターゲットは次のとおりです。

• コンテナイメージ
• ファイルシステム / Rootfs
• リモートの Git リポジトリ
• 仮想マシンイメージ
• Kubernetes クラスタ
• SBOM ファイル
• クラウド環境（AWS など）

コンテナイメージだけでなく、ローカルのファイルシステムや稼働中の Kubernetes クラスタ、さらにはクラウド環境まで同じツールで検査できます。「まずはイメージだけスキャンしたい」というケースから「クラスタ全体を対象にしたい」というケースまで、段階的に対象を広げられる構成になっています。

スキャナー — 何を検出できるか（脆弱性・誤設定・シークレット・ライセンス・SBOM）

検出できる対象（スキャナー）は次のとおりです。

• 既知の脆弱性（CVE）— OS パッケージおよび言語ごとの依存ライブラリ
• IaC の設定ミス（misconfiguration）
• 機密情報・シークレット（API キーやトークンの漏洩検出）
• ソフトウェアライセンス
• SBOM（ソフトウェア部品表）の生成

対応範囲の具体的な一覧は公式ドキュメントの Coverage ページにまとめられています（Trivy Docs: Coverage）。OS は AlmaLinux・Alpine・Amazon Linux・Debian・Ubuntu など多数に対応し、言語別パッケージも Java・Python・Node.js・Go・.NET など主要な言語を広くカバーしています。IaC は Terraform・Kubernetes・CloudFormation・Helm・Docker などに対応しています。自分のプロジェクトで使っている OS・言語・IaC が対象に含まれているかは、まずこの Coverage ページで確認するとよいでしょう。

Trivyの基本的な使い方（コマンド体系）

Trivy のコマンドは trivy <target> というシンプルな構文を基本としています。公式 README には、基本構文として次の形が示されています。

trivy <target> [--scanners <scanner1,scanner2>] <subject>

（出典: GitHub: aquasecurity/trivy README）

具体的な実行例も README に記載されています。たとえばコンテナイメージをスキャンする場合は次のように指定します。

trivy image python:3.4-alpine

（出典: GitHub: aquasecurity/trivy README）

ファイルシステムを対象に、脆弱性・シークレット・設定ミスを同時にスキャンしたい場合は、--scanners オプションで検出対象を指定できます。

trivy fs --scanners vuln,secret,misconfig myproject/

（出典: GitHub: aquasecurity/trivy README）

Kubernetes クラスタをスキャンし、結果をサマリ形式で出力する例は次のとおりです。

trivy k8s --report summary cluster

（出典: GitHub: aquasecurity/trivy README）

このように、image / fs / k8s のようにターゲットを切り替えるだけで、同じコマンド体系のまま対象を変えられるのが Trivy の使い勝手のよさです。

導入面でも、Trivy はデーモン（常駐サービス）を必要とせず、単一バイナリで動作します。Homebrew でのインストール、Docker イメージとしての実行、バイナリの直接ダウンロードなど複数の導入方法が用意されており、CLI ツールとして手軽に試し始められます。インストール方法の詳細は公式ドキュメントのインストールページにまとまっています（Trivy Docs: Installation）。常駐プロセスのセットアップが不要なため、ローカル環境でも CI 環境でも導入のハードルが低い点は、初めて脆弱性スキャナを導入するチームにとって判断材料になります。

TrivyのCI/CD・エコシステム連携

セキュリティスキャンは一度実行して終わりではなく、開発のたびに継続して回す必要があります。そのため「既存の CI/CD パイプラインや開発ワークフローに無理なく組み込めるか」は、実運用での採用可否を左右する重要な観点です。

Trivy は主要な CI/CD サービスとの連携が公式に提供されており、公式ドキュメントの Ecosystem ページには GitHub Actions・GitLab CI・CircleCI・AWS CodePipeline・Azure DevOps・Bitbucket Pipelines などとの統合が掲載されています（Trivy Docs: Ecosystem）。たとえば GitHub Actions では公式の trivy-action を使うことで、プルリクエストやプッシュのたびにイメージや IaC をスキャンするフローを比較的容易に組めます。

ここで、前述したサプライチェーン攻撃（CVE-2026-33634）との関連で注意しておきたい点があります。2026 年 3 月の攻撃で標的になったのは、まさにこの GitHub Actions 連携部分（trivy-action / setup-trivy）でした。インシデント自体は復旧済みですが、GitHub Actions に Trivy を組み込む際は、次の 2 点を実務上の前提にしておくと安全です。

• 公式アドバイザリで安全バージョンを確認する: trivy-action は v0.35.0、setup-trivy は v0.2.6 が安全なバージョンとされています（Aqua Security 公式アドバイザリ）。導入前に最新の公式アドバイザリを確認しておきましょう。
• バージョンはタグではなくコミット SHA で固定する: 今回の攻撃は、可変なバージョンタグ（mutable tags）が悪意あるコミットに force-push で書き換えられたことで成立しました。GitHub 公式も推奨しているとおり、uses: aquasecurity/trivy-action@<commit-sha> の形でコミット SHA を指定して固定すれば、タグが書き換えられても意図しないコードが実行されるリスクを抑えられます。これは Trivy に限らず、サードパーティの GitHub Actions 全般に共通するベストプラクティスです。

CLI ツールにとどまらず、Trivy はエコシステム全体が整備されている点も特徴です。Kubernetes 上で継続的にスキャンを実行する Kubernetes Operator（trivy-operator）や、エディタ上で脆弱性を確認できる VS Code 拡張なども公式に提供されています（GitHub: aquasecurity/trivy）。手元での単発スキャンから、CI への組み込み、クラスタ上での常時監視まで、段階的に運用を拡張していける土台が用意されています。

既存のパイプラインに後から組み込みやすいという点は、開発ワークフローを大きく変えずにセキュリティチェックを追加したいチームにとって、Trivy を選ぶ実務的な理由になります。導入時にバージョン管理の作法さえ押さえておけば、運用に乗せやすいツールです。

Grype・Clairとの違いと、Trivyが選ばれる理由

コンテナ脆弱性スキャンの OSS としては、Trivy のほかに Grype（anchore/grype）と Clair（quay/clair）がよく比較対象に挙がります。いずれも Apache-2.0 ライセンスの OSS ですが、カバー範囲や導入モデルに明確な違いがあります。まず全体像を表で整理します。

Grypeとの違い（カバー範囲・SBOMの分業・優先順位付け）

Grype は、コンテナイメージとファイルシステムを対象に既知の脆弱性（CVE）を検出することに特化したスキャナです。Trivy のように IaC の設定ミスやシークレット、ライセンスまでをカバーするわけではなく、検出範囲を脆弱性に絞っています。

設計面の違いとして、Grype は SBOM の生成を姉妹ツールである syft に任せ、syft が生成した SBOM を入力として脆弱性検出を行う役割分担型のアプローチを採ります。一方の Trivy は SBOM の生成自体を自身で行えます。

Grype の強みは、検出した脆弱性に対してリスクスコアを付与し、対応の優先順位付けを支援する点にあるとされています。脆弱性の検出に集中し、どれから対応すべきかの判断材料を重視したい場合には Grype が適しています。逆に、脆弱性以外の設定ミスやシークレットも 1 つのツールでまとめてカバーしたい場合は、Trivy のほうが守備範囲が広くなります。

Clairとの違い（導入モデル・大規模運用）

Clair は、コンテナイメージの脆弱性を静的解析するエンジンで、Red Hat の Quay レジストリに統合される設計が特徴です。Trivy が CLI で単発実行する軽量な導入モデルなのに対し、Clair は API サーバーとして常駐させ、コンテナレジストリと連携して使う前提のアーキテクチャになっています。

このため Clair は、レジストリに登録されるイメージを継続的・大規模に検査するような運用に向いています。対象はコンテナイメージが中心で、IaC やシークレット、ライセンスは対象に含まれません。「まず手元やパイプラインで軽く始めたい」というニーズには CLI 単体で動く Trivy のほうが導入が容易で、「レジストリ統合を前提とした大規模な常駐運用を組みたい」場合には Clair が選択肢になります。

なお、OSS ではありませんが、開発者向けの商用プラットフォームとして Snyk も比較対象に挙がることがあります。Snyk は IDE 統合や幅広い言語サポート、ダッシュボードによる可視化が強みですが、完全な OSS である Trivy・Grype・Clair とはライセンス・コストの前提が異なります。Trivy 自体も商用版（Aqua プラットフォーム）との関係が公式に整理されており、OSS 版と商用版の違いは公式の比較ページで確認できます（Trivy Docs: Commercial Compare）。

ここまでの比較を踏まえると、Trivy が選ばれる理由は「1 つのツールで脆弱性以外（IaC・シークレット・ライセンス）まで広くカバーできること」と「CLI 単体でデーモン不要、導入が軽いこと」の 2 点に集約されます。

Trivyの採用に向くケース・向かないケース

ここまでの整理を、採用判断の形にまとめます。自分のプロジェクトの状況に当てはめて確認してください。

Trivy の採用が向いているのは、次のようなケースです。

• コンテナイメージだけでなく、IaC の設定ミスやシークレット、ライセンスも 1 つのツールでまとめてチェックしたい
• 常駐サービスを立てず、CLI で軽く始めたい
• 既存の CI/CD（GitHub Actions など）に組み込んでスキャンを自動化したい
• Kubernetes クラスタやクラウド環境まで対象を広げる可能性がある

一方で、次のようなケースでは別のツールも検討する価値があります。

• 脆弱性の検出と、対応すべき優先順位の判断を特に重視したい → Grype
• コンテナレジストリと統合し、大規模に常駐運用したい → Clair
• ダッシュボードによる可視化や、商用サポートを前提に運用したい → Snyk 等の商用プラットフォーム

最終的なチェックとして、ライセンスとメンテナンス健全性も確認しておきましょう。Trivy は Apache-2.0 ライセンスで商用利用しやすく、スター数 36,368・直近（2026-06-11）まで更新が続く活発なプロジェクトであり、アーカイブもフォークもされていない現役の OSS です。採用後に開発が止まるリスクという観点では、現時点では健全な状態にあると判断できます。

ただし、前述したとおり 2026 年 3 月には GitHub Actions 連携部分を狙ったサプライチェーン攻撃（CVE-2026-33634）が発生した経緯があります。インシデント自体は復旧済みですが、特に「既存の CI/CD に組み込んで自動化したい」というケースで採用する場合は、trivy-action / setup-trivy を導入する前に公式アドバイザリで安全バージョンを確認し、バージョンをタグではなくコミット SHA で固定する運用を前提にしておくことを強くおすすめします。この一手間をかけられるかどうかも、CI に組み込む形で Trivy を採用するうえでの実務的なチェックポイントになります。

まとめ

Trivy は、コンテナイメージ・Kubernetes・IaC・コードリポジトリ・クラウドといった幅広い対象を、脆弱性・設定ミス・シークレット・ライセンス・SBOM という複数の観点から、1 つの CLI でまとめてスキャンできる OSS です。デーモン不要で導入が軽く、CI/CD への組み込みやエコシステムも整備されているため、初めて脆弱性スキャナを導入するチームでも段階的に運用を広げやすい点が強みになります。

類似ツールとの使い分けの要点は、「脆弱性に絞って優先順位付けを重視するなら Grype」「レジストリ統合の大規模常駐運用なら Clair」「広い守備範囲と軽い導入を両立したいなら Trivy」と整理できます。なお、CI/CD（特に GitHub Actions）に組み込んで使う場合は、2026 年 3 月のサプライチェーン攻撃（CVE-2026-33634、復旧済み）を踏まえ、公式アドバイザリの確認とバージョンのコミット SHA 固定を前提にしておきましょう。自分のプロジェクトがどの状況に当てはまるかを確認したうえで、Trivy が候補になるなら、まずは公式サイト（trivy.dev）と公式ドキュメントのインストールページ（Trivy Docs: Installation）から対象範囲とインストール方法を確認することをおすすめします。