KCSA — Trivy — Vulnerability Scanning

6 minute read

Trivy — Vulnerability Scanning

Before a container image reaches production, it must be scanned for known vulnerabilities. Before infrastructure-as-code is applied, it must be checked for misconfigurations. Before a dependency is imported, it should be verified against vulnerability databases. Trivy does all of this in a single tool.

What Is Trivy?

Trivy is an open-source, all-in-one security scanner created by Aqua Security. It is one of the most widely adopted vulnerability scanners in the cloud native ecosystem and is commonly referenced in KCSA exam content.

Key characteristics:

  • All-in-one scanner — covers images, filesystems, IaC, Kubernetes, SBOM, and more
  • Fast and simple — single binary, no database server required
  • Comprehensive vulnerability database — aggregates data from NVD, OS vendors, language-specific databases
  • Shift-left friendly — runs locally, in CI/CD pipelines, and in-cluster
  • Open source — Apache 2.0 license, active community

Trivy scans for two distinct categories of issues: vulnerabilities (known CVEs in packages) and misconfigurations (insecure settings in IaC/Kubernetes manifests).

Trivy Scanning Targets

Trivy is not limited to container images — it can scan six different target types:

Target What It Scans Typical Use Case
Container Image OS packages and language-specific dependencies (npm, pip, gem, etc.) CI/CD pipeline, registry scanning
Filesystem Local project files and dependencies on disk Developer workstation, pre-commit checks
Git Repository Remote repository contents Pre-merge scanning, PR checks
Kubernetes Running cluster resources (pods, deployments, configmaps) Runtime misconfiguration detection
IaC Terraform, CloudFormation, Dockerfile, Kubernetes YAML, Helm charts Shift-left security, infrastructure review
SBOM Existing Software Bill of Materials documents (CycloneDX, SPDX) Supply chain security, compliance

Command Examples (Conceptual)

# Scan a container image
trivy image nginx:1.25

# Scan a local filesystem
trivy fs ./my-project

# Scan a remote Git repository
trivy repo https://github.com/example/app

# Scan IaC files (Terraform, Dockerfile)
trivy config ./terraform/

# Scan a running Kubernetes cluster
trivy k8s --report summary

# Scan an existing SBOM document
trivy sbom ./sbom.cdx.json

The KCSA exam does not ask you to run these commands — but you must know what each target type scans and when you would use it.

Vulnerability Severity Levels

Trivy classifies discovered vulnerabilities using standard severity levels:

Severity CVSS Score Range Description Action
CRITICAL 9.0–10.0 Easily exploitable, severe impact Fix immediately — block deployment
HIGH 7.0–8.9 Significant risk, likely exploitable Fix before production
MEDIUM 4.0–6.9 Moderate risk, context-dependent Plan remediation
LOW 0.1–3.9 Minor risk, limited impact Fix when convenient
UNKNOWN N/A Severity not yet assigned by vendor Investigate manually

CVSS Scoring — Brief Overview

The Common Vulnerability Scoring System (CVSS) is an industry standard for rating the severity of security vulnerabilities. It considers:

  • Attack Vector — Network, Adjacent, Local, Physical
  • Attack Complexity — Low, High
  • Privileges Required — None, Low, High
  • User Interaction — None, Required
  • Impact — Confidentiality, Integrity, Availability

For the KCSA exam, you don’t need to calculate CVSS scores — just know that CRITICAL and HIGH severity vulnerabilities should be prioritized for remediation, and that CVSS provides an objective scoring framework.

Trivy Output Format

Trivy produces detailed scan results in multiple formats:

Format Flag Use Case
Table --format table (default) Human-readable terminal output
JSON --format json Machine-readable, CI/CD integration
SARIF --format sarif GitHub Security tab integration
CycloneDX --format cyclonedx SBOM generation
SPDX --format spdx-json SBOM generation (SPDX standard)
Template --format template Custom HTML/Markdown reports

Sample Table Output

nginx:1.25 (debian 12.2)
=========================
Total: 85 (UNKNOWN: 0, LOW: 52, MEDIUM: 22, HIGH: 9, CRITICAL: 2)

┌──────────────┬──────────────────┬──────────┬────────────────┬──────────────────┐
│   Library    │  Vulnerability   │ Severity │ Installed Ver  │   Fixed Version  │
├──────────────┼──────────────────┼──────────┼────────────────┼──────────────────┤
│ libssl3      │ CVE-2024-XXXXX   │ CRITICAL │ 3.0.11-1       │ 3.0.13-1         │
│ curl         │ CVE-2024-YYYYY   │ HIGH     │ 7.88.1-10      │ 7.88.1-10+deb12u5│
│ zlib1g       │ CVE-2023-ZZZZZ   │ MEDIUM   │ 1:1.2.13       │                  │
└──────────────┴──────────────────┴──────────┴────────────────┴──────────────────┘

Trivy in CI/CD Pipelines

Integrating Trivy into CI/CD pipelines is one of the most common use cases — it catches vulnerabilities before images reach production.

GitHub Actions Example

name: Security Scan
on: push

