Trivy Is Overwhelming by Default. Here's How to Actually Use It.

You run trivy image on your container. It comes back with 847 vulnerabilities. 12 CRITICAL. 94 HIGH. 341 MEDIUM. 400 LOW. You stare at it. You close the terminal. You open it again. You still have 847 vulnerabilities.

This is the Trivy experience for most people the first time they use it in a real environment. And based on what engineers are saying across Reddit, GitHub, and DevOps forums, it does not get much better unless you know what to tune.

This is not a post bashing Trivy. It is a genuinely excellent tool: free, fast, broad in what it scans, actively maintained, and trusted enough that it became one of the most widely deployed security scanners in the Kubernetes ecosystem. The problem is that out of the box, Trivy is configured to tell you everything. And everything is not useful.

This post covers why Trivy produces so much output, what the community has figured out about dealing with it, and the practical filters and workflows that turn it from a firehose into something you can actually act on.

The Community Has Been Complaining About This for Years

This is not a new problem and you are not alone in finding it frustrating.

In 2022, Aqua Security opened GitHub issue #2466 titled "Add an --ignore-unfixable flag." The reason? Engineers were getting flooded with vulnerabilities that had no available fix - CVEs that had been discovered but whose upstream distributions had not yet released a patch. These unfixable vulnerabilities would show up in every scan, clutter every report, and there was no clean way to exclude them. The issue had dozens of upvotes and comments from engineers across different organizations all describing the same experience.

GitHub discussion #3620, titled simply "Ignoring stuff," captured another common complaint: the documentation for how to ignore findings was confusing and incomplete, and users were struggling to understand what could be ignored, how to do it, and whether ignores would persist across scans. A maintainer eventually acknowledged that the documentation needed a rewrite.

VMware's Tanzu team published an official blog post specifically about reducing Trivy false positive noise, recommending VEX, Vulnerability Exploitability eXchange, documents as a way to filter out CVEs that do not apply to your specific deployment context. The fact that a major enterprise vendor published guidance on managing Trivy noise tells you something about how widespread the problem is.

On Reddit's r/kubernetes and r/devops, threads about Trivy regularly surface the same frustrations: scans blocking CI pipelines because of unfixable CVEs, security teams unable to communicate which findings actually matter, and developers ignoring scan results because there are too many to process.

One Medium post put it plainly in its title: "Trivy Is Noise by Default."

Why Trivy Produces So Much Output

Before getting to the fixes, it helps to understand why Trivy behaves this way. It is not a bug - it is a deliberate default configuration that optimizes for completeness over signal.

It scans everything in the image

By default, Trivy scans every package in your container image: the OS packages installed by your base image, language-level dependencies in your application, and any other artifacts it can find. A typical Node.js application running on an Ubuntu base image might have 200+ OS packages and hundreds of npm dependencies, each of which is checked against the vulnerability database.

Most of those packages are not part of your application logic. They are base image utilities, build tools left in the image, or transitive dependencies of your actual dependencies. But Trivy does not know that. It sees a package, it checks for CVEs, it reports what it finds.

It reports unfixable vulnerabilities by default

Here is the detail that surprises most people: Trivy by default reports vulnerabilities that have no available fix. These are CVEs that have been discovered and assigned a severity score but where the upstream distribution has not yet released a patched version.

There is nothing you can do about an unfixable vulnerability right now. You cannot update the package because no update exists. Yet these findings appear in your report at whatever severity level the CVE was assigned, mixed in with vulnerabilities you could fix if you chose to act on them.

This is a significant source of noise. On many base images, unfixable CVEs outnumber fixable ones.

Severity scores are assigned without deployment context

Trivy uses CVSS, Common Vulnerability Scoring System, scores to assign severity levels. A CRITICAL rating means the vulnerability has a high base score - but base scores are calculated without knowing anything about your specific environment.

A CRITICAL vulnerability in a library that your application loads but never uses the vulnerable code path of is not actually critical for you. A CRITICAL vulnerability in a package that is not exposed to the network in your deployment is not as critical as it looks. But Trivy does not know your runtime context. It applies the CVSS score as-is, which means your reports are full of CRITICAL findings that may not represent real risk in your environment.

Research from ARMO found that only around 15% of reported vulnerabilities are in packages actually loaded at runtime, meaning roughly 85% of what Trivy reports may not be exploitable in practice. A 2022 security industry report found that more than 40% of security tool alerts are false positives.

