Trivy実地分析: コンテナからKubernetesまで一つのCLIで調べる

Trivyは対象と検出内容を組み合わせる

Aqua SecurityのオープンソースプロジェクトTrivyは、READMEで包括的かつ多用途なセキュリティスキャナーと説明されています。設計を読むときは、どこを調べるかというtargetと、何を探すかというscannerを分けるのが分かりやすいです。対象にはコンテナイメージ、ファイルシステム、リモートGitリポジトリ、仮想マシンイメージ、Kubernetesが挙げられています。

検出側では、使用中のOSパッケージとソフトウェア依存関係をSBOMとして扱い、既知の脆弱性をCVEとして探します。IaCの問題と設定ミス、機密情報とシークレット、ソフトウェアライセンスも対象です。つまり「脆弱性だけを見るコマンド」ではなく、イメージ、ソース、クラスタなどの入口に、必要な検査カテゴリを組み合わせる道具です。READMEは主要な言語、OS、プラットフォームの多くを支援すると述べていますが、全対応表はScanning Coverageページへ委ねています。対応の有無を名前だけで推測せず、対象の種類と公式カバレッジを個別に確認する必要があります。

導入はHomebrew、Docker、リリースバイナリから始める

READMEにある代表的な導入方法は三つです。Homebrewならbrew install trivy、コンテナならdocker run aquasec/trivy、直接使うならGitHub Releasesの最新バイナリをダウンロードします。すべての方式を一つに固定する必要はありませんが、CIでは実行イメージと版を明示し、開発者の手元では更新経路を記録する方が結果を比較しやすくなります。

Trivyは多くのプラットフォームやアプリケーションと統合されており、詳細はEcosystemページにまとまっています。READMEで具体的に挙がるのはGitHub Actions、Kubernetes operator、VS Codeプラグインです。これらは呼び出しやすさを高めますが、連携先の権限、実行場所、キャッシュ、結果の保存、失敗時にビルドを止めるかは別の設計です。READMEには他のパッケージマネージャーや、各統合の入力と出力の完全な仕様は載っていません。導入時はまずCLI単体で同じ対象を再現し、連携を一つずつ追加するのが安全です。

基本構文で対象と検査カテゴリを明示する

一般的な書式はtrivy <target> [--scanners <scanner1,scanner2>] <subject>です。コンテナイメージを調べるtrivy image python:3.4-alpine、ファイルシステムに対して脆弱性、シークレット、設定ミスを指定するtrivy fs --scanners vuln,secret,misconfig myproject/、Kubernetesクラスタの概要を出すtrivy k8s --report summary clusterがREADMEの例です。

三つの例から読み取れるのは、対象の種類と検出カテゴリをコマンド上で選べることです。実際の出力はREADMEでは画像として示され、表の列、重大度の分類、終了コード、JSONなどの出力仕様までは本文にありません。CIで結果を判定する場合、画面表示だけで成功とみなさず、指定した形式の出力、終了コード、除外対象、DB更新の状態を自分の版で確認してください。対象を誤るとスキャナーが動いていても期待した範囲を見ていないため、実行ログにはtargetとscannerの両方を残すべきです。

canaryは新しさより本番境界を優先する

canaryビルドはmainブランチへのpushごとに生成されます。Docker Hub、GitHub Container Registry、Amazon ECRのイメージとバイナリの形で提供されるため、新しい変更を早く試す経路としては分かりやすい構成です。しかしREADMEは、canaryには重大なバグが含まれる可能性があり、本番利用を推奨しないと明記しています。

この注意書きは、canaryを通常の更新チャネルとして扱わないための境界です。検証で使う場合も、発見した結果を安定版のスキャンと同じ基準で解釈できるかを確認し、CIの必須判定や本番イメージの拒否条件へ直接つながない方がよいでしょう。READMEにはcanary専用の検証手順や問題報告の方法は示されず、一般的な議論の窓口としてGitHub Discussionsが案内されています。安定版、リリースバイナリ、canaryを記録上で区別し、脆弱性DBや検出ルールの差を含めて比較する必要があります。

SBOMと脆弱性を同じ依存関係の地図で見る

Trivyが探すOSパッケージとソフトウェア依存関係は、SBOMとして把握する対象です。コンテナイメージやファイルシステムで、どの部品が使われ、既知のCVEが紐づくかを確認する入口になります。IaCの設定ミス、シークレット、ライセンスも同じスキャンの考え方に置かれますが、検出結果の扱いはカテゴリごとに違います。秘密情報は即時の漏えい対応、ライセンスは利用条件、CVEは修正版や影響範囲の調査が必要です。

