Trackr.Live The landing site for Trackr Services
§ Trackr.Live

Trivy

Trivy is free. That is the first thing worth saying about it, because almost everything else follows from it. It is an open-source, Apache-2.0 scanner from Aqua Security, and being genuinely OSS rather than a freemium teaser is why it ended up in basically every CI pipeline that touches a container, and why it shows up in federal programs that either can’t get budget for a commercial scanner or won’t spend it. You can go install it, drop the static binary into a runner, and gate a build on vulnerabilities before lunch. No license server, no seat count, no procurement cycle.

A single binary fanning out scan beams across container layers, an IaC config file, a git tree, and a Kubernetes cluster, with findings flowing back into one report.

Aqua Security is still the maintainer, and as of mid-2026 Aqua is still an independent private company. No acquisition, no rebrand. The last raise was about $60M in January 2024 (Evolution Equity Partners led it), putting the valuation north of $1B, and the company has been the kind of name people expect to IPO for years without it actually happening. Aqua is the one that acquired things along the way, tfsec in July 2021 and Argon in December 2021, which matters more than it sounds (more on tfsec below). The project moved its home to trivy.dev a while back, so if you’re still bookmarking the old aquasecurity.github.io docs path, update it.

Version reality

Latest is v0.70.0, out around April 17, 2026. Note the leading zero. Trivy has never shipped a 1.0, and it has been doing frequent minor releases on the 0.x line for years. I read that as a deliberate semver posture, not a maturity signal. A tool this widely deployed staying on 0.x is a way of reserving the right to break things between minors without the ceremony a 1.0 implies, and given the release cadence (a new minor every few weeks) that’s the honest call. You can disagree, plenty do, but treating “still 0.x” as “not production-ready” would be wrong on its face given where it runs.

The v0.70 changelog itself dates fast, so I’ll keep it light. The interesting one is uniform third-party package skipping across OS types, which is a direct swing at the noise problem (packages from Docker, NVIDIA, EPEL, Remi repos throwing false positives). There’s also Go binary version detection for -trimpath builds via the ELF symbol table, and AKS misconfiguration scanning for clusters defined in ARM templates. By the time you read this there’s probably a v0.71 or v0.72; check the tag.

What it actually scans

The mental model that keeps people out of trouble: Trivy separates targets from scanners. The target is the thing you point it at. The scanner is the check it runs.

Target OS + dep CVEs IaC misconfig Secrets License SBOM
Container image yes — yes yes gen/scan
Filesystem / rootfs yes yes yes yes gen/scan
Git repo (remote) yes yes yes yes —
VM image yes — yes yes gen
Kubernetes cluster yes yes yes — —
Cloud (AWS, etc.) — yes — — —

That breadth in one binary is the whole pitch. The CVE scanner covers OS packages and language dependencies. The misconfiguration scanner reads Terraform, CloudFormation, Kubernetes manifests, Dockerfiles, Helm. Secrets and licenses come along for the ride on most targets. And it generates and consumes SBOMs in both CycloneDX and SPDX, which is the format question federal programs always ask first.

The tfsec merge, which people still get wrong

If a pipeline or a wiki page in your org still treats tfsec as a separate tool, it’s stale. tfsec was acquired by Aqua and folded fully into Trivy; the standalone tfsec repo stopped getting new checks (it sits at v1.28.x and won’t move). The misconfiguration engine inside Trivy is the old tfsec engine. The check IDs carry over unchanged, so an AVD-AWS-0086 you remember from tfsec is the same finding in Trivy. Migration is just tfsec . becoming trivy config ., exit codes and all. There’s a migration guide in the archived tfsec repo if someone needs convincing.

This is also where the honest comparison with Anchore lives. Anchore’s Syft and Grype occupy a lot of the same container-CVE ground Trivy does, and in Iron Bank both Anchore and Trivy run against the same images. They are not interchangeable in temperament (Anchore leans toward the SBOM-as-system-of-record model, Trivy toward the fast gate), but if someone tells you Trivy and Grype find wildly different CVE sets on the same image, push back and ask which DB snapshot each one pulled. See Anchore for that side.

CLI versus Operator

Two deployment shapes, and conflating them causes most of the confusion.

The CLI is one-shot. You run it in a pipeline, it scans, it sets an exit code, the build passes or fails. This is the shift-left gate, and it’s what most people mean when they say “we run Trivy.”

The Trivy Operator is the Kubernetes-native story. You install it via Helm into the cluster, it watches workload state, and it auto-triggers scans as things change. Results land as CRDs (VulnerabilityReport, ConfigAuditReport, and friends) that you read straight through the Kubernetes API. That’s the continuous-monitoring flavor, the thing that gives you the ongoing posture RA-5 actually wants rather than a point-in-time snapshot from a single pipeline run. There’s also a trivy-enforcer project for admission-style image assurance, but it’s flagged EXPERIMENTAL in its own repo, so don’t build a control narrative on it yet.

Where it sits in the federal flow

