Trivyコンテナ脆弱性スキャン｜CIパイプライン組み込みとポリシーゲート設計

なぜ「スキャンするだけ」では不十分なのか

コンテナイメージのセキュリティ対策として、Trivyなどのスキャナーを導入している組織は増えています。しかし「スキャン結果をレポートとして保存する」だけで運用を終えているケースも少なくありません。この状態では、CRITICAL評価の脆弱性を含むイメージが本番環境にデプロイされるリスクを実質的に排除できていません。

スキャンが真に機能するのは、結果をパイプラインの「ゲート」として使い、基準を超えた場合にビルドやデプロイを自動停止する仕組みと組み合わせたときです。本記事では、Trivyをゼロから組み込むのではなく、すでにDockerfileやCI設定が存在する運用環境を前提に、ポリシーゲートを実装して継続的に機能させるための設計と手順を整理します。

Trivyの現在地：2026年時点のバージョンと機能範囲

Trivyはクラウドネイティブセキュリティプロジェクト（CNCF）のサンドボックスプロジェクトとして成長を続けており、2026年時点ではコンテナイメージだけでなく、ファイルシステム・Kubernetes マニフェスト・IaC（Terraform/CloudFormation）・Gitリポジトリまでスキャン対象が広がっています。

CI用途で特に重要な変更点として、--exit-codeオプションの挙動とSBOM出力（CycloneDX・SPDX形式）の安定化が挙げられます。かつてはオプション名や出力スキーマが頻繁に変わりましたが、v0.50以降は安定しており、パイプライン定義を書き直す頻度は大幅に減っています。また、--ignore-unfixedフラグで「修正版が提供されていない脆弱性を除外する」運用が標準的になりました。修正不可能な脆弱性でアラートが鳴り続けるノイズ問題は、このフラグひとつで大幅に改善されます。

ポリシーゲートの設計思想：何を基準に止めるか

ゲートを設計する前に、「何を閾値にするか」を組織として決める必要があります。よく見られる設計パターンを以下に示します。

• 重大度ベース（シンプル型）：CVSSスコアがCRITICALまたはHIGHに分類される脆弱性がひとつでも検出された場合にビルドを失敗させる。導入が容易で、最初のステップとして有効です。
• 修正可能性フィルター付き（推奨型）：--ignore-unfixedを組み合わせ、「修正版パッケージが存在するCRITICAL/HIGH」のみをゲート対象にする。ノイズを抑えつつ、対処可能な脆弱性には確実に対応できます。
• 例外リスト（.trivyignore）管理型：一時的に許容する脆弱性をCVE IDで明示的にリストアップし、レビュープロセスを経てファイルを更新する。コンプライアンス要件が厳しい環境向きです。

多くの現場では「推奨型＋.trivyignoreによる例外管理」の組み合わせが現実的です。シンプル型だけではノイズで運用が崩壊しがちで、例外リストだけでは管理コストが高くなります。

.trivyignoreファイルの管理ルール

.trivyignoreは単なる除外リストではなく、「一時的に許容したリスクの台帳」として扱うことが重要です。各エントリにはコメントで許容理由・期限・担当者を記載し、定期的なレビュー（例：四半期ごと）をCIの外側のプロセスとして確立しておくと、セキュリティ負債の蓄積を防げます。

GitHub ActionsおよびGitLab CIへの組み込み手順

GitHub Actionsでの実装例

GitHub Actionsでは、公式のaquasecurity/trivy-actionを使う方法が最もメンテナンスコストを抑えられます。以下はCRITICAL/HIGHの修正可能な脆弱性を検出した際にジョブを失敗させる基本設定です。

- name: Run Trivy vulnerability scanner
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: '${{ env.IMAGE_NAME }}:${{ github.sha }}'
    format: 'table'
    exit-code: '1'
    ignore-unfixed: true
    vuln-type: 'os,library'
    severity: 'CRITICAL,HIGH'

exit-code: '1'を指定することで、基準を超えた脆弱性が検出されたときにアクションが非ゼロの終了コードを返し、ジョブ全体が失敗扱いになります。vuln-type: 'os,library'はOSパッケージとアプリケーションライブラリの両方をカバーするため、特別な理由がない限りこのセットを推奨します。

