What Trivy is and why teams adopt it
Trivy is an open source security scanner from Aqua Security. It ships as a single binary with no server to run, which is a large part of why it spreads: an engineer can add it to a pipeline in minutes. It reads container images, repositories and clusters, compares what it finds against vulnerability databases, and also checks configuration files and looks for exposed secrets.
That ease is also the trap. A scanner that is added quickly and left at default settings produces hundreds of findings, developers learn to ignore them, and the programme quietly fails. Our Trivy consulting is mostly about the work around the tool: policy, base images, exception handling and where results appear. We cover the container-specific pipeline details in Trivy image scanning in CI/CD.
How we run Trivy in production
In the pipeline
A pull request scan for a repository and a build scan for the image cover different risks. The repository scan catches vulnerable dependencies and misconfigured manifests early; the image scan catches what the base image and OS packages add. A typical GitHub Actions step looks like this:
- name: Scan image
uses: aquasecurity/trivy-action@master
with:
image-ref: ${{ env.IMAGE }}
severity: HIGH,CRITICAL
ignore-unfixed: true
exit-code: "1"
format: sarif
output: trivy.sarif
We pin the action to a release or commit rather than a moving branch, cache the vulnerability database so scans stay fast, and upload SARIF so findings appear in the security tab. The same options work from the command line in GitLab CI or Jenkins. See the sibling page on GitHub Actions for the wider pipeline design.
In the cluster
The Trivy Operator runs inside Kubernetes and scans workloads as they run, producing vulnerability, configuration and exposed secret reports as custom resources. This matters because the image in production may have been built months ago. We export the reports to Prometheus metrics or your dashboards and route them by namespace owner. The operator uses cluster resources for its scan jobs, so we set concurrency limits and schedules to avoid straining small nodes.
Tuning findings so they are worth reading
Tuning is where most of the value is.
- Fix the base image first. A small set of approved, regularly rebuilt base images typically accounts for most findings. Refreshing them weekly through automated pull requests removes whole classes of noise.
- Use fix availability. Ignoring unfixed findings in the gate (while still reporting them) prevents blocking on problems nobody can resolve.
- Gate on new, not old. Existing debt is tracked and burned down separately. A pull request should fail because of what it introduces.
- Prefer VEX or targeted ignores. An ignore with a reason, owner and expiry is documentation. A blanket severity ignore is a blind spot.
- Separate dev and runtime dependencies. A vulnerable test library does not carry the same risk as one in the runtime path.
Our container security hardening and container image scanning with Trivy and ECR pages describe the registry side.
Cost, capacity and speed
The question we hear most is whether scanning will slow the pipeline. Done well, it should add well under the time of a typical test stage, because the database is cached and only changed artefacts are scanned.
Trivy itself is free, but the pipeline cost is real. Downloading the database on every job adds time and can hit rate limits on the default registry, so we mirror or cache it. Large monorepos benefit from scanning only changed images and lock files. Operator reports in a big cluster create many custom resources, which adds load on the API server, so retention and scan frequency are tuned.
Day-2 operations
- Database freshness. Scheduled rescans of deployed images matter as much as build scans. An image clean on Monday can carry a critical finding on Friday with no change.
- Version management. Scanner and action versions are updated deliberately, because a new version can change results and break a previously passing build.
- SBOM retention. Bills of materials are stored per release, ideally in a tool such as Dependency-Track, so a new disclosure can be matched to services quickly.
- Ownership. Findings route to the team that owns the service. A central security inbox does not scale.
Honest limits
Trivy matches known identifiers. It does not find logic flaws, unknown vulnerabilities or insecure code in your own application; that is the job of static analysis such as SonarQube and review. Its misconfiguration checks overlap with, but are not as deep as, a dedicated IaC scanner like Checkov. It reports presence, not reachability, so many findings are not exploitable in your context. And a clean scan says nothing about runtime behaviour, which is where Falco fits.
Rolling out without blocking developers
We run the scan in report-only mode for a couple of weeks, publish the top ten causes of findings, and fix those at the base image level before any gate fails a build. Only then do we turn on a blocking check, limited to new high and critical findings with a fix. Teams keep a documented way to request an exception, and the platform team reviews them weekly, so nobody waits long for an answer.
When to choose something else
If you want developer-facing fix suggestions, support contracts and a hosted dashboard, a commercial tool may serve you better. If you need agentless coverage across whole cloud accounts, look at a cloud security platform. For many startups, Trivy plus good base images is a strong and inexpensive start.
Working with us
We start with a baseline scan, agree a gate in report-only mode, then enforce on new findings once the noise is down. For ongoing ownership, our managed DevOps service can run the scanning programme with you. To discuss your setup, get in touch.
Official documentation: trivy.dev