Trivy’s federal credibility comes through DoD Platform One’s Iron Bank. Every image in Iron Bank goes through DISA hardening and STIG review, and vulnerability scanning runs via both Anchore and Trivy, with findings documented in the image’s Container Approval Record. The images and the pipeline are mirrored into repo1.dso.mil (the DSOP GitLab). That’s the real hook, and it’s a strong one.

But be careful here, because this is the trap. Trivy has no standalone FedRAMP authorization and is not on the DoD APL. It’s an OSS CLI. It gains its standing by being embedded inside an authorized pipeline (Iron Bank, Big Bang), not by carrying a stamp of its own. Anyone who writes “Trivy is FedRAMP authorized” in an SSP has invented a fact. That’s normal for a command-line tool, by the way. The authorization boundary is the platform that runs it, not the binary.

Deeper: who runs it and on what cadence. Trivy isn’t owned by a separate scanning team in most shops. It’s wired in by the platform or DevSecOps engineers, and the ISSE inherits the output. Cadence splits along the CLI/Operator line: the CLI fires every build or PR as a gate, the Operator scans continuously in-cluster. What pulls Trivy in is rarely a line item that names Trivy. It’s container and IaC hardening requirements, and SBOM and supply-chain expectations downstream of the post-EO-14028 framing. Worth knowing that the 2025-2026 policy ground shifted under all of this: EO 14028 was superseded, EO 14144 walked back by EO 14306 in June 2025, and OMB M-26-05 (January 2026) moved agencies to a risk-based, agency-by-agency assurance posture rather than the old standardized self-attestation forms. SBOM is still very much in play; the mandate language around it is softer and more agency-discretionary than it was two years ago. Check your agency’s current policy, not a 2022 blog post.

What it’s good at, and what people gripe about

Good at: free, fast, one binary, no server to run, trivial to wire into GitLab CI or GitHub Actions or an Azure DevOps extension, broad coverage, SBOMs in formats other tools accept. For shift-left gating it’s hard to beat on effort-to-value.

The complaints are real and you should know them going in. The eternal one is false positives on OS package CVEs, the case where a distro has already backport-patched a fix but the version string doesn’t reflect it, so Trivy flags a CVE that’s effectively dead. The v0.70 third-party-skip work is a direct response to that family of noise. Then there’s the vuln DB problem, which is the federal gotcha.

The air-gap DB problem

trivy-db and trivy-java-db are distributed as OCI artifacts out of GitHub Container Registry (GHCR). Trivy pulls them on scan. In a busy CI environment, or behind a shared egress IP, you will hit GHCR rate limits (the TOOMANYREQUESTS error is a well-worn discussion thread), and in an air-gapped DoD enclave you simply can’t reach GHCR at all. The fix is to mirror the DB artifacts into an internal OCI registry and point Trivy at it with --db-repository and --java-db-repository. The Trivy DB republishes every 6 hours and the Java DB every 24, so your mirror needs a refresh job, and “the cron that pulls the DB has been silently failing for three weeks so every scan is running against a stale snapshot” is exactly the failure you should expect to find when an air-gapped scan suddenly stops flagging anything. Authenticating to GHCR raises the rate limit if you’re rate-limited rather than fully air-gapped, which buys some teams out of the problem without a full mirror.

Other honest gaps: there’s no central dashboard or reporting surface in the OSS tool. That’s deliberate, it’s where Aqua’s commercial platform upsell lives, and the OSS-versus-commercial line is worth stating plainly to anyone expecting a UI. Severity triage and suppression workflow are thin compared to a commercial scanner too. You get .trivyignore and VEX (OpenVEX, CycloneDX VEX, CSAF) for suppression, plus SARIF output for code-scanning surfaces and JSON for whatever SIEM or downstream you’re feeding, and exit-code gating to fail the build. There is no native eMASS ingestion. Results move into eMASS as artifacts and POA&M evidence, not through a connector, so don’t let anyone draw a box labeled “Trivy → eMASS” on an architecture diagram.

Here’s the contestable take, plainly marked: Trivy is the right default OSS scanner and a poor system of record. In a federal program it should gate builds and feed the Operator’s continuous view, but the authoritative vuln inventory should live somewhere with real history, dedup, and reporting, whether that’s Anchore Enterprise, a commercial platform, or your own warehouse fed off the JSON. Treating a stack of per-build Trivy JSON files as your inventory of record is how you end up unable to answer “show me every system affected by this CVE” in an IG audit.

Control ties

The genuine 800-53 mappings: RA-5 for vulnerability scanning, with the Operator supplying the ongoing/continuous character RA-5 leans toward rather than point-in-time. SA-11 for developer security testing, since Trivy in the build pipeline is the static-analysis-adjacent gating that SA-11 and its enhancements are after. CM-6 for configuration settings, which is exactly what the ex-tfsec misconfig engine checks against secure baselines. And the SR family for supply chain, where SBOM generation and dependency provenance live (SR-3, SR-4, SR-11 territory), with SA-15 as a reasonable stretch for development tooling. I’d stop there. Mapping Trivy into IA or AC is reaching.

Sources

Adjacent material on this site