It scans more than you expect

When you run trivy k8s to scan a Kubernetes cluster, Trivy scans every container image in every running pod across your cluster. A medium-sized cluster with 50 pods each running 2-3 containers could return thousands of findings. If multiple pods are running the same image, the same vulnerabilities appear multiple times.

What Actually Matters: A Framework for Prioritization

Not all CVEs are equal. Before applying any filters, here is a mental model for deciding what deserves attention:

Act immediately:

• CRITICAL or HIGH severity
• Has a known fix available right now
• The vulnerable code path is actually reached by your application
• The package is exposed to untrusted input, such as network-facing code or user data handling

Scheduled remediation:

• HIGH severity without a fix yet, watched for upstream patches
• MEDIUM severity in actively used packages
• CRITICAL/HIGH in packages you use but with limited exposure

Track but do not prioritize:

• Any severity for packages with no fix available
• LOW and MEDIUM in base image OS packages that your application does not directly interact with
• Vulnerabilities in packages that are installed but not imported or used by your code

Acknowledge and document:

• CVEs that are not applicable to your deployment context, such as a Windows-only exploit in a Linux container
• Vulnerabilities in dev dependencies that are not included in your production build

The Practical Filters

Here are the specific Trivy flags and configurations that reduce noise and make output actionable.

Filter out unfixable vulnerabilities

This one change removes a huge portion of the noise in most scans:

trivy image --ignore-unfixed myimage:latest

This tells Trivy to only report vulnerabilities where a fixed version is available. If you cannot fix it, it probably should not be blocking your CI pipeline or cluttering your dashboard.

Focus on severity levels that matter

Stop reporting LOW and MEDIUM by default. Start with CRITICAL and HIGH only:

trivy image --severity CRITICAL,HIGH myimage:latest

Once you have a process for handling CRITICAL and HIGH, you can gradually add MEDIUM. Trying to address all severity levels at once guarantees you address none of them.

Combine both for a clean CI gate

For CI pipeline checks, this combination gives you a useful gate without overwhelming developers:

trivy image \
  --ignore-unfixed \
  --severity CRITICAL,HIGH \
  --exit-code 1 \
  myimage:latest

--exit-code 1 fails the build if any findings match your criteria. Without this flag, Trivy exits 0 regardless of findings, which means your pipeline passes even with CRITICAL vulnerabilities.

Use .trivyignore for known accepted risks

Create a .trivyignore file in your repository to suppress specific CVEs that you have reviewed and accepted:

# CVE-2023-12345 - Affects Windows only, not applicable to this Linux container
CVE-2023-12345

# CVE-2023-67890 - In dev dependency, not included in production build
CVE-2023-67890

This is the right way to handle CVEs that are not applicable to your context. Document why you are ignoring each one - this is an audit trail, not a way to hide problems.

Scan only the layers you own

If you are using a well-maintained official base image, such as alpine, distroless, or ubuntu, most OS-level CVEs are the base image maintainer's responsibility to patch, not yours. Focus your attention on your application dependencies:

# For a Python application, scan only pip packages
trivy image --vuln-type library myimage:latest

# For OS packages only
trivy image --vuln-type os myimage:latest

Separating OS and library scans lets you assign ownership: the platform team handles OS CVEs when they update base images, and the application team handles library CVEs.

Use the table format for humans, JSON for automation

The default table output is long and hard to read in a terminal. For human review, use the summary format:

trivy image --format table --report summary myimage:latest

For automation, piping, or feeding into dashboards:

trivy image --format json --output results.json myimage:latest

For GitHub Actions annotations, where findings appear inline in pull request diffs:

trivy image --format github myimage:latest

Kubernetes cluster scanning with scope control

When scanning a full cluster, scope your scan to the namespaces that matter:

# Scan a specific namespace only
trivy k8s --namespace production --report summary all

# Exclude system namespaces
trivy k8s --exclude-namespaces kube-system,kube-public --report summary all

Without scoping, a cluster scan produces a report so large it is effectively unreadable.

A Practical CI/CD Workflow

Here is a workflow that gives you security gates without CI fatigue:

Stage 1: Build gate, hard fail

Run during every pull request. Only fail on CRITICAL unfixed vulnerabilities in your application's own dependencies. This is the bar that gets you actual fixes without blocking every PR.

trivy image \
  --ignore-unfixed \
  --severity CRITICAL \
  --vuln-type library \
  --exit-code 1 \
  myimage:${PR_SHA}

