Container Image Scanning: Trivy vs Snyk vs Grype -Which Scanner Should You Use? 🔍

You’re shipping vulnerabilities to production right now. The question is whether you know which ones.

• Every container image you ship contains software.
• That software has dependencies.
• Those dependencies have known vulnerabilities, CVEs documented in public databases, with severity scores, exploit availability, and patch availability all catalogued.
• Container image scanners compare everything in your image against those databases and tell you what’s vulnerable.
• The three most widely used in DevOps teams today are Trivy, Snyk, and Grype. They all do this core job.
• They differ significantly in how they do it, what they find, how they integrate, and what they cost

🧪 What Image Scanners Actually Do

Before comparing tools, understand what they’re scanning:

• OS packages → packages installed via apt, yum, apk, the base image layer
• Language dependencies → npm packages, pip packages, Maven artifacts, Go modules — your application layer
• Binaries → compiled executables that contain embedded libraries
• License compliance → which open-source licenses are in use (some scanners only)
• Secrets → hardcoded credentials, API keys, tokens (some scanners only)
• Misconfigurations → Dockerfile problems, insecure settings (some scanners only)

The coverage varies by scanner.

A “vulnerability found in Trivy but not Grype” isn’t always a Grype miss, it might be a different CVE database, a different confidence threshold, or a different interpretation of whether a vulnerability is exploitable in that context.

🔬 Trivy — The Free Standard

Trivy by Aqua Security has become the de facto standard for open-source container scanning. It’s fast, comprehensive, actively maintained, and has zero cost.

What Trivy scans:

• OS packages (Alpine, Debian, Ubuntu, RHEL, CentOS, Amazon Linux, and more)
• Language packages (Node.js, Python, Ruby, PHP, Java, Go, Rust, .NET)
• Container images, filesystems, Git repos, Kubernetes clusters, IaC files
• Secrets: hardcoded credentials, API keys, tokens
• Misconfigurations in Dockerfiles, Kubernetes manifests, Terraform, Helm

Vulnerability databases Trivy uses:

• NVD (National Vulnerability Database)
• GitHub Security Advisories
• OS-specific advisories (Alpine SecDB, Debian Security Tracker, Ubuntu CVE Tracker, Red Hat, etc.)
• Language-specific databases (npm advisory, PyPI advisory, RustSec, etc.)

Installing and Using Trivy

# macOS
brew install aquasecurity/trivy/trivy

# Linux
curl -sfL <https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh> | sh -s -- -b /usr/local/bin
# Verify
trivy --version

# Scan a public image
trivy image nginx:latest

# Scan your own image
trivy image myregistry.io/myapp:v2.0.0

# Scan only HIGH and CRITICAL - filter the noise
trivy image --severity HIGH,CRITICAL myapp:v2.0.0

# Fail the build if CRITICAL vulnerabilities found (CI/CD use)
trivy image --exit-code 1 --severity CRITICAL myapp:v2.0.0

# Ignore unfixed vulnerabilities (only show what has a patch available)
trivy image --ignore-unfixed myapp:v2.0.0

# JSON output for processing
trivy image --format json --output results.json myapp:v2.0.0

# Scan a tarball (useful in air-gapped environments)
docker save myapp:v2.0.0 -o myapp.tar
trivy image --input myapp.tar

# Scan a local filesystem (your application directory)
trivy fs ./

# Scan Kubernetes manifests and Helm charts
trivy config ./kubernetes/
trivy config ./helm/myapp/

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

Sample output:

myapp:v2.0.0 (debian 11.6)
====================================
Total: 47 (HIGH: 12, CRITICAL: 3)
┌────────────────┬───────────────┬──────────┬───────────────────┬──────────────────┬──────────────────────────────────────────┐
│    Library     │ Vulnerability │ Severity │ Installed Version │  Fixed Version   │                  Title                   │
├────────────────┼───────────────┼──────────┼───────────────────┼──────────────────┼──────────────────────────────────────────┤
│ openssl        │ CVE-2023-0286 │ CRITICAL │ 1.1.1n-0+deb11u3  │ 1.1.1n-0+deb11u4 │ X.400 address type confusion in X.509    │
│ zlib1g         │ CVE-2022-37434│ CRITICAL │ 1:1.2.11.dfsg-2   │ 1:1.2.11.dfsg-2+deb11u2 │ heap-based buffer over-read       │
│ libssl1.1      │ CVE-2023-0464 │ HIGH     │ 1.1.1n-0+deb11u3  │ 1.1.1n-0+deb11u4 │ Excessive Resource Usage Verifying...    │
└────────────────┴───────────────┴──────────┴───────────────────┴──────────────────┴──────────────────────────────────────────┘