SBOM出力も同時に保存したい場合は、スキャンジョブを2段階に分割する構成が管理しやすいです。1回目をformat: 'cyclonedx'でSBOM生成・アーティファクト保存、2回目をformat: 'table'でゲート判定に使う、という分割です。

GitLab CIでの実装例

GitLab CIではDockerイメージを直接指定して実行します。GitLab自体にコンテナスキャン機能が組み込まれていますが、Trivyを直接使う場合は以下のようなジョブ定義になります。

trivy-scan:
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy image
        --exit-code 1
        --ignore-unfixed
        --severity CRITICAL,HIGH
        --no-progress
        "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
  allow_failure: false

allow_failure: false（デフォルト値ですが明示的に記載することを推奨します）を設定しておかないと、スキャン失敗がパイプライン全体の失敗として扱われず、後続のデプロイジョブが継続してしまう場合があります。特にGitLab CIではallow_failureの扱いが複雑なため、意図を明示しておくことが重要です。

よくある落とし穴と切り戻し・調整ポイント

スキャン対象を「ビルド後イメージ」にする

Trivyのスキャン対象は必ず最終的なビルド済みイメージにしてください。Dockerfileのベースイメージ（FROM行で指定するイメージ）だけをスキャンする誤った運用が散見されますが、アプリケーションの依存ライブラリはビルド後にインストールされるため、ベースイメージのスキャンだけでは見落としが発生します。

DBキャッシュとオフライン環境

TrivyはスキャンのたびにGhSA・NVDなどの脆弱性データベースを更新しようとします。ネットワーク制限のある環境や、CI実行ごとのDB取得でジョブが遅くなる場合は、--skip-db-updateフラグとDBキャッシュの共有を組み合わせた運用が有効です。GitLab CIであればcacheディレクティブ、GitHub Actionsであればactions/cacheを使ってTrivyのキャッシュディレクトリ（デフォルト：$HOME/.cache/trivy）を保持します。ただし、DBが古くなりすぎると検出精度が落ちるため、キャッシュの有効期限は最大でも24時間程度に設定することを推奨します。

ゲートが厳しすぎてデプロイが止まり続ける場合

初めてCRITICAL/HIGHゲートを導入すると、既存のイメージで大量の脆弱性が検出されてパイプラインが全滅するケースがあります。この場合の現実的な段階的導入アプローチとして、まず--exit-code 0（スキャンは行うがゲートは機能させない）でしばらく運用し、レポートを見ながら.trivyignoreを整備してから--exit-code 1に切り替える方法が有効です。また、新規イメージのみゲートを適用し、既存イメージは別ジョブで監視のみ行う分岐設計も現場でよく使われます。

2026年時点の現行環境差分：OCI・Kubernetes連携の動向

2026年においてコンテナセキュリティのトレンドとして注目されるのが、スキャン結果とOCIアーティファクトの紐付けです。Trivyが出力するSBOMや脆弱性レポートをOCIレジストリにアーティファクトとして付与する（cosignのAttestationと組み合わせる）運用が標準化しつつあります。これにより「このイメージのSBOMはどこにあるか」という追跡性の問題が解決され、サプライチェーンセキュリティの要件（SLSA・NIST SSDF）への対応が容易になります。

Kubernetes環境では、Trivyをアドミッションコントローラーとして組み込むTrivy Operatorの採用が進んでいます。CIゲートに加えてクラスター内でも継続的なスキャンを行い、新たに公開された脆弱性情報に対してデプロイ済みワークロードを自動で再評価する仕組みです。CI段階でのゲートとクラスター内の継続監視を組み合わせた「二重防衛」が、2026年時点での現実的なベストプラクティスとして定着しつつあります。

一方、既存の組み込み型スキャン（ECRの自動スキャンやGitLab Container Scanning）との二重管理は混乱の元になります。Trivyをパイプラインの主軸に据える場合は、クラウドプロバイダーや開発プラットフォームの組み込みスキャンを意図的に無効化または結果集約の対象から外す設計を明確にしておくことが、運用の健全性を保つ上で重要です。