Trivyの使い方｜脆弱性スキャン・SBOM出力とGitHub Actions設定

Trivy は、コンテナイメージ・フォルダ・リポジトリ・設定ファイルを1つのコマンドで調べる、無料のセキュリティスキャナーです。 依存ライブラリの脆弱性（vuln）、秘密情報（secret）、設定ミス（misconfig）、ライセンス（license）を検出し、SBOM（ソフトウェアの部品表）も出せます。

trivy image python:3.12-slim                                # コンテナイメージ
trivy fs .                                                  # フォルダ（package-lock.json・requirements.txt など）
trivy config .                                              # Dockerfile・Kubernetes・Terraform の設定ミス
trivy fs --severity HIGH,CRITICAL --exit-code 1 .           # 重大なものがあれば CI を失敗させる
trivy fs --format cyclonedx --output sbom.cdx.json .        # SBOM を出す

確認環境：Trivy 0.75.0（GitHub のリリースから入れ、公開されたチェックサムと照合）、Ubuntu 24.04 で動かしました。設定ミスのスキャンは Trivy に組み込まれたチェックで行い、脆弱性 DB を使うスキャン（trivy image・trivy fs の vuln）の出力の形、trivy-action の入力は公式ドキュメントと README で確かめています（確認日 2026年10月13日）。

インストール

バイナリを入れるときは、同じリリースの trivy_0.75.0_checksums.txt と照合します。

curl -LO https://github.com/aquasecurity/trivy/releases/download/v0.75.0/trivy_0.75.0_checksums.txt
sha256sum --ignore-missing -c trivy_0.75.0_checksums.txt
tar xzf trivy_0.75.0_Linux-64bit.tar.gz trivy && sudo mv trivy /usr/local/bin/

2026年3月、Trivy の配布物を狙った攻撃がありました。 Aqua Security の公表では、3月19日に悪意のある Trivy v0.69.4、trivy-action・setup-trivy のタグの書き換えが行われ、Docker Hub の 0.69.5・0.69.6 のイメージも悪意のあるものでした。公表されたものを使っていないかの確認、版を固定した入れ方、GitHub Actions をコミット SHA で固定すること（後述）が勧められています。

コマンド早見表

スキャンする対象

trivy image は、Docker が無くても動きます。 --image-src の既定は docker,containerd,podman,remote の順で、ローカルに無ければレジストリから直接取得します。

よく使うオプション

trivy fs の既定は vuln,secret で、設定ミス（misconfig）は入っていません。 Dockerfile や Kubernetes の YAML も一緒に見るときは、--scanners vuln,secret,misconfig を付けるか、trivy config を別に流します。

依存ライブラリの脆弱性をスキャンする

trivy fs --scanners vuln .
trivy image --severity HIGH,CRITICAL --ignore-unfixed python:3.12-slim

結果の表は、公式ドキュメントでは次の列です。

--ignore-unfixed を付けると、修正版がまだ無いものを表示しません。 ドキュメントでは、--ignore-status affected,will_not_fix,fix_deferred,end_of_life と同じ意味です。直す手段が無いものでビルドを止めないために、CI でよく使われます。どのライブラリから入ってきたかを知りたいときは、--dependency-tree（表の形式のときだけ）で依存の木を出せます。

Trivy が部品として認識するもの

フォルダの中のどのファイルから部品（パッケージ）を見つけるかで、スキャンの漏れが変わります。

requirements.txt は、版を == で固定した行しか部品として認識されませんでした。 次の3行を置いて SBOM を出すと、部品は Django だけでした。

Django==3.2.0
flask>=2.0
requests~=2.19

[('requirements.txt', None), ('Django', '3.2.0')]

ドキュメントでも、既定では == の行だけを読むと書かれています。--detection-priority comprehensive を付けると、>=・~= の行も「下限の版」として読みました。

$ trivy fs --detection-priority comprehensive --format cyclonedx .
[('requirements.txt', None), ('Django', '3.2.0'), ('flask', '2.0'), ('requests', '2.19')]

ただし、これは「下限の版」で、実際に入る版とは違います。漏れと誤検知を減らすには、pip freeze や uv pip compile で全部の版を固定したファイルか、uv.lock・poetry.lock を作ってからスキャンします。

脆弱性 DB を取れないとき

脆弱性のスキャンには、初回に脆弱性 DB のダウンロードが要ります。 取得先は OCI レジストリで、既定では mirror.gcr.io/aquasec/trivy-db:2、取得できなければ ghcr.io/aquasecurity/trivy-db:2 の順に試します（--db-repository の既定値）。社内のプロキシなどで両方に出られないと、次のエラーで止まります。

