A container image that looks clean on the surface can still ship a vulnerable OpenSSL library, an outdated Python package, or a hardcoded credential buried three layers deep. Catching that before it reaches production is the entire point of Trivy, the open-source scanner built by Aqua Security that has become a default choice for teams who need fast, free vulnerability scanning without standing up a dedicated security platform. This tutorial walks through installing Trivy v0.76.0 (released October 14, 2026), running your first scans, wiring the tool into GitHub Actions and GitLab CI, generating SBOMs, and deploying the Trivy Operator for continuous Kubernetes scanning. For broader context on how this fits into a security program, see our cybersecurity coverage.
By the end you will have a working pipeline that scans a real Dockerized application, fails the build on critical CVEs, and produces an SBOM you can hand to an auditor. Thirteen numbered steps, more than a dozen code examples, a full troubleshooting table, and a list of mistakes that trip up almost everyone on their first rollout.
What Trivy Does and Why It Matters for Container Security in 2026
Trivy started as a single-purpose container image scanner and has grown into what Aqua Security calls an all-in-one security scanner. The current release line on GitHub shows v0.76.0 shipping October 14, 2026, with v0.75.0 on October 1, v0.74.0 on August 14, and v0.73.0 on August 3. It covers five distinct scan targets: container images, filesystems, git repositories, Kubernetes clusters, and infrastructure-as-code files including Terraform. A single binary handles vulnerability detection, misconfiguration checks, secret detection, and software bill of materials (SBOM) generation, which is why so many teams replace three or four separate tools with one Trivy install.
The project is licensed under Apache 2.0, so there is no paywall between you and a working scanner. That matters in 2026 because container sprawl has outpaced most security budgets. Every microservice, every base image bump, and every third-party dependency is a fresh attack surface, and most organizations cannot afford a commercial scanner for every repository they own. Trivy’s zero-cost core removes that excuse. Aqua does sell commercial tooling built around the open-source scanner, but the CLI, the database, and the Kubernetes Operator all remain free and self-hostable.
Speed is the other reason Trivy keeps winning adoption. In one 2026 third-party scanner benchmark, Trivy finished test scans in roughly 0.1 to 0.3 seconds per image, noticeably faster than Grype’s 1 to 2.5 seconds on the same targets. The two tools found comparable numbers of vulnerabilities on standard images (16 versus 20 on alpine:3.20, 314 versus 315 on nginx:1.27), so the speed gap does not come at the cost of coverage. For a CI pipeline running hundreds of scans a day, shaving even a second off each job adds up fast.
Understanding Trivy’s Four Built-In Scanners
It helps to think of Trivy as four scanners wearing one jacket rather than a single-purpose tool. The vulnerability scanner is the one most people reach for first: it compares every package it finds, OS-level and language-level alike, against known CVE records and tells you which ones have a fix available. The misconfiguration scanner works differently. Instead of checking package versions, it walks structured files such as Dockerfiles, Kubernetes YAML, and Terraform against a built-in policy library and flags things a CVE database would never catch, like a container running as root or a storage bucket left publicly readable.
The third engine, secret detection, scans file contents and git history for patterns that look like API keys, private keys, or database connection strings. It is intentionally narrower than a dedicated secret-scanning tool, which is why teams that treat credential leaks as a top priority often layer a specialist on top rather than relying on Trivy alone. The fourth engine, license scanning, inspects package metadata and flags dependencies under licenses your legal team has blocked, such as certain copyleft terms that conflict with a closed-source product. Most Trivy commands run only the vulnerability scanner by default, so the other three need to be requested explicitly with the –scanners flag, something worth remembering the first time a scan comes back “clean” and still ships a hardcoded token.
Knowing which scanner produced a given finding also changes how you triage it. A vulnerability finding usually has a clear remediation path: bump the package version, rebuild, rescan. A misconfiguration finding often requires a design decision rather than a version bump, since fixing an overly broad IAM policy might mean rethinking how a service authenticates in the first place. Keeping that distinction in mind when a report lands in a pull request review saves a lot of back-and-forth between developers who expect every red flag to be solved with npm update.
Trivy vs Grype vs Docker Scout vs Snyk vs Clair: How They Stack Up
Before installing anything, it helps to know where Trivy sits relative to the other scanners you will hear about. Grype, built by Anchore, is the closest open-source peer and shares a similar philosophy: free, fast, and CLI-first. Docker Scout ships inside Docker Desktop and leans on Docker’s own ecosystem, with a freemium model that caps free scans per month. Snyk Container is a commercial platform with a generous free tier for individual developers but a licensing cost once you scale to a team. Clair, one of the oldest names in this space, is also Apache-2.0 but expects you to run a server and a Postgres database rather than a single binary, which raises the operational bar considerably.
| Tool | License / Pricing | Scan Targets | Infrastructure Needed | Relative Speed |
|---|---|---|---|---|
| Trivy | Apache 2.0, free | Images, filesystems, repos, IaC, Kubernetes, SBOM | Single binary, no server | Fastest in 2026 third-party benchmarks |
| Grype | Apache 2.0, free | Images, filesystems, SBOM | Single binary, no server | Fast, roughly 1-2.5s per scan in cited benchmark |
| Docker Scout | Freemium, capped free scans | Docker images, registries | Docker Desktop / Docker Hub account | Fast within Docker ecosystem |
| Snyk Container | Commercial, free tier for individuals | Images, IaC, code, open source deps | Snyk account, agent or CLI | Moderate, cloud-assisted |
| Clair | Apache 2.0, free | Registry images | Server + Postgres database | Depends on deployed infrastructure |
None of these tools is wrong, they just solve different problems. If your organization already runs an enterprise vulnerability management platform, a scanner like Trivy usually sits alongside it rather than replacing it. Our comparison of Tenable, Qualys, and Rapid7 covers that enterprise end of the market if you need infrastructure-wide scanning beyond containers. Trivy’s job is narrower and sharper: catch CVEs and misconfigurations in the software supply chain, fast, for free, without a procurement cycle.
The practical decision usually comes down to two questions: how much are you willing to run yourself, and does your team already live inside one vendor’s ecosystem. A shop already paying for Docker Business might get more immediate value from Docker Scout simply because it is already wired into the build step. A shop that wants a free, server-less scanner it can drop into any pipeline without touching procurement tends to land on Trivy or Grype. Clair is worth considering mainly if you are already running a registry-centric setup and have the operational appetite to maintain a database-backed service rather than a stateless binary. Snyk earns its commercial price tag with developer-facing remediation advice and IDE integrations that neither Trivy nor Grype attempt to match, which matters more for teams prioritizing fix velocity over raw scan cost.
Prerequisites: Tools, Accounts, and Versions You Will Need
This tutorial assumes a working knowledge of the command line and basic Docker usage. You do not need Kubernetes experience until Step 12, and you do not need a paid account anywhere in this guide. Here is exactly what to have ready before Step 1.
| Requirement | Minimum Version | Notes |
|---|---|---|
| Trivy | v0.76.0 | Released October 14, 2026, current as of this guide |
| Docker Engine | 24.x or newer | Needed for image scanning and the sample project |
| Git | 2.40 or newer | For repository scanning in Step 6 |
| kubectl | 1.30 or newer | Only needed for Step 12 (Trivy Operator) |
| Helm | 3.14 or newer | Used to install the Trivy Operator |
| GitHub or GitLab account | n/a | For the CI/CD steps (10 and 11) |
| Operating system | Linux, macOS, or Windows | Install method differs per OS, covered in Step 1 |
You will also want roughly 500MB of free disk space for the vulnerability database cache. Trivy stores this locally so repeated scans do not need to re-download data every time, which is exactly the kind of detail that trips people up in CI environments with ephemeral storage, something covered in the pitfalls section further down.
None of these requirements are exotic, and that is deliberate. Trivy was built to drop into an existing workflow rather than demand a new one. If you can already build a Docker image and push a commit, you already have everything Steps 1 through 11 need. Kubernetes and Helm only come into play once you reach Step 12, so skip ahead and come back to that section later if your current setup does not run on a cluster yet.
Step 1: Install Trivy on Linux, macOS, or Windows
Trivy ships official install paths for every major platform. On Debian or Ubuntu, add Aqua’s APT repository and install from there so you get automatic updates alongside your regular system packages.
sudo apt-get install -y wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo gpg --dearmor -o /usr/share/keyrings/trivy.gpg
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install -y trivyOn macOS, Homebrew is the fastest route and keeps Trivy current with a simple brew upgrade later.
brew install trivyOn Windows, Chocolatey is the simplest path if you already have it installed. If you do not, download the Windows zip directly from the project’s GitHub Releases page and add the extracted binary to your PATH.
choco install trivyIf you want a specific version pinned (useful for reproducible CI builds), the official install script accepts a version flag and drops the binary wherever you point it, which is the cleanest way to lock every pipeline to the same Trivy release.
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.76.0Prefer not to install anything locally at all? Aqua also publishes an official Docker image, which is handy for one-off scans on a machine you do not want to touch.
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy image nginx:1.27Step 2: Verify the Install and Download the Vulnerability Database
Confirm the binary landed correctly and check the version string against what you expect.
trivy --versionYou should see Version: 0.76.0 along with the Vulnerability DB version and timestamp. The first time you run any scan, Trivy pulls its vulnerability database from a public OCI registry. You can trigger that download on its own, which is useful if you want to warm the cache before a CI job runs and avoid a slow first scan.
trivy image --download-db-onlyThis database refreshes roughly every six hours upstream, and Trivy checks for updates automatically before each scan unless you pass –skip-db-update. Leave that flag off for your first few runs so you are always working against current CVE data.
Under the hood, Trivy pulls two separate artifacts: a vulnerability database and a Java-specific index used for deeper JAR and WAR inspection. Both are distributed as OCI artifacts rather than a traditional file download, which is why the download command looks like a container pull rather than a wget call. If your organization already runs its own OCI registry mirror for compliance reasons, the same mirror can host these artifacts, which is the foundation for the air-gapped setup covered later in the advanced tips section.
Step 3: Run Your First Container Image Scan
With the database in place, scan a real image. Nginx is a good first target because it is small, widely used, and almost always carries a handful of known CVEs in its base OS layer.
trivy image nginx:1.27Within a second or two you get a full table broken down by target (OS packages, then each language-specific lockfile Trivy finds inside the image), listing the package name, installed version, fixed version if one exists, severity, and a CVE identifier you can look up directly. A typical first scan on a general-purpose image turns up a mix of LOW, MEDIUM, HIGH, and the occasional CRITICAL finding, almost always concentrated in the base OS packages rather than the application code itself.
Step 4: Filter and Interpret Trivy’s Scan Output
A raw scan against a real-world image can return hundreds of findings, most of which you will never act on because no patch exists yet or the vulnerable code path is never executed. The first filter worth learning is severity.
trivy image --severity HIGH,CRITICAL nginx:1.27That alone cuts most result sets down to a manageable list. The second filter that matters is –ignore-unfixed, which drops any CVE for which no patched package version is currently available. Chasing a fix that does not exist yet wastes a team’s time, so most production pipelines run with both flags together.
trivy image --severity HIGH,CRITICAL --ignore-unfixed nginx:1.27For machine-readable output, add –format json or –format table (the default), and for anything feeding into another tool, JSON is the format you want piped downstream.
Step 5: Scan Filesystems and Local Project Directories
Not every scan target is a built container image. Trivy can walk a local directory and check every dependency manifest it finds, package-lock.json, requirements.txt, go.sum, Gemfile.lock, and dozens more, without you ever building a Docker image first. That makes it a fast pre-commit check.
trivy fs .Run from the root of a project, this scans every dependency file it finds recursively. It is the right tool to run inside a pre-commit hook or a lightweight local check before you even open a pull request, since it needs no Docker daemon and finishes in well under a second on most repositories.
Step 6: Scan Git Repositories Directly From a URL
Trivy can also clone and scan a remote git repository in one command, without you checking it out manually first. This is useful for auditing a dependency or a vendor’s code before you add it to your own stack.
trivy repo https://github.com/aquasecurity/trivy-test-images --branch mainUnder the hood this clones to a temporary directory and runs the same logic as trivy fs, so expect the same output format. Add –scanners vuln,secret to also check commit history and tracked files for leaked credentials in the same pass. If secret scanning is a bigger priority for your team than vulnerability scanning, our TruffleHog and Gitleaks setup guide covers dedicated secret-detection tooling in more depth than Trivy’s built-in secret scanner offers.
Step 7: Scan Dockerfiles and Terraform for Misconfigurations
Vulnerabilities are only half the picture. A perfectly patched container can still run as root, expose an unnecessary port, or mount a host volume it has no business touching. Trivy’s config scanner catches these misconfigurations in Dockerfiles, Kubernetes manifests, and Terraform, all through a single subcommand.
trivy config ./terraform-modulesPoint it at a Dockerfile and it flags things like missing USER directives, use of the latest tag, or exposed secrets baked into build arguments. Point it at a Terraform directory and it checks for overly permissive IAM policies, public S3 buckets, and security groups open to 0.0.0.0/0. The checks are based on a built-in policy set, and you can write custom Rego policies if your organization has rules Trivy does not ship out of the box.
Step 8: Generate an SBOM in CycloneDX and SPDX Formats
Software bills of materials have moved from nice-to-have to contractual requirement for a lot of enterprise buyers in 2026, especially in regulated industries. Trivy generates both of the two SBOM standards that matter, CycloneDX and SPDX, directly from an image scan.
trivy image --format cyclonedx --output sbom-cyclonedx.json myapp:latest
trivy image --format spdx-json --output sbom-spdx.json myapp:latestBoth files list every package Trivy detected, its version, and where applicable its license. Hand either one to a customer’s security team and you have answered the “what’s actually inside this container” question without a single manual spreadsheet. You can also feed an existing SBOM back into Trivy to check it against the current vulnerability database, which is handy when a new CVE drops and you need to know fast whether it touches anything you already shipped.
Step 9: Set Severity Thresholds and Exit Codes for CI Gating
A scan that just prints a report is informational. A scan that can fail a build is a control. The difference is the –exit-code flag, which tells Trivy to return a non-zero exit code when it finds a match for your chosen severity, something every CI system understands as a hard stop.
trivy image --severity CRITICAL --exit-code 1 --ignore-unfixed myapp:latestRun that in a build step and the pipeline stops the moment a critical, fixable CVE shows up. Teams that are new to scanning almost always start too strict, gating on every severity including LOW, and burn out their developers within a month. Start by gating on CRITICAL only, then tighten to HIGH and CRITICAL once the team has cleared its existing backlog of findings.
Step 10: Add Trivy to a GitHub Actions Workflow
Aqua maintains an official GitHub Action, trivy-action, that wraps the CLI and reports results as a workflow step. Drop this into .github/workflows/scan.yml and every push gets scanned automatically.
name: Container Scan
on: [push, pull_request]
jobs:
trivy-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build image
run: docker build -t myapp:ci .
- name: Run Trivy scan
uses: aquasecurity/trivy-action@master
with:
image-ref: myapp:ci
format: table
severity: HIGH,CRITICAL
exit-code: 1
ignore-unfixed: trueFor a GitHub-native security dashboard, swap format: table for format: sarif and upload the result with the official github/codeql-action/upload-sarif step. Findings then show up directly in the repository’s Security tab alongside any other code scanning alerts you already track.
Step 11: Add Trivy to a GitLab CI Pipeline
GitLab documents a free Trivy integration directly in its own CI templates, no separate license required. Add a job like this to .gitlab-ci.yml and it scans the image your build job just pushed to the GitLab Container Registry.
container_scanning:
stage: test
image:
name: aquasec/trivy:0.76.0
entrypoint: [""]
script:
- trivy image --severity HIGH,CRITICAL --exit-code 1 --ignore-unfixed $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"Pinning the image tag to aquasec/trivy:0.76.0 instead of latest keeps results consistent across pipeline runs, which matters more than it sounds because a database update between two runs of the exact same image can otherwise produce different findings and confuse a reviewer who assumes nothing changed.
Step 12: Deploy the Trivy Operator for Continuous Kubernetes Scanning
CI scans catch problems before deployment. They do not catch a new CVE disclosed against an image that has been running happily in your cluster for six months. That is the gap the Trivy Operator closes: it runs inside Kubernetes, automatically scans every workload, and re-scans on a schedule so a freshly disclosed CVE surfaces against images already in production, not just new ones.
helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update
helm install trivy-operator aqua/trivy-operator
--namespace trivy-system
--create-namespace
--version 0.35.0Version 0.35.0 is the current release listed on the project’s package index as of this guide, and the underlying Go module is tracked separately on pkg.go.dev if you need to vendor it directly into a custom controller. Once installed, the Operator creates VulnerabilityReport and ConfigAuditReport custom resources for every workload it finds, which you can query directly with kubectl.
kubectl get vulnerabilityreports --all-namespacesTeams that already use an admission controller like Kyverno to enforce policy at deploy time often pair it with the Trivy Operator for continuous drift detection after deployment. If you have not set up policy enforcement yet, our Kyverno setup guide walks through blocking non-compliant workloads before they ever reach the cluster, which complements what the Trivy Operator catches after the fact.
Step 13: Assemble the Complete Pipeline — a Working Dockerized App Scanned End to End
Here is everything from the previous twelve steps combined into one working project: a minimal Node.js app, a Dockerfile, and a CI job that builds, scans, and gates the release. Start with the application files.
// server.js
const http = require('http');
http.createServer((req, res) => {
res.writeHead(200, { 'Content-Type': 'text/plain' });
res.end('Trivy demo app runningn');
}).listen(3000);FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY server.js ./
USER node
EXPOSE 3000
CMD ["node", "server.js"]Note the USER node line. That single instruction fixes one of the most common findings Trivy’s config scanner reports: containers running as root by default. Build the image, then run the full scan sequence locally before it ever touches CI.
docker build -t trivy-demo:local .
trivy image --severity HIGH,CRITICAL --exit-code 1 --ignore-unfixed trivy-demo:local
trivy config --exit-code 1 ./Dockerfile
trivy image --format cyclonedx --output sbom.json trivy-demo:localThree commands, three different checks: vulnerabilities in the final image, misconfigurations in the Dockerfile itself, and an SBOM you can archive alongside the release artifact. Wire the same three lines into the GitHub Actions workflow from Step 10 and you have a complete, working, gated pipeline. If the base image or a dependency later picks up a critical CVE, the very next build fails instead of shipping it.
What makes this a complete project rather than a collection of disconnected commands is that each piece feeds the next one. The Dockerfile’s USER directive exists because the config scan would otherwise flag it. The –ignore-unfixed flag exists because without it, the very first unpatchable OS-level CVE in the node:20-alpine base image would block every single build indefinitely. The SBOM step exists because once this image ships, someone, possibly you in six months, will need to answer whether a newly disclosed CVE affects it, and grepping through old build logs is not a real answer. Copy this exact structure into a real project and swap the Node.js server for whatever your team actually ships, the commands do not change.
How Trivy Fits Into a Complete DevSecOps Workflow
A single scanner never makes a security program. What Trivy actually gives a team is a cheap, fast checkpoint at three distinct moments in the software lifecycle: before code is committed (the trivy fs pre-commit check from Step 5), before an image ships (the CI gate from Steps 9 through 11), and continuously after deployment (the Operator from Step 12). Each checkpoint catches a different class of problem. A pre-commit scan catches a vulnerable dependency before it is even reviewed. A CI gate catches a vulnerable base image before it reaches a registry. A running cluster scan catches a CVE disclosed against something that has already been live for months, which no pre-deployment check could ever have found.
Treating these three checkpoints as one continuous pipeline rather than three unrelated tools is what separates a team that merely “has a scanner” from one that actually reduces its exposure window. The SBOM from Step 8 ties the whole thing together: once you can point to an exact, versioned manifest of what shipped in a given release, a newly disclosed CVE becomes a five-minute lookup instead of a week of manually checking every service for an affected package.
Common Pitfalls to Avoid When Rolling Out Trivy
Most Trivy rollouts fail on process, not on the tool itself. The CLI is simple enough that almost nobody struggles to get a first scan running. Where teams actually get stuck is in the weeks after that first scan, once the backlog of existing findings and the noise from low-severity results start competing for attention. These are the mistakes that show up most often.
- Gating on every severity from day one. Starting with –severity LOW,MEDIUM,HIGH,CRITICAL on an existing codebase usually surfaces hundreds of findings at once and stalls every pull request. Start with CRITICAL, clear the backlog, then tighten.
- Letting the vulnerability database go stale in CI. If a pipeline caches the Trivy database but never refreshes it, scans quietly stop catching new CVEs while still reporting green. Refresh on a schedule, not just once.
- Treating –ignore-unfixed as permanent. A CVE with no fix today might get a patch next week. Revisit ignored findings periodically rather than assuming the flag is a one-time decision.
- Scanning the wrong image tag. Scanning myapp:latest in CI while production actually runs myapp:v2.3.1 gives a false sense of security. Always scan the exact tag or digest you are about to deploy.
- Skipping the Dockerfile and IaC scans entirely. Teams often run only trivy image and never trivy config, missing misconfigurations like root users and exposed secrets that the vulnerability scanner was never designed to catch.
- Not pinning the Trivy version in CI. Using aquasec/trivy:latest means a tool upgrade can silently change scan behavior or output format mid-sprint. Pin the version, and bump it deliberately.
Troubleshooting: 8 Common Trivy Errors and Fixes
Most Trivy problems in practice are environmental rather than bugs in the tool itself: network access, file permissions, or resource limits in whatever platform is running the scan. The table below covers the errors that come up most often across local machines, CI runners, and Kubernetes clusters, roughly in the order you are likely to hit them during a first rollout.
| Error or Symptom | Likely Cause | Fix |
|---|---|---|
| unable to download vulnerability DB | Corporate proxy or firewall blocking the OCI registry | Set HTTP_PROXY/HTTPS_PROXY env vars, or mirror the DB with TRIVY_DB_REPOSITORY |
| GHCR rate limit exceeded | Too many anonymous pulls of the DB image from ghcr.io | Authenticate to GHCR or cache the DB locally between runs |
| permission denied on /var/run/docker.sock | User not in the docker group when scanning local images | Add your user to the docker group, or run with sudo in CI only as a last resort |
| Scan hangs or times out on a large image | Default timeout too short for multi-GB images | Increase with –timeout 10m |
| Same image, different results between runs | DB updated between scans, or tool version drifted | Pin the Trivy version and note the DB timestamp in reports |
| SBOM missing license fields | Some package ecosystems do not expose license metadata to Trivy | Cross-check with the package registry directly for those ecosystems |
| Trivy Operator pods stuck Pending | Insufficient CPU/memory requests available on cluster nodes | Lower the Operator’s resource requests or add cluster capacity |
| Build fails on a CVE with no available fix | –ignore-unfixed flag omitted | Add –ignore-unfixed so unpatchable findings do not block the build |
Advanced Tips for Running Trivy in Production
Once the basics are working, a handful of adjustments make Trivy noticeably more useful at scale. First, separate the database download from the actual scan step in CI and cache the DB directory between runs. This alone removes most of the slowness people complain about in high-frequency pipelines, since the scan itself takes well under a second once the database is warm.
Second, if you operate in an air-gapped or heavily firewalled environment, mirror the vulnerability database to an internal OCI registry and point Trivy at it with the TRIVY_DB_REPOSITORY environment variable. This is the only reliable way to run Trivy where outbound internet access is restricted by policy rather than just a proxy.
Third, use a .trivyignore file to document exceptions instead of scattering –skip flags across scripts. A .trivyignore file sits in the repository root, lists CVE IDs one per line, and gets picked up automatically, which means the exception is version-controlled and reviewable in a pull request rather than hidden in a CI config only one person remembers writing.
# .trivyignore
# CVE-2026-XXXXX: no fix available, low exploitability in our context, reviewed 2026-10-10
CVE-2026-XXXXXFourth, combine scanners in a single pass instead of running separate commands for vulnerabilities, secrets, and misconfigurations. The –scanners flag accepts a comma-separated list, so a single invocation of trivy fs –scanners vuln,secret,config covers all three at once and cuts CI job count down.
Finally, feed scan results into whatever your team uses for incident tracking rather than letting them die in a CI log. A critical finding on a production image is exactly the kind of event that should trigger your existing response process. Our incident response plan guide covers how to structure that handoff so a scan finding does not sit unread in a Slack channel for two weeks.
Frequently Asked Questions
Is Trivy actually free, or is there a paid tier I need eventually?
The CLI, the vulnerability database, and the Kubernetes Operator are all Apache 2.0 and free to self-host indefinitely. Aqua Security sells commercial platforms built on top of the open-source project, but nothing in this tutorial requires a license or a paid account.
What is the difference between Trivy and the Trivy Operator?
Trivy is the CLI you run manually or in CI to scan a single target on demand. The Trivy Operator is a separate Kubernetes component that runs continuously inside a cluster, automatically scanning every workload and re-scanning on a schedule so newly disclosed CVEs surface against images already deployed.
Can Trivy scan images stored in a private registry?
Yes. Authenticate first with docker login against your registry, or pass credentials through environment variables such as TRIVY_USERNAME and TRIVY_PASSWORD, and Trivy will pull and scan the image the same way it handles public registries.
Does Trivy replace a full SAST or SCA platform?
Not entirely. Trivy focuses on known-vulnerability detection in dependencies and images plus misconfiguration and secret scanning. It does not perform deep static analysis of your own application logic the way a dedicated SAST tool does, so most mature security programs run both.
How often does the vulnerability database update?
The upstream database refreshes roughly every six hours, and Trivy checks for a newer version before each scan unless you pass –skip-db-update. Running with a stale, manually frozen database is one of the most common reasons teams miss recently disclosed CVEs.
Can Trivy scan Windows container images?
Trivy’s OS package detection is built around Linux distributions, so Windows container base layers get far thinner coverage than a Linux image. Application-level dependency scanning (npm, NuGet, and similar ecosystems) still works regardless of the base OS.
What exit code does Trivy return when it finds a matching vulnerability?
By default Trivy always exits 0, even when it finds critical vulnerabilities, because the base behavior is reporting rather than gating. You control the gate yourself with –exit-code 1 combined with a –severity filter, which is what turns a report into a build-breaking check.
Is Trivy usable in an air-gapped environment with no internet access?
Yes, with setup. You need to mirror the vulnerability database to an internal registry ahead of time and point Trivy at it using the TRIVY_DB_REPOSITORY environment variable, since the tool cannot reach its default public database source without outbound internet access.