Feature Idea: Complement VEX with a Simple, Built-in Reachability Check

[damaoooo]

Description

Hi Trivy Team,

First, I want to say I'm a big fan of Trivy. I've been closely following the discussions around vulnerability reachability, especially regarding the integration with tools like govulncheck and the strategic decision to adopt the VEX standard.

While VEX is definitely the right direction for a standardized and comprehensive solution, I've noticed that for many teams, generating VEX documents can introduce extra complexity and an adoption barrier, as it often requires configuring separate, language-specific tools.

A Simpler, Complementary Approach

My recent research has focused on a much simpler, more universal method for identifying unreachable vulnerabilities. The methodology is straightforward:

1. Identify the specific vulnerable function(s) for a given CVE from security advisories.
2. Perform a simple static text search (like grep) across the user's codebase to see if these functions are ever called.

The results from this lightweight approach have been very promising. My findings show that this method can successfully filter out approximately 60% of the false positive findings from SBOM-based scans across multiple ecosystems (Python, Node.js, etc.).

My Idea

I would like to propose the idea of adding an optional, built-in, lightweight reachability check to Trivy.

This feature would not replace the robust VEX workflow but would act as a powerful "first-pass" filter that works out-of-the-box for everyone.

How it could work:

• A new flag could be introduced, e.g., --enable-light-reachability-check.
• When a vulnerability is found, Trivy would attempt to find the associated vulnerable function name.
• It would then perform a quick scan of the source code for calls to that function.
• If no calls are found, the vulnerability could be flagged as likely-unreachable in the output, allowing users to easily filter or deprioritize it.

Why this is a valuable complement to VEX:

• Immediate Value & Lower Barrier: Users could instantly reduce noise without needing to set up a separate VEX generation pipeline.
• Cross-Ecosystem: The grep-like approach is language-agnostic and provides value even in ecosystems that don't have a mature tool like govulncheck.
• Better User Experience: It would significantly improve the default signal-to-noise ratio, making Trivy even more practical and developer-friendly.

Given the potential for a ~60% reduction in noise with a relatively simple implementation, I wanted to open a discussion to see what the team thinks about this idea as a complement to the existing VEX support.

Thank you for building such a great tool and for fostering these important community discussions!

Target

SBOM

Scanner

Vulnerability

[knqyf263]

Thanks for your proposal. While it’s great that even simple filtering can reduce noise, reachability analysis is implemented in Aqua's commercial scanner.
https://trivy.dev/v0.66/commercial/compare/

In OSS, it is currently out of scope. However, the community can create plugins and the like.
https://trivy.dev/v0.66/docs/plugin/