Trivy in GitHub Actions

# .github/workflows/security.yml
name: Container Security Scan

on:
  push:
    branches: [main, develop]
  pull_request:
jobs:
  trivy-scan:
    runs-on: ubuntu-latest
    permissions:
      security-events: write    # Required to upload SARIF results
      contents: read

    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          format: sarif
          output: trivy-results.sarif
          severity: CRITICAL,HIGH
          exit-code: 1
          ignore-unfixed: true    # Only fail on patchable vulns

      - name: Upload results to GitHub Security tab
        uses: github/codeql-action/upload-sarif@v3
        if: always()             # Upload even if scan found issues
        with:

          sarif_file: trivy-results.sarif
      # Also scan IaC at the same time
      - name: Scan Kubernetes manifests
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: config
          scan-ref: kubernetes/
          severity: CRITICAL,HIGH

Trivy .trivyignore — Suppressing False Positives

# .trivyignore — add CVEs you've triaged and accepted
# Format: one CVE per line, optionally with expiry date

# This CVE doesn't affect our usage pattern - reviewed 2026-01-15
CVE-2023-1234

# Not exploitable in our Alpine image - expires 2026-06-01
CVE-2023-5678 exp:2026-06-01

# Accepted risk for this specific library
CVE-2022-9999

Trivy strengths:

• Free and open source, no license cost at any scale
• Broadest scan coverage (images, filesystems, Git repos, IaC, clusters)
• Actively maintained with frequent DB updates
• Fast — typically 10–30 seconds for a medium image
• Integrates with every CI/CD platform
• Finds secrets and misconfigurations alongside CVEs

Trivy limitations:

• No SLA on vulnerability database updates (community-driven)
• No developer workflow (no PR comments, no fix PRs)
• False positive management is manual (.trivyignore file)
• No license compliance scanning

💼 Snyk — The Developer-First Platform

Snyk takes a different philosophy: instead of just reporting vulnerabilities, it integrates into the developer workflow, explains vulnerabilities in context, and helps fix them. It’s a commercial product with a free tier.

What Snyk scans:

• Container images (OS + language packages)
• Open source dependencies (separate product: Snyk Open Source)
• Infrastructure as code (separate product: Snyk IaC)
• Application code with SAST (separate product: Snyk Code)

What makes Snyk different from Trivy and Grype:

• Snyk Intelligence -their proprietary vulnerability database that curates NVD data, adds exploitability context, and reduces noise
• Fix PRs -Snyk can automatically open pull requests to update vulnerable dependencies
• Developer portal: vulnerability dashboards, team reporting, SLA tracking
• IDE plugins: shows vulnerabilities in VS Code, IntelliJ as you code
• Runtime monitoring: tracks what’s deployed and alerts on newly published CVEs

Installing and Using Snyk CLI

# Install
npm install -g snyk
# Or: brew install snyk-cli

# Authenticate
snyk auth

# Scan a container image
snyk container test myapp:v2.0.0

# Scan with more detail
snyk container test myapp:v2.0.0 --file=Dockerfile

# Fail only on high severity
snyk container test myapp:v2.0.0 --severity-threshold=high

# Monitor the image (track in Snyk dashboard, alert on new CVEs)
snyk container monitor myapp:v2.0.0 --project-name=myapp-production

# Scan your local filesystem for dependency vulnerabilities
snyk test

# Get a JSON report
snyk container test myapp:v2.0.0 --json > snyk-results.json

Snyk’s output is more curated:

Testing myapp:v2.0.0...

✗ High severity vulnerability found in openssl
  Description: Improper Input Validation
  Info: <https://snyk.io/vuln/SNYK-DEBIAN11-OPENSSL-3257921>
  Introduced through: openssl@1.1.1n-0+deb11u3
  Fixed in: 1.1.1n-0+deb11u4

  This vulnerability affects your OpenSSL installation. Given your
  image is a web service, this could be exploitable via TLS connections.
  Upgrade to fix.

✗ Medium severity vulnerability found in libgcrypt20
  Description: Information Exposure
  Info: <https://snyk.io/vuln/SNYK-DEBIAN11-LIBGCRYPT20-3110143>
  Introduced through: gnupg2@2.2.27-2+deb11u2

  Low exploitability - this vulnerability requires local access.
  Consider as low priority.

Organization: myorg
Package manager: deb
Target file: Dockerfile
Project name: myapp
Docker image: myapp:v2.0.0
Licenses: enabled

Tested 128 dependencies for known issues, found 23 issues.

Snyk in GitHub Actions

- name: Snyk Container scan
  uses: snyk/actions/docker@master
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  with:
    image: myapp:${{ github.sha }}
    args: --severity-threshold=high --file=Dockerfile

