---

name: trivy-vulnerability-scanner description: '用于通过 Trivy 扫描仓库、容器镜像、文件系统、rootfs、SBOM、Kubernetes、IaC、密钥、许可证和系统 CVE。' zh_description: "用于通过 Trivy 扫描仓库、容器镜像、文件系统、rootfs、SBOM、Kubernetes、IaC、密钥、许可。" version: "1.0.0" author: seaworld008 source: "in-house" source_url: "" tags: '[security, vulnerability-scanning, cve, container-security, kubernetes, sbom, iac, secrets]' created_at: "2026-05-20" updated_at: "2026-05-20" quality: 4 complexity: advanced

Trivy Vulnerability Scanner

Trigger / When to Use

Use this skill when the user asks to scan a codebase, container image, Linux root filesystem, Kubernetes cluster, SBOM, or repository for CVEs, misconfigurations, exposed secrets, or license risks with Trivy.

Good trigger phrases:

• "scan this Docker image for CVEs"
• "run Trivy on this repo"
• "check Kubernetes manifests for vulnerabilities"
• "generate a SARIF vulnerability report"
• "scan a Linux rootfs or container filesystem"
• "fail CI on critical fixable CVEs"

Core Capabilities

• Vulnerability scanning for OS packages and application dependencies.
• Container image scanning from local engines or remote registries.
• Filesystem and root filesystem scanning for source trees and unpacked images.
• Repository scanning for git URLs or local project directories.
• Kubernetes scanning for cluster and resource risk review.
• IaC misconfiguration checks for Kubernetes YAML, Dockerfiles, Terraform, and related config.
• Secret scanning for committed tokens, keys, and credentials.
• License scanning and SPDX/CycloneDX SBOM workflows.
• SARIF, JSON, table, template, and GitHub-friendly reporting.

Workflow

1. Identify the Target

Classify the target before running commands:

• Source repository: use trivy repo or trivy fs.
• Container image: use trivy image.
• Unpacked root filesystem: use trivy rootfs.
• Kubernetes cluster or manifests: use trivy k8s or trivy config.
• SBOM file: use trivy sbom.
• VM image or filesystem archive: prefer image/rootfs modes when supported.

Ask only if the target is ambiguous and a wrong scan could be destructive or very slow. Otherwise choose the narrowest safe scan mode.

2. Install or Verify Trivy

trivy --version

If missing, recommend the official installation path for the user's OS. Avoid piping remote install scripts into a privileged shell unless the user explicitly approves.

3. Run a Baseline Scan

Use a read-only baseline first:

trivy fs --scanners vuln,secret,misconfig --severity HIGH,CRITICAL --ignore-unfixed .

For a container image:

trivy image --scanners vuln,secret,misconfig --severity HIGH,CRITICAL nginx:latest

For Kubernetes manifests:

trivy config --severity HIGH,CRITICAL ./deploy

For an unpacked Linux root filesystem:

trivy rootfs --severity HIGH,CRITICAL /mnt/rootfs

4. Produce Machine-Readable Output

Use JSON for triage automation:

trivy fs --format json --output trivy-results.json .

Use SARIF for GitHub code scanning:

trivy fs --format sarif --output trivy-results.sarif .

Generate an SBOM when the user needs inventory:

trivy fs --format cyclonedx --output sbom.cdx.json .
trivy image --format spdx-json --output image.spdx.json registry.example.com/app:tag

5. Triage Findings

For each HIGH or CRITICAL finding, capture:

• Package or dependency name.
• Installed version and fixed version.
• Vulnerability ID.
• Target path or image layer when available.
• Whether the finding is fixable.
• Runtime reachability or deployment exposure, if known.

Prioritize in this order:

1. Critical fixable vulnerabilities in internet-facing services.
2. High fixable vulnerabilities in runtime packages.
3. Secret findings with active credentials.
4. Misconfigurations that expose privilege escalation or public access.
5. License violations that affect distribution.

6. Remediate Safely

Common remediation moves:

• Upgrade base images to patched digests.
• Rebuild images after OS package updates.
• Upgrade direct dependencies before forcing transitive overrides.
• Remove unused OS packages from images.
• Replace broad Kubernetes permissions with least-privilege RBAC.
• Rotate leaked secrets before removing them from git history.
• Document accepted false positives with .trivyignore and an expiration date.

Common Patterns

CI Gate for Containers

name: trivy
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t app:${{ github.sha }} .
      - name: Scan image
        run: |
          trivy image \
            --exit-code 1 \
            --severity HIGH,CRITICAL \
            --ignore-unfixed \
            app:${{ github.sha }}

Repo Scan with SARIF Upload

- name: Trivy repo scan
  run: trivy fs --format sarif --output trivy.sarif .
- name: Upload SARIF
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: trivy.sarif

Ignore File with Expiration

# .trivyignore
# CVE accepted until 2026-06-30 because upstream has no fixed Alpine package.
CVE-2026-0000

Interpretation Rules

• Do not treat every CVE as equally exploitable.
• Vendor package status matters; Debian, Ubuntu, Red Hat, Alpine, and language ecosystems may report fixes differently.
• Prefer fixed-version and vendor advisory evidence over raw CVSS alone.
• Treat scanner output as a queue for triage, not as final proof of exploitability.
• Keep a record of accepted risks with owner, reason, and review date.

Boundaries

• Do not run destructive cleanup commands during scanning.
• Do not upload proprietary SBOMs or source metadata to third-party services without user approval.
• Do not suppress findings globally to make CI green.
• Do not claim a clean scan proves the system is secure.
• Do not scan production Kubernetes clusters with broad permissions unless the user has authorized that scope.

Reference Sources

• Trivy docs: https://trivy.dev/latest/docs/
• Vulnerability scanning: https://trivy.dev/docs/latest/scanner/vulnerability/
• Secret scanning: https://www.trivy.dev/docs/v0.55/guide/scanner/secret/
• License scanning: https://www.trivy.dev/docs/latest/scanner/license/