INFO  [vulndb] Downloading artifact...  repo="ghcr.io/aquasecurity/trivy-db:2"
FATAL Fatal error  run error: init error: DB error: failed to download vulnerability DB: OCI artifact error:
      failed to download vulnerability DB: failed to download artifact from ghcr.io/aquasecurity/trivy-db:2:
      OCI repository error: 1 error occurred:
    * Get "https://ghcr.io/v2/": Forbidden

設定ミスのスキャンは、DB が無くても動きました。 チェックの集まり（checks bundle）の取得に失敗すると、Falling back to embedded checks と出て、バイナリに組み込まれたチェックで続けます（ドキュメントの説明どおり）。

設定ミスをスキャンする（trivy config）

よくある書き方の Dockerfile と、Kubernetes の Deployment をスキャンしました。

FROM python:3.12
COPY . /app
RUN pip install -r /app/requirements.txt
CMD ["python", "/app/main.py"]

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 1
  selector:
    matchLabels: { app: demo }
  template:
    metadata:
      labels: { app: demo }
    spec:
      containers:
        - name: app
          image: demo:latest
          securityContext:
            privileged: true

$ trivy config .
Report Summary

┌─────────────────┬────────────┬───────────────────┐
│     Target      │    Type    │ Misconfigurations │
├─────────────────┼────────────┼───────────────────┤
│ Dockerfile      │ dockerfile │         2         │
├─────────────────┼────────────┼───────────────────┤
│ k8s/deploy.yaml │ kubernetes │        18         │
└─────────────────┴────────────┴───────────────────┘

Dockerfile (dockerfile)
=======================
Tests: 27 (SUCCESSES: 25, FAILURES: 2)
Failures: 2 (UNKNOWN: 0, LOW: 1, MEDIUM: 0, HIGH: 1, CRITICAL: 0)

DS-0002 (HIGH): Specify at least 1 USER command in Dockerfile with non-root user as argument
...
KSV-0001 (MEDIUM): Container 'app' of Deployment 'demo' should set 'securityContext.allowPrivilegeEscalation' to false
────────────────────────────────────────
 k8s/deploy.yaml:14-17
────────────────────────────────────────
  14 ┌         - name: app
  15 │           image: demo:latest
  16 │           securityContext:
  17 └             privileged: true

該当する行まで表示されます。 検出された20件のうち、主なものです。

Dockerfile を次のように直すと、Dockerfile の検出は 0件になりました。

FROM python:3.12-slim
RUN useradd --create-home --uid 10001 app
WORKDIR /app
COPY --chown=app:app requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY --chown=app:app . .
USER app
HEALTHCHECK --interval=30s --timeout=3s CMD python -c "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/health')"
CMD ["python", "main.py"]

Dockerfile を軽く安全に書く方法は、関連記事「Dockerfileの書き方｜軽く・速く・安全なイメージを作るベストプラクティス」で扱っています。

秘密情報をスキャンする

ソースに書いたトークンやパスワードも検出します。 ダミーの GitHub の個人アクセストークン（ghp_ で始まる文字列）を書いたファイルをスキャンしました。

$ trivy fs --scanners secret .
settings.py (secrets)
=====================
Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 1)

CRITICAL: GitHub (github-pat)
════════════════════════════════════════
GitHub Personal Access Token
────────────────────────────────────────
 settings.py:1 (offset: 16 bytes)
────────────────────────────────────────
   1 [ GITHUB_TOKEN = "****************************************"
   2   DEBUG = True

結果の中では、トークンは * で伏せて表示されました。 見つかったトークンは、ファイルから消すだけでなく、発行元で無効にして作り直します。手順は、関連記事「APIキーをGitHubにpushしてしまった時の対処手順」で扱っています。

重大度での絞り込みと終了コード

CI でビルドを止めるかどうかは、--severity と --exit-code の組み合わせで決めます。

$ trivy config -q --severity HIGH,CRITICAL --exit-code 1 .
Dockerfile (dockerfile)
Failures: 1 (HIGH: 1, CRITICAL: 0)
DS-0002 (HIGH): Specify at least 1 USER command in Dockerfile with non-root user as argument
k8s/deploy.yaml (kubernetes)
Failures: 3 (HIGH: 3, CRITICAL: 0)
KSV-0014 (HIGH): ...
KSV-0017 (HIGH): ...
KSV-0118 (HIGH): ...
$ echo $?
1

--severity は「表示する重大度」と「終了コードを決める対象」の両方に効きます。 手元では、HIGH・CRITICAL に絞ると LOW・MEDIUM の16件は表示されませんでした。LOW の検出（DS-0026）だけがある Dockerfile では、--severity HIGH,CRITICAL --exit-code 1 の終了コードは 0 でした。

.trivyignore で除外する

誤検知や、理由があって直さないものは .trivyignore に ID を書いて除外します。 1行に1つの ID を書き、# から後はコメントです。exp:日付 を付けると、その日を過ぎたら除外が切れます。

# 理由：ベースイメージ側で USER を設定済み（チケット SEC-12）
DS-0002
# 期限付きで除外（この日を過ぎると再び検出される）
KSV-0118 exp:2026-12-31
CVE-2024-12345

ID は、Trivy 0.75.0 の出力では DS-0002 の形でした。 少し前の版のドキュメントでは AVD-DS-0002 の形で書かれています。出力に出た ID をそのまま書きます。

.trivyignore.yaml（ファイル・理由ごとに除外）

YAML の形にすると、「このファイルだけ」「理由」「期限」を書けます。 ドキュメントでは試験的な機能で、--ignorefile で指定したときだけ読まれます。

misconfigurations:
  - id: KSV-0014
    paths:
      - "k8s/deploy.yaml"
    statement: 書き込みが要るため。対応はチケット SEC-15
    expired_at: 2026-12-31
vulnerabilities:
  - id: CVE-2024-12345
    purls:
      - "pkg:npm/lodash@4.17.15"
    statement: 該当の関数を使っていない

trivy config --ignorefile .trivyignore.yaml .

手元では、KSV-0014 だけが表示されなくなりました。除外には必ず理由と期限を書き、レビューで見てもらいます。 期限が無い除外は、直す機会を失いがちです。

SBOM を出す（CycloneDX・SPDX）

SBOM（Software Bill of Materials）は、ソフトウェアに入っている部品（ライブラリと版）の一覧です。 後から新しい脆弱性が公表されたときに、「どのシステムが影響を受けるか」をすぐに調べられます。

trivy fs --format cyclonedx --output sbom.cdx.json .       # CycloneDX
trivy fs --format spdx-json --output sbom.spdx.json .      # SPDX（JSON）
trivy image --format cyclonedx --output sbom.cdx.json python:3.12-slim
trivy sbom sbom.cdx.json                                   # SBOM から脆弱性を調べる

package-lock.json（lodash・minimist）と requirements.txt（Django・requests・PyYAML）を置いたフォルダから出した結果です。

application requirements.txt
application package-lock.json
library lodash 4.17.15 pkg:npm/lodash@4.17.15
library minimist 1.2.5 pkg:npm/minimist@1.2.5
library Django 3.2.0 pkg:pypi/django@3.2.0
library PyYAML 5.3 pkg:pypi/pyyaml@5.3
library requests 2.19.0 pkg:pypi/requests@2.19.0

purl（Package URL）は、部品を言語をまたいで一意に表す書き方です。 脆弱性 DB や .trivyignore.yaml の purls で、部品を指すときに使います。

SBOM を作るだけなら、脆弱性 DB は要りませんでした。 部品の一覧は、手元のファイルから作られるためです。

GitHub Actions の雛形

trivy-action は、GitHub Actions から Trivy を動かすための公式のアクションです。 2026年10月13日時点の最新のタグは v0.36.0 です。2026年3月にタグが書き換えられた件があったので、タグではなく、コミット SHA で固定します。 v0.36.0 のコミット SHA は git ls-remote で確かめました。

git ls-remote https://github.com/aquasecurity/trivy-action 'refs/tags/v0.36.0*'
# ed142fd0673e97e23eac54620cfb913e5ce36c25  refs/tags/v0.36.0^{}   ← この値を使う

プルリクエストで依存と設定をスキャンする

name: trivy
on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: "0 0 * * 1"          # 毎週月曜（新しく公表された脆弱性に気づくため）

permissions:
  contents: read

jobs:
  scan:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
      security-events: write      # SARIF のアップロードに要る
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

      - name: 依存・秘密情報・設定ミス（HIGH 以上で失敗）
        uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25 # v0.36.0
        with:
          scan-type: fs
          scan-ref: .
          scanners: vuln,secret,misconfig
          severity: HIGH,CRITICAL
          ignore-unfixed: true
          exit-code: "1"
          trivyignores: .trivyignore

      - name: 結果を SARIF で出す（失敗しても続ける）
        if: always()
        uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25 # v0.36.0
        with:
          scan-type: fs
          scan-ref: .
          scanners: vuln,secret,misconfig
          format: sarif
          output: trivy-results.sarif
          skip-setup-trivy: true

      - name: GitHub の Security タブに送る
        if: always()
        uses: github/codeql-action/upload-sarif@24c54180a607b1449ed407dd24f251e4e9147c8d # v4.38.3
        with:
          sarif_file: trivy-results.sarif

イメージをビルドしてスキャンし、SBOM を残す

  image:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - run: docker build -t app:${{ github.sha }} .

      - name: イメージの脆弱性（HIGH 以上で失敗）
        uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25 # v0.36.0
        with:
          image-ref: app:${{ github.sha }}
          severity: HIGH,CRITICAL
          ignore-unfixed: true
          exit-code: "1"

      - name: SBOM（CycloneDX）
        if: always()
        uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25 # v0.36.0
        with:
          image-ref: app:${{ github.sha }}
          format: cyclonedx
          output: sbom.cdx.json
          skip-setup-trivy: true

      - uses: actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9 # v7.0.2
        if: always()
        with:
          name: sbom
          path: sbom.cdx.json

SARIF の出力には、既定では severity が効きません。 README のとおり、SARIF にもすべての重大度が入ります（手元の trivy config -f sarif でも、20件すべてが入りました）。Security タブには全件を出し、ビルドの失敗は HIGH 以上で決める、という分け方ができます。

version の既定は README では v0.74.0 で、Trivy 本体の最新（v0.75.0）とは一致しません。 本体の版をそろえたいときは、version: v0.75.0 のように指定します。GitHub Actions の基本は関連記事「CI/CDとは｜GitHub Actionsで最初のパイプラインを作るまで」で、キャッシュは「GitHub Actionsのキャッシュとmatrix｜コピペ用YAMLとキー設計」で扱っています。

よくある質問

Q. 検出が多すぎて、どれから直せばよいか分かりません。 A. --severity HIGH,CRITICAL --ignore-unfixed で、「重大で、直す手段があるもの」に絞ってから始めます。脆弱性はライブラリの版上げでまとめて消えることが多いので、Library 列でまとめて見ます。

Q. ベースイメージの OS のパッケージの脆弱性が大量に出ます。 A. -slim・distroless などの小さいベースイメージにすると、入っているパッケージが減り、検出も減ります。アプリのライブラリだけを見たいときは --pkg-types library を使います。

Q. 毎回 DB をダウンロードして遅いです。 A. trivy-action は README ではキャッシュが既定で有効です。自分で動かすときは --cache-dir をキャッシュの対象にします。

Q. 社内のネットワークから DB を取得できません。 A. 「脆弱性 DB を取れないとき」の表のとおり、通信の許可、社内のレジストリへの複製、--download-db-only と --skip-db-update の組み合わせがあります。

まとめ

• trivy image・trivy fs・trivy config で、イメージ・フォルダ・設定ファイルを調べる。fs の既定は vuln,secret
• CI は --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 が基本の形。--severity は表示と終了コードの両方に効く
• requirements.txt は == で固定した行だけが部品になる。ロックファイルを作ってからスキャンする
• 除外は .trivyignore（exp: で期限）か .trivyignore.yaml（ファイル・理由ごと）。期限切れは効かなくなる
• SBOM は --format cyclonedx / spdx-json。作るだけなら DB は要らない
• GitHub Actions は trivy-action v0.36.0 をコミット SHA で固定し、SARIF は if: always() で送る

参考・出典

確認日はいずれも 2026年10月13日です。

• Trivy リリース（v0.75.0）：https://github.com/aquasecurity/trivy/releases
• Trivy ドキュメント「Filtering」（.trivyignore・.trivyignore.yaml・--ignore-unfixed）：https://trivy.dev/docs/latest/configuration/filtering/
• Trivy ドキュメント「Python」（requirements.txt の読み方）：https://trivy.dev/docs/latest/coverage/language/python/
• Trivy ドキュメント「Node.js」：https://trivy.dev/docs/latest/coverage/language/nodejs/
• Trivy ドキュメント「Reporting」：https://trivy.dev/docs/latest/configuration/reporting/
• Trivy ドキュメント「Air-Gapped Environment」：https://trivy.dev/docs/latest/guide/advanced/air-gap/
• Trivy ドキュメント「Troubleshooting」：https://trivy.dev/docs/latest/guide/references/troubleshooting/
• aquasecurity/trivy-action（README）：https://github.com/aquasecurity/trivy-action
• Aqua Security「Trivy Supply Chain Attack: What You Need to Know」：https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。