READMEは、ほとんどの一般的な言語やOS、プラットフォームを支援すると述べています。ただし、どの版の依存関係をどのデータベースで判定するか、誤検出の調整、例外の承認、結果の保存期間は、READMEの短い説明からは決められません。SBOMが出たことを完全な部品表とみなす前に、対象の検出範囲、生成時点、スキャン対象から外れたファイル、ソースとバイナリの対応を確認します。結果をチケットやリリース判定へ渡すなら、重大度だけでなく修正可能性と業務影響も別に記録する設計が必要です。

Kubernetesと開発環境では権限を分けて考える

KubernetesはTrivyのスキャン対象の一つで、READMEにはtrivy k8s --report summary clusterの例があります。クラスタ全体の概要を取る使い方ですが、接続情報、読み取り権限、対象Namespace、結果の保存先は運用側で決める必要があります。GitHub Actionsではコードやイメージの更新時、Kubernetes operatorではクラスタ上の継続的な確認、VS Codeプラグインでは開発者の編集時というように、同じTrivyでも実行位置が変わります。

権限を広く与えれば検査対象は増えますが、漏えいした結果や設定情報の範囲も大きくなります。READMEはセキュリティスキャナーとしての機能と統合先を示していますが、組織ごとのRBAC、監査ログ、秘密情報を含む結果の保護、APIの認証方式までは説明していません。まず読み取り専用のサービスアカウントとテストNamespaceで実行し、結果が誰に見え、どこへ転送されるかを確認してから対象を広げるべきです。

Aquaの位置づけとオープンソースの境界

READMEはTrivyの上にAquaが構築され、より拡張されたセキュリティ管理機能を提供すると案内しています。Trivy利用者向けの比較表、Aquaの製品サイト、デモ依頼へのリンクもあります。これはオープンソースのCLIに加えて商用の管理製品があるという製品構成の紹介であり、Trivy単体に商用サービスの全機能が含まれるという説明ではありません。

コミュニティ面では、TrivyはAqua Securityのオープンソースプロジェクトとされ、GitHub Discussionsで連絡や議論を行い、行動規範を守るよう求めています。メンテナーの応答時間、サポート契約、導入支援の範囲はREADMEに書かれていません。プロジェクトのスター数やダウンロード数のバッジも利用規模の手がかりですが、検出精度や自社環境での継続運用を保証しません。

Apache 2.0とREADMEが残す未確定事項

TrivyはApache License 2.0で配布されています。READMEにはライセンスバッジがあり、リポジトリのLICENSEへリンクしています。Apache 2.0は著作権と特許に関する許諾、複製、改変、公開、配布などの条件を定めるライセンスですが、セキュリティ、サポート、保証を約束する文書ではありません。自社製品へ組み込む場合は、通知、著作権表示、改変部分、第三者コンポーネントの条件をLICENSE本文と合わせて確認してください。

公開メタデータでは、2026年8月14日にv0.74.0がリリースされ、37674スター、635フォーク、258件のオープンIssueが記録されています。これらは取得時点のプロジェクト情報であり、本番導入の承認材料そのものではありません。READMEからは完全なカバレッジ表、検出の正確さ、出力の全仕様、長期サポート、第三者監査までは確定できません。採用前に安定版を固定し、イメージ、ソース、Kubernetesの代表サンプルを同じ条件で走らせ、結果の保管、誤検出の修正、canaryとの分離、更新時の再検証を運用手順に入れる必要があります。

編集部の結論

Trivyは、コンテナイメージ、ファイルシステム、リモートGitリポジトリ、仮想マシンイメージ、Kubernetesを対象に、OSパッケージ、依存関係、CVE、IaCの設定ミス、シークレット、ライセンスを調べるGo製スキャナーです。brew、Docker、リリースバイナリから始められ、GitHub Actions、Kubernetes operator、VS Code拡張との接続もREADMEにあります。一方、正確な対応表、出力形式、終了コード、検出精度、運用時の保証はREADMEだけでは確定できません。mainへのpushごとに作られるcanaryは重大なバグの可能性があり本番非推奨です。導入前に対象とスキャナーを明示し、テスト用のイメージとリポジトリで結果、除外設定、失敗時の扱い、脆弱性情報の更新を確認してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes