Trivy vs SonarQube: Two Security Tools That Belong in the Same Pipeline

If you ask a DevOps engineer "should I use Trivy or SonarQube?" you'll often get a confused look. The question assumes they're competing for the same job. They're not. Trivy scans what you deploy — container images, filesystems, infrastructure-as-code — for known vulnerabilities. SonarQube scans what you write — source code — for bugs, security flaws, code smells, and technical debt. Most teams that take security seriously eventually run both.

This post covers what each tool does, where they overlap, how to deploy each, and when running both makes sense.

Trivy — scanning what you deploy

Trivy is an open-source security scanner by Aqua Security. It's the most-starred open-source security scanner on GitHub with 36,500+ stars, under Apache 2.0, and the current stable release is v0.71.0 (June 2026). It's the default scanner in Harbor, RedHat certified, and used by default in countless CI/CD pipelines.

The core design: a single Go binary with no agents, no database to manage, no server to run. Point it at a target, get results. The vulnerability database downloads and caches automatically (~50MB), updated every six hours from NVD, OS vendor advisories, and language-specific advisories.

What Trivy scans

Trivy covers eight target types with four scanner engines:

Targets: container images (Docker, OCI), filesystems, Git repositories, VM images (AWS AMI, Azure VM), Kubernetes clusters, and SBOMs.

Scanner engines:

• Vulnerabilities — OS packages (Alpine, Debian, Ubuntu, RHEL, Amazon Linux) and application dependencies (Python, npm, Go modules, Java, Rust, PHP, Ruby)
• Misconfigurations — IaC files: Terraform (absorbed tfsec in 2023), CloudFormation, Kubernetes YAML, Dockerfiles, Helm charts
• Secrets — hardcoded API keys, passwords, tokens in code and config files
• Licenses — open source license compliance across dependencies

Trivy in CI/CD

The most common pattern: scan every image build and fail the pipeline on CRITICAL or HIGH findings:

# Scan a container image
trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:latest

# Scan a filesystem (source code + dependencies)
trivy fs --severity HIGH,CRITICAL --exit-code 1 .

# Scan IaC files
trivy config --severity HIGH,CRITICAL ./terraform/

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

# Generate an SBOM
trivy image --format cyclonedx --output sbom.json myapp:latest

In GitHub Actions:

- name: Scan image with Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myapp:latest
    format: sarif
    output: trivy-results.sarif
    severity: HIGH,CRITICAL
    exit-code: 1

Trivy also ships a Kubernetes Operator (via Helm) for continuous cluster scanning — it runs as a controller, scans workloads, and stores results as Kubernetes CRDs you can query or surface in a dashboard.

What Trivy is NOT

Trivy doesn't analyze your source code logic. It won't find SQL injection, XSS, or logic bugs in your application code — it finds CVEs in packages and misconfigurations in IaC. It doesn't track code quality, technical debt, or test coverage. These are not gaps; they're design choices for a different scope.

SonarQube — scanning what you write

SonarQube is an open-core code quality and SAST platform by SonarSource, used by 7 million+ developers at organizations including Snowflake, Deutsche Bank, and Ford. The free tier is Community Build (LGPL-3.0, ~10,700 GitHub stars), covering 20+ languages. Commercial editions add branch analysis, taint analysis, PR decoration, and more. Current release: SonarQube Server 2026.2 (March 2026).

Where Trivy scans build artifacts and infrastructure, SonarQube scans source code. It performs static analysis — reading your code without executing it — to find bugs, security hotspots, code smells, duplications, and maintainability issues.

What SonarQube analyzes

• Bugs — code that will likely cause runtime failures: null dereferences, resource leaks, incorrect API usage
• Security hotspots — code that might be a vulnerability and needs human review
• SAST — actual security vulnerabilities: SQL injection, XSS, insecure deserialization (paid tiers add taint analysis for cross-method data flow tracking)
• Code smells — maintainability issues: overly complex methods, duplicated code, poor naming, technical debt
• Secrets detection — 400+ patterns for API keys, passwords, tokens committed in code
• Coverage — test coverage integration to enforce minimum thresholds
• Duplications — copy-pasted code across the codebase

Quality Gates

SonarQube's most powerful CI/CD integration feature is the Quality Gate — a pass/fail check with configurable conditions. Define: "fail if new code has any CRITICAL security hotspot, or coverage drops below 80%, or technical debt ratio exceeds 5%." The gate blocks merges when conditions aren't met.

# sonar-project.properties
sonar.projectKey=myapp
sonar.sources=src
sonar.tests=test
sonar.coverage.exclusions=**/*.test.js
sonar.host.url=https://sonar.example.com

Self-hosting SonarQube

SonarQube Community Build runs on Docker Compose with PostgreSQL. Note: it requires Elasticsearch internally, which needs vm.max_map_count set on the host:

sudo sysctl -w vm.max_map_count=524288

services:
  sonarqube:
    image: sonarqube:community
    depends_on:
      - db
    environment:
      SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonarqube
      SONAR_JDBC_USERNAME: sonar
      SONAR_JDBC_PASSWORD: ${SONAR_PASSWORD}
    ports:
      - "9000:9000"
    volumes:
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions

  db:
    image: postgres:16
    environment:
      POSTGRES_USER: sonar
      POSTGRES_PASSWORD: ${SONAR_PASSWORD}
      POSTGRES_DB: sonarqube

Minimum requirements: 2 CPU cores, 4GB RAM (Elasticsearch is hungry). This is significantly heavier than Trivy's single binary with no server.

What SonarQube is NOT

SonarQube doesn't scan container images for CVEs. It doesn't check OS packages or application dependency vulnerabilities (that's CVE scanning — Trivy's domain). The Community Build doesn't include taint analysis (cross-method data flow) or PR decoration — those require paid editions.

Where they overlap

There is genuine overlap in two areas, worth understanding before choosing:

Secrets detection — both tools detect hardcoded secrets. Trivy's secrets scanner finds secrets in container images, filesystems, and Git repos. SonarQube's secrets detection (in Server editions) finds secrets in source code with 400+ patterns. If you're running both, you get double coverage — which is fine, but don't assume one replaces the other.

IaC security — Trivy's misconfiguration scanner checks Terraform, CloudFormation, and Kubernetes manifests for security issues. SonarQube (paid) also analyzes IaC files. For open source setups, Trivy covers this; SonarQube Community focuses on application code.

Dependency vulnerabilities — Trivy scans manifest files (package.json, requirements.txt, go.sum) for known CVEs. SonarQube Advanced Security (paid add-on, 2025) added SCA for dependency vulnerability detection. In practice for free tiers: Trivy is the dependency CVE scanner; SonarQube focuses on code quality.

Trivy vs SonarQube — side by side

When to use each

Use Trivy if:

• You need to scan container images for CVEs before deployment
• You want fast, zero-infrastructure security scanning in CI/CD
• You're scanning IaC (Terraform, Kubernetes YAML) for misconfigurations
• You need SBOM generation as part of supply chain security
• You want a single binary that scans images, filesystems, and code repos

Use SonarQube if:

• You want to enforce code quality standards (coverage, duplications, technical debt)
• You need SAST on source code — SQL injection, XSS, insecure patterns
• You want Quality Gates blocking PRs that degrade code quality
• Your team needs a persistent dashboard of code health over time
• You need compliance reporting (OWASP, CWE, NIST SSDF)

Use both: For any team serious about DevSecOps in 2026, the honest answer is both. Trivy gates deployment on known CVEs; SonarQube gates merges on code quality and security patterns. They operate at different points in the pipeline and catch different classes of problems. The overlap (secrets, IaC) is additive, not redundant.

A practical DevSecOps pipeline

A complete open source security scanning pipeline using both tools:

# Stage 1: Code commit — SonarQube in CI
- Run SonarScanner on source code
- Quality Gate blocks merge if: CRITICAL security hotspot, coverage < 80%

# Stage 2: Image build — Trivy on the artifact
- trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:$TAG
- Fails build if image has unfixed critical CVEs

# Stage 3: IaC — Trivy on config
- trivy config --severity HIGH,CRITICAL ./terraform/
- trivy config ./kubernetes/

# Stage 4: Continuous — Trivy Operator in cluster
- Trivy Operator scans running workloads continuously
- Results stored as Kubernetes CRDs, surfaced in dashboard

This pipeline covers: code quality and SAST (SonarQube), container CVEs and IaC misconfigs (Trivy at build), and continuous cluster posture (Trivy Operator).

My take

The "Trivy vs SonarQube" framing is a false choice that comes from treating security scanning as a monolithic concern. They're different tools for different layers: Trivy operates at the infrastructure and artifact layer (what runs in production), SonarQube operates at the source code layer (what developers write).

If budget and complexity allow only one: start with Trivy. A single binary, no server, no maintenance overhead, and scanning every container image before deployment for known CVEs is the highest-ROI security investment most teams can make. Then add SonarQube's Community Build when you want to enforce code quality and catch security patterns at the source.

Trivy is operationally free to run. SonarQube Community Build is also free but carries the overhead of a PostgreSQL + Elasticsearch stack. Both are worth it. Most mature DevOps teams run both — they just didn't frame it as a choice.