Stage 2: Full report, soft fail, tracked

Run on every merge to main. Scan everything, report everything, and save results as artifacts. Do not fail the build - use this for visibility and trending.

trivy image \
  --format json \
  --output trivy-results-${DATE}.json \
  myimage:latest

Stage 3: Weekly remediation review

Pull the full reports from Stage 2, filter for CRITICAL and HIGH with fixes available, assign them to teams based on which dependencies they own. Review unfixable ones monthly to check if fixes have been released.

This three-stage approach separates "blocking security issues" from "security visibility" from "security debt management" - which is how security actually works in practice rather than trying to fix 847 things at once.

The March 2026 Supply Chain Incident

Worth mentioning because it affected a lot of teams: in March 2026, the Trivy GitHub Actions, aquasecurity/trivy-action, and Docker Hub images were compromised in a supply chain attack. Attackers force-pushed release tags with malicious payloads that stole CI/CD secrets, cloud credentials, and SSH keys from pipelines using the affected versions.

The lesson is not specific to Trivy - any tool in your CI pipeline is a potential supply chain risk. Pin to specific image digests rather than mutable tags, verify checksums, and use tools like StepSecurity to audit your GitHub Actions dependencies. The Trivy team responded quickly and the compromised versions were identified and documented, but teams that had run pipelines during the window should audit their credentials.

Frequently Asked Questions

Why does Trivy report so many vulnerabilities?

Trivy scans every package in your container image and checks each against the vulnerability database, including OS packages, language-level dependencies, and transitive dependencies. By default it also reports vulnerabilities with no available fix. Most container images contain hundreds of packages, many inherited from the base image, which is why raw scan output is typically in the hundreds of findings.

How do I reduce Trivy output noise?

The two most effective filters are --ignore-unfixed, which removes CVEs with no available patch, and --severity CRITICAL,HIGH, which removes LOW and MEDIUM findings. Combining these typically reduces scan output by 70-90% and focuses results on findings you can actually act on.

What is the --ignore-unfixed flag in Trivy?

--ignore-unfixed tells Trivy to exclude vulnerabilities from the report where no fixed version is available in the upstream distribution. Since you cannot patch what has not been patched yet, filtering these out reduces noise without hiding actionable risks.

How do I stop Trivy from failing my CI pipeline on every build?

Use --ignore-unfixed --severity CRITICAL as your CI gate rather than scanning everything. Also use .trivyignore to document and suppress CVEs that are not applicable to your deployment context. Reserve hard CI failures, --exit-code 1, for genuinely blocking issues only.

How do I ignore a specific CVE in Trivy?

Create a .trivyignore file in your repository root and add the CVE identifier on its own line. Trivy will skip that CVE in all subsequent scans. Document the reason for ignoring it as a comment - this is an audit trail, not a way to hide vulnerabilities.

Are all CRITICAL Trivy findings actually critical?

No. Trivy uses CVSS base scores, which are calculated without knowing your deployment context. A CRITICAL vulnerability in a library where your application does not use the vulnerable code path is not actually critical in your environment. Research suggests only about 15% of reported vulnerabilities are in packages actually loaded at runtime, meaning many findings do not represent exploitable risk in practice.

What is the best way to use Trivy for Kubernetes cluster scanning?

Use trivy k8s scoped to specific namespaces, such as --namespace production, with --report summary to get an overview first. Use --ignore-unfixed and --severity CRITICAL,HIGH to reduce noise. Exclude system namespaces, such as --exclude-namespaces kube-system,kube-public, when they are outside your team's control.

The Bottom Line

Trivy out of the box is not designed to be immediately actionable - it is designed to be comprehensive. The comprehensiveness is actually a feature: you want to know everything that is there. The mistake is treating the raw output as a to-do list.

The workflow that works: filter aggressively for CI gates, scan broadly for visibility, and review the full picture on a scheduled cadence rather than trying to address everything in real time. Build a .trivyignore file that documents accepted risks. Separate OS CVEs from library CVEs and assign them to the right owners.

Trivy is a good tool. It is just a good tool that requires tuning to be useful, and that tuning is not obvious from the documentation alone - which is exactly why so many engineers end up with 847 findings and no idea where to start.

Published on kubethings.com - the community resource for Kubernetes tooling.

Have a tool to suggest or an article to contribute? Submit it ->