- name: Upload Snyk results to GitHub Security tab
  uses: github/codeql-action/upload-sarif@v3
  if: always()
  with:
    sarif_file: snyk.sarif

Snyk Pricing Reality

Snyk has a free tier:

• Free: 200 tests/month for open source, unlimited for container scanning (with limitations)
• Team: $25/developer/month — removes test limits, adds reporting
• Business: $62/developer/month — adds SSO, custom policies, priority support
• Enterprise: custom pricing — dedicated support, SLAs, advanced integrations

For a 10-engineer team: $250–620/month. For a 50-engineer team: $1,250–3,100/month. This is the key factor in the Trivy vs Snyk decision.

Snyk strengths:

• Best developer experience, context, fix suggestions, IDE integration
• Exploitability scoring, prioritizes what actually matters
• Automatic fix PRs reduce remediation effort significantly
• Continuous monitoring alerts you when new CVEs affect deployed images
• License compliance scanning built in

Snyk limitations:

• Cost at scale is significant
• Free tier has meaningful limitations on CI/CD
• Requires sending image data to Snyk’s cloud (data sovereignty concern for some orgs)
• Over-reliance on it can make teams passive — waiting for Snyk to tell them what to fix

🦅 Grype — The Fast Challenger

Grype by Anchore is newer than Trivy but is gaining significant adoption. It’s fast, open source, and pairs naturally with Anchore’s SBOM tool Syft.

What Grype scans:

• Container images and SBOMs (Software Bill of Materials)
• Filesystems and directories
• OCI archives

Vulnerability databases:

• NVD
• GitHub Security Advisories
• OS-specific: Alpine, Debian, Ubuntu, RHEL, CentOS, Amazon Linux
• Language: npm, PyPI, Maven, RubyGems, NuGet, Go

Installing and Using Grype

# macOS
brew install anchore/grype/grype

# Linux
curl -sSfL <https://raw.githubusercontent.com/anchore/grype/main/install.sh> | sh -s -- -b /usr/local/bin

# Scan an image
grype myapp:v2.0.0

# Filter severity
grype myapp:v2.0.0 --fail-on critical

# Only fixed vulnerabilities
grype myapp:v2.0.0 --only-fixed

# JSON output
grype myapp:v2.0.0 -o json > results.json

# Template output (custom formats)
grype myapp:v2.0.0 -o template -t my-template.tmpl

Grype + Syft: The SBOM Workflow

Grype’s biggest differentiator is its first-class SBOM (Software Bill of Materials) support.

Instead of scanning the image directly each time, you generate an SBOM once and scan that, faster, and the SBOM becomes a reusable artifact you can store and re-scan against future vulnerability databases.

# Install Syft (SBOM generator from the same team)
brew install anchore/syft/syft

# Generate SBOM from image
syft myapp:v2.0.0 -o spdx-json > myapp-sbom.spdx.json

# Now scan the SBOM - no image pull required
grype sbom:./myapp-sbom.spdx.json

# Store the SBOM with your build artifacts:
# - Attach to GitHub Release

# - Push to OCI registry alongside the image
# - Archive in S3

# Re-scan tomorrow against updated vulnerability DB without rebuilding
grype sbom:./myapp-sbom.spdx.json

This workflow is increasingly important for supply chain security compliance (SLSA, SSDF, executive orders on software supply chain).

Grype in GitHub Actions

- name: Run Grype scanner
  uses: anchore/scan-action@v3
  with:
    image: myapp:${{ github.sha }}
    severity-cutoff: critical
    fail-build: true
    only-fixed: true

- name: Upload Grype results
  uses: github/codeql-action/upload-sarif@v3
  if: always()
  with:
    sarif_file: results.sarif

Grype Configuration File

# .grype.yaml — project-level configuration
ignore:
  # Ignore specific CVEs
  - vulnerability: CVE-2023-1234
    reason: "Not exploitable in our Alpine configuration"

  # Ignore vulnerabilities in specific packages
  - package:
      name: libssl1.1
      version: 1.1.1n-0+deb11u3
    vulnerability: CVE-2023-0464
    reason: "Reviewed, not exploitable in our context"

  # Ignore everything below high
  - fix-state: not-fixed   # Only care about fixable vulns

fail-on-severity: critical
only-fixed: true
output: sarif

Grype strengths:

• Free and open source
• First-class SBOM support, generates and consumes SBOMs natively
• Fast, comparable to Trivy, sometimes faster
• Clean, simple CLI with good defaults
• Works well with Anchore Enterprise if you need commercial features later

Grype limitations:

• Smaller community than Trivy
• No IaC or secret scanning
• No developer platform (just a scanner, not a full workflow tool)
• Less battle-tested in large-scale production environments than Trivy

⚡ Head-to-Head: Practical Comparison

Detection Accuracy

Independent testing consistently shows all three tools finding similar numbers of vulnerabilities on the same images, with variation mainly in:

• Edge cases in language ecosystems → Grype and Trivy sometimes differ on transitive Go dependencies; Snyk sometimes finds language vulns the others miss
• Proprietary CVEs → Snyk adds their own intelligence on top of NVD, sometimes surfacing issues others miss
• False positives → Snyk has lower false positive rates due to exploitability scoring; Trivy and Grype report everything in the database regardless of exploitability

Speed (approximate, 200MB image)

• Trivy: 15–40 seconds (first run downloads DB; subsequent runs use cache)
• Grype: 10–30 seconds (similar caching behavior)
• Snyk: 20–60 seconds (sends to Snyk’s API; network-dependent)

All three are fast enough for CI/CD. Speed is not a meaningful differentiator.

False Positive Rate

This matters enormously in practice. High false positive rates create alert fatigue, and alert fatigue means real vulnerabilities get ignored.

Factors affecting false positives:

• Trivy and Grype: Report all CVEs in their databases. CVEs that are “disputed,” “not affecting this OS,” or “not exploitable in this context” still appear. Teams must maintain ignore lists.
• Snyk: Applies exploitability scoring and contextual analysis. Reports fewer total findings, but the findings they do report are generally more actionable.

For a typical production image, expect:

• Trivy/Grype: 30–100+ findings on a non-hardened image, many LOW or MEDIUM with no fix
• Snyk: 15–50 findings, with priority scoring that highlights what to fix first

CI/CD Integration Depth

• Trivy: Native GitHub Actions action, GitLab template, Jenkins plugin, pre-built integrations everywhere.
• SARIF output supported. Works in any pipeline with the CLI.
• Snyk: Deepest integration — PR comments, fix suggestions, branch policies, IDE plugins, dashboard. More setup required.
• Grype: Clean CLI, GitHub Actions action, SARIF output. Less native integration depth than Trivy.

Cost at Scale

• Trivy: Free at any scale
• Grype: Free at any scale
• Snyk: Free tier (200 tests/month), then $25–62/developer/month

🎯 Which to Choose

Choose Trivy if:

• You want zero cost at any scale
• You need to scan more than just images (IaC, filesystems, Kubernetes clusters)
• Your team can maintain an ignore list to manage false positives
• You want the broadest community support and integrations
• You’re starting a DevSecOps practice and want maximum coverage

Choose Snyk if:

• Developer experience is the priority — you want to meet developers where they are (IDE, PR comments)
• Your organization will pay for the tooling (budget approved, compliance requirement)
• You want automatic fix PRs to reduce remediation effort
• You need license compliance scanning alongside CVE scanning
• Continuous monitoring of production deployments is a requirement

Choose Grype if:

• You’re building a supply chain security practice and need SBOM-first workflows
• You want a simple, fast alternative to Trivy with excellent SBOM support
• You might eventually move to Anchore Enterprise for compliance use cases
• You prefer a smaller, more focused tool

Use more than one if:

• Trivy + Snyk is a common combination: Trivy for fast CI feedback on every build, Snyk for developer workflow and continuous monitoring
• Trivy + Grype catches the small percentage of CVEs where their databases differ

🔧 Recommended Setup for Most Teams

Small teams (1–10 engineers), budget-conscious:

# CI/CD: Trivy, strict mode
- name: Security scan
  run: |
    trivy image \\
      --exit-code 1 \\
      --severity CRITICAL \\
      --ignore-unfixed \\
      myapp:${{ github.sha }}

• CRITICAL with fix → block the build
• HIGH with fix → warn, allow merge, create ticket
• Anything without a fix → ignore (update base image regularly instead)

Mid-size teams (10–50 engineers), compliance requirements:

• Trivy in CI/CD for fast feedback on every build
• Snyk for developer workflow (IDE plugins, PR comments)
• Grype + Syft for SBOM generation attached to every release

Large teams (50+ engineers), enterprise:

• Snyk or Aqua Security (Trivy’s enterprise parent) for centralized reporting, policy enforcement, SLAs
• Trivy for local developer scanning (free, no token required)
• SBOM generation as a mandatory build artifact

Final Thoughts

• The “which scanner” decision matters less than the decision to actually implement scanning and act on the results.
• A team running Trivy in strict mode that actually patches CRITICAL vulnerabilities ships more securely than a team running Snyk Enterprise that dismisses everything as “low priority.”