jobs:
  trivy-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myapp:$ .
      - name: Trivy vulnerability scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:$
          format: sarif
          output: trivy-results.sarif
          severity: CRITICAL,HIGH
          exit-code: 1    # Fail the pipeline on findings
      - name: Upload to GitHub Security
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-results.sarif

GitLab CI Example

trivy-scan:
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity CRITICAL,HIGH myapp:latest
  allow_failure: false

Key Integration Patterns

Pattern Description
Gate on severity Fail the pipeline only if CRITICAL or HIGH vulnerabilities are found
SARIF upload Push results to GitHub Security tab for centralized tracking
Scan on PR Run Trivy on pull requests to catch issues before merge
Registry scanning Scan images in the container registry on a schedule
SBOM generation Generate CycloneDX/SPDX output as a build artifact

Shift-left means finding vulnerabilities as early as possible — ideally when a developer pushes code, not after deployment.

Trivy Operator for Kubernetes

The Trivy Operator (formerly Starboard) runs inside a Kubernetes cluster and performs continuous security scanning:

  • Automatically scans workloads when they are deployed or updated
  • Stores results as Kubernetes Custom Resources (VulnerabilityReport, ConfigAuditReport)
  • Can scan images, check configurations, and generate compliance reports

How It Works

Workload deployed → Trivy Operator detects → Scans image and config →
  → Creates VulnerabilityReport CR → Queryable via kubectl

# View vulnerability reports (conceptual)
kubectl get vulnerabilityreports -A
kubectl get configauditreports -A
Resource What It Contains
VulnerabilityReport CVEs found in container images
ConfigAuditReport Misconfigurations in workload specs (missing security context, etc.)
ExposedSecretReport Hardcoded secrets found in images
RbacAssessmentReport RBAC configuration issues

The Trivy Operator brings Trivy’s scanning capabilities into the cluster as a Kubernetes-native operator, making results queryable through the Kubernetes API.

Trivy vs Other Scanners

The KCSA exam may reference multiple scanning tools. Here is how they compare:

Feature Trivy Grype Snyk Clair
Creator Aqua Security Anchore Snyk Ltd Red Hat / Quay
License Apache 2.0 Apache 2.0 Proprietary (free tier) Apache 2.0
Image scanning Yes Yes Yes Yes
IaC scanning Yes No Yes No
Filesystem scanning Yes Yes Yes No
Kubernetes scanning Yes (in-cluster) No Yes No
SBOM generation Yes No (uses SBOMs) No No
SBOM scanning Yes Yes No No
CI/CD integration Excellent Good Excellent Moderate
Speed Fast Fast Moderate Moderate
Offline mode Yes Yes No Yes

For the KCSA exam: Trivy is the most frequently referenced scanner because of its breadth (images + IaC + Kubernetes + SBOM). Know that Grype focuses on vulnerability scanning using SBOMs, Snyk is commercial with a developer focus, and Clair is a container image scanner integrated with Quay registries.

Ignoring False Positives

Not every vulnerability finding is actionable. Trivy supports a .trivyignore file to suppress known false positives or accepted risks:

# .trivyignore — suppress specific CVEs
# Accepted risk: low severity, no network exposure
CVE-2023-12345

# Will not be fixed upstream — mitigated by network policy
CVE-2024-67890

# Disputed vulnerability
CVE-2023-11111

Always document why a vulnerability is being ignored. Suppressing findings without justification creates a false sense of security.

SBOM — Software Bill of Materials

Trivy can both generate and scan SBOMs, which are increasingly important for supply chain security:

SBOM Format Standard Body Use Case
CycloneDX OWASP Rich vulnerability and dependency data
SPDX Linux Foundation License compliance and provenance 
# Generate an SBOM from an image (conceptual)
trivy image --format cyclonedx --output sbom.cdx.json nginx:1.25

# Scan an existing SBOM for vulnerabilities
trivy sbom sbom.cdx.json

An SBOM is like an ingredient list for your software — it lists every library, package, and dependency included in an artifact. This is critical for responding quickly when a new vulnerability (like Log4Shell) is disclosed.

Key Takeaways for the Exam

  1. Trivy is an all-in-one scanner — it scans images, filesystems, Git repos, Kubernetes clusters, IaC files, and SBOMs
  2. Severity levels — CRITICAL, HIGH, MEDIUM, LOW, UNKNOWN — based on CVSS scores
  3. Shift-left — integrate Trivy into CI/CD pipelines to catch vulnerabilities before production
  4. Trivy Operator runs in-cluster and stores results as Kubernetes Custom Resources (VulnerabilityReport, ConfigAuditReport)
  5. Trivy scans for both vulnerabilities and misconfigurations — two distinct issue categories
  6. SBOM support — Trivy generates CycloneDX/SPDX SBOMs and scans existing SBOMs
  7. .trivyignore suppresses accepted risks — always document the reason
  8. Compared to Grype/Snyk/Clair — Trivy is the broadest all-in-one open-source option
  9. Trivy does NOT enforce policy — it reports findings. Use OPA/Kyverno to block deployments based on scan results

Next: OPA & Kyverno — Policy Enforcement

Updated:

You may also enjoy