LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

開発チームから「コンテナの検査にはTrivyを使っています」と聞いたものの、何を検査しているのか分からない。無料と聞くけれど、業務で使い続けてよいのか判断がつかない——。開発を外部の会社と一緒に進めている情報システム部門では、こうした戸惑いが起こりがちです。Trivyは、コンテナイメージやソースコード、設定ファイルなどに潜むセキュリティ上の問題を探す、オープンソースの検査ツールです。

コンテナだけでなく、ファイル一式やKubernetes（コンテナをまとめて動かす仕組み）まで1つの道具で点検できるのが持ち味です。ただし万能ではなく、見つけられるのは公表済みの弱点や、用意された検査ルールに当てはまる設定の誤りです。本記事では、システムの導入や運用を判断する立場の方に向けて、Trivyが検査できる対象と見つけるもの、商用製品との違い、結果の読み方、そして外部に頼むときに確認したい点を整理します。

Trivyとは

Trivyは、Aqua Securityが保守しているオープンソースの検査ツールです。^*1 GitHubの説明では、問題を探す「検査の種類（スキャナー）」と、問題を探しに行く「検査する場所（ターゲット）」の組み合わせで機能を整理しています。まずは道具としての基本を押さえておきます。

• ライセンスはApache License 2.0で、利用・改変・再配布が認められています^*1
• コマンドで操作する道具で、Webの管理画面は付いていません
• 脆弱性の情報はデータベースとして別に配られ、Trivyが必要に応じて自動で取得し更新します^*2
• GitHub Actions（開発作業を自動で回す仕組み）やKubernetes、VS Code（コードを書くための編集ソフト）と連携する公式の部品があります

無料で使える代わりに、データベースをどこから取得するか、結果を誰が見て直すかは自分たちで決めることになります。社内のネットワークから外部へ接続しにくい環境に向けて、データベースの取得先を別に指定する設定も用意されています。

検査できる対象と見つけるもの

GitHubの説明は、検査できる対象として5つ、見つけられるものとして5つを挙げています。^*1 対象を変えても同じ道具で検査できるため、コンテナを使っていない開発でも、ソースコードの置き場所や設定ファイルを点検する用途で使えます。

• 使っている部品：OSのパッケージやライブラリを洗い出し、SBOM（ソフトウェア部品表）としてCycloneDXかSPDXの形式で書き出せます^*3
• 既知の脆弱性：公表済みの弱点（CVE、脆弱性ごとに付く識別番号）が含まれていないかを調べます
• 設定の誤り：Terraform・CloudFormation（クラウドの構成を書くファイル）、Kubernetesの定義、Dockerfileなどを点検します^*4
• 秘密情報：パスワード、APIキー、トークンが書き込まれたままになっていないかを探します。この検査は標準で有効です^*5
• ライセンス：見つけたライセンスを「禁止」「制限」など7つの区分に分けて示します^*6

注意したいのは、Kubernetesのクラスターと仮想マシンのイメージの検査が、公式ドキュメントで試験的（EXPERIMENTAL）な機能と明記されている点です。^*7*8 互換性を保たずに変わることがあるため、業務の手順に組み込むなら、版を上げるたびに動きを確かめる前提で使います。

オープンソース版と商用製品の違い

開発元はTrivyをもとにした商用製品も提供しており、公式ドキュメントに両者の違いをまとめた比較表を載せています。^*9 どちらが合うかは使い方で変わるため、ここでは比較表に書かれている事実を抜き出して並べます。

オープンソース版で足りるかどうかは、検査する仕組みの数や部署の数、問題が見つかったときに誰が対応を追いかけるかで決まります。1つのチームで検査を回すうちはオープンソース版から始め、複数の部署の結果を1か所で管理したくなった段階で、商用製品や別の管理の仕組みを比べる順で考えると判断しやすくなります。

検査結果の読み方

Trivyの結果には、見つかった弱点ごとに重大度が付きます。重大度は、OSの提供元など情報源が付けた評価を優先して使い、評価が無いときはCVSS（脆弱性の深刻さを0〜10の点数で表す共通の尺度）の点数から決めます。^*10

• 同じ弱点でも情報源によって評価が変わります。公式ドキュメントは、米国の脆弱性データベースNVDがHIGHとした弱点を、Red Hatの評価に合わせてLowと表示する例を挙げています^*10
• 修正版がまだ出ていない弱点も一覧に出ます。表示しない設定もありますが、隠すかどうかは自社の基準で決めます
• Trivyは誤検知を減らすことを優先し、一部の見逃しは受け入れる方針だと説明しています

最初の検査では一覧が長くなりがちです。件数に慌てず、重大度が高く修正版が出ているものから順に見ていくと手が止まりません。見逃しを受け入れる方針である以上、Trivyの結果が空でも問題が無いと言い切れない点も、社内で共有しておきます。

外部に頼むときに確認しておきたい点

