Trivy and Grype: Container Image Scanning in CI

Actualizado: 2026-05-03

Container image scanning before deployment has moved from “good practice” to requirement in modern pipelines. Two open-source tools dominate this space: Trivy^[1] from Aqua Security and Grype^[2] from Anchore. Both do the basic job well, with subtle differences that matter depending on context.

Key takeaways

• Trivy and Grype cover over 95% of the same CVEs in typical scenarios; the real difference lies in ecosystem and speed.
• Trivy stands out for IaC scanning (Terraform, Kubernetes manifests) and better all-in-one integration.
• Grype shines when Syft is already used to generate SBOMs — the SBOM→scan pipeline is native.
• The biggest operational problem with both isn’t coverage but false-positive fatigue: .trivyignore and VEX are the answer.
• The important thing is to have at least one of them — both are better than none.

What Each Does

Both scan images (and more) against known-vulnerability databases. They detect:

• Vulnerable OS packages (apt, rpm, apk).
• Language dependencies with CVEs (npm, pip, gem, go.mod, Cargo).
• Problematic configuration files (insecure Dockerfile patterns, exposed Kubernetes manifests).
• SBOMs in various formats.

Output is a list of vulnerabilities with severity, affected package, and CVE ID.

Architecture Differences

Trivy

• Internal database Trivy DB^[3]: syncs from multiple sources (NVD, vendor advisories, GitHub Security Advisories).
• Compressed format (~50 MB), designed for offline scans.
• Supports images, local filesystems, git repos, and IaC (Terraform, CloudFormation, Kubernetes).
• Client-server mode for distributed scans.

Grype

• Database Vulnerability Database^[4]: compiled from similar sources.
• Uses Syft^[5] for SBOM generation (same team), making the SBOM→scan pipeline native.
• More modular: Syft generates the SBOM, Grype scans it, additional tools consume it.
• Supports SBOM attestations via cosign.

Coverage Compared

In tests over diverse images (alpine, debian, node, python, ruby):

• Both detect the vast majority of known CVEs in OS packages.
• Trivy usually catches more in language ecosystems through more direct lockfile integration.
• Grype excels on images with Syft-precomputed SBOMs, eliminating re-indexing.
• Both can give false positives from backported versions: the patch is applied but the version number remains the “vulnerable” one for the base CVE.

Coverage difference is less than 5% in typical scenarios. More relevant: database update speed and severity interpretation quality.

Performance

Benchmarks on a ~200 MB Python 3.11 image:

• Trivy: 3-5 seconds on first run with DB cache, <1s on subsequent runs.
• Grype: 4-6 seconds on first run, ~2s on subsequent runs.

For CI with large images (>1 GB, multi-stack), speed matters. With 50-100 builds/day, either is sufficient. For hundreds of builds/hour pipelines, Trivy is typically slightly faster.

CI Integration

Trivy in GitHub Actions

- name: Run Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'my-app:${{ github.sha }}'
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'

The exit-code: '1' flag fails the build if CRITICAL or HIGH is found. Integration with the GitHub Security tab^[6] via SARIF.

Grype in GitLab CI

scan_image:
  stage: test
  script:
    - grype my-app:$CI_COMMIT_SHA -o sarif > grype.sarif
    - grype my-app:$CI_COMMIT_SHA --fail-on high

Both integrate with SonarQube, DefectDojo, and other result aggregators.

False-Positive Handling

The most common operational problem: too many false positives generate fatigue and lead to ignoring real alerts. Two complementary approaches:

• .trivyignore^[7] (Trivy) or equivalent in Grype: explicitly list CVEs that don’t apply (patch applied, functionality not used).
• VEX (Vulnerability Exploitability eXchange): emerging format to declare which vulnerabilities are exploitable in the specific context. Both tools are actively adding support.

Maintaining these lists requires discipline: quarterly review to avoid accumulating stale suppressions that hide real problems.

Beyond Basic Scanning

Both tools go beyond CVEs:

• Policies and compliance: rules that fail builds if non-allowed base images are used or images exceed a size threshold.
• Licences: detecting dependencies with incompatible licences (GPL in a closed commercial product).
• Secrets: detecting API keys or credentials exposed in image layers (Trivy has --scanners secret).

For context on the broader defence layer, see supply-chain attacks and how to defend — scanning is one layer, not the only one. The complete chain includes SLSA Level 3 for attesting build provenance. Integrating these tools in Kubernetes 1.27 is complemented by admission controllers that verify attestations before admitting images.

Conclusion

Trivy and Grype are practically equivalent alternatives for image scanning. The difference usually lies in the broader ecosystem: if you already use Anchore/Syft, Grype fits naturally; if you want an all-in-one with better IaC integration, Trivy. The important thing is to have at least one integrated into the pipeline — either is better than none.

1. Trivy
2. Grype
3. Trivy DB
4. Vulnerability Database
5. Syft
6. GitHub Security tab
7. .trivyignore