開発者が自分のPCで試すだけなら、Trivyに外部の手は要りません。一方、検査を開発の流れに組み込み、結果を誰がいつ見て直すかまで決める段階になると、設計と運用の手間が増えます。開発元も、オープンソース版の導入と連携にはある程度の技術が要るとしています。外部に頼む場合は、次の点を見積もりの前に確かめておきます。

• 検査の範囲：コンテナイメージだけか、ソースコードや設定ファイル、Kubernetesのクラスターまで含めるか
• 結果の扱い：どの重大度から直すか、修正版が無い弱点をどう記録するかの基準まで一緒に決めてくれるか
• データベースの取得：社内のネットワークから取得できるか、取得先を別に用意する必要があるか
• 試験的な機能：Kubernetesや仮想マシンの検査を使うなら、版の更新で動きが変わったときの確かめ方
• 運用後の見直し：検査の対象や基準を、結果を見ながら直す場を設けるか

コンテナイメージの検査を開発の流れに組み込む具体的な進め方は、コンテナイメージ脆弱性スキャン導入を外注で進めるで扱っています。部品表の作成と管理まで広げる場合は、SBOM作成・管理の外注費用と委託先の選び方も参考になります。

まとめ：Trivyで確かめておきたい3つの点

Trivyを使い始めるうえで、確かめておきたい点は3つに整理できます。第一に、コンテナイメージ、ソースコード、設定ファイル、Kubernetesのクラスターのうち、どれを検査するかを決めること。第二に、重大度の決まり方を知ったうえで、どこから直すかの基準を決めること。第三に、データベースの取得と版の更新を誰が受け持つかを決めることです。この3点を踏まえておけば、「検査は入れたが、結果の一覧が積み上がるだけで誰も直していない」という事態を避けやすくなります。検査の設計や運用の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：aquasecurity/trivy（GitHub）README・LICENSE（https://github.com/aquasecurity/trivy）。出典：検査できる対象（Targets）と見つけられるもの（Scanners）、連携先（GitHub Actions・Kubernetes operator・VS Code plugin）、Aqua Securityのオープンソースプロジェクトであること、ライセンス（Apache License 2.0）を参照（2026年10月確認）
2. *2　参考：Trivy Documentation「Databases」（https://trivy.dev/docs/latest/configuration/db/）。出典：脆弱性データベース等を自動で取得・管理する仕組み、取得先の変更の記述を参照（2026年10月確認）
3. *3　参考：Trivy Documentation「SBOM」（https://trivy.dev/docs/latest/supply-chain/sbom/）。出典：CycloneDXとSPDXの形式でSBOMを生成できる記述を参照（2026年10月確認）
4. *4　参考：Trivy Documentation「Infrastructure as Code」（https://trivy.dev/docs/latest/coverage/iac/）。出典：設定の誤りを検査できる設定ファイルの種類（Kubernetes・Docker・Terraform・CloudFormation等）を参照（2026年10月確認）
5. *5　参考：Trivy Documentation「Secret Scanning」（https://trivy.dev/docs/latest/scanner/secret/）。出典：パスワード・APIキー・トークンの検出と、秘密情報の検査が標準で有効である記述を参照（2026年10月確認）
6. *6　参考：Trivy Documentation「License Scanning」（https://trivy.dev/docs/latest/scanner/license/）。出典：ライセンスの区分（Forbidden・Restricted・Reciprocal・Notice・Permissive・Unencumbered・Unknown）を参照（2026年10月確認）
7. *7　参考：Trivy Documentation「Kubernetes」（https://trivy.dev/docs/latest/target/kubernetes/）。出典：Kubernetesの検査が試験的（EXPERIMENTAL）な機能である記述を参照（2026年10月確認）
8. *8　参考：Trivy Documentation「Virtual Machine Image」（https://trivy.dev/docs/latest/target/vm/）。出典：仮想マシンのイメージの検査が試験的（EXPERIMENTAL）な機能である記述を参照（2026年10月確認）
9. *9　参考：Trivy Documentation「Comparison」（Aqua Security）（https://trivy.dev/docs/latest/commercial/compare/）。出典：オープンソース版と開発元の商用製品の比較表（操作方法・サポート・検査の実行・脆弱性の情報源・Windowsのコンテナ）を参照（2026年10月確認）
10. *10　参考：Trivy Documentation「Vulnerability」（https://trivy.dev/docs/latest/scanner/vulnerability/）。出典：重大度の決め方（情報源の評価を優先・CVSSの点数による区分）、NVDとRed Hatの評価が異なる例、修正版の無い弱点、誤検知を減らす方針の記述を参照（2026年10月確認）
11. *11　参考：経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を策定しました（2023年7月28日）（https://www.meti.go.jp/press/2023/07/20230728004/20230728004.html）。出典：SBOMの導入により期待される効果（脆弱性対応の初動期間の短縮など）の記述を参照（2026年10月確認）

Tweet