Feature Request: Lightweight Reachability Analysis to Reduce False Positives

[damaoooo]

What would you like to be added:

I propose adding an optional, lightweight static analysis feature directly into Grype.

This feature would work as follows:

1. After matching a vulnerability, Grype would identify the specific function(s) or method(s) known to be vulnerable for that CVE.
2. It would then perform a simple, text-based search (effectively a grep) across the scanned source code to determine if these vulnerable functions are actually called.
3. If no calls to the vulnerable functions are found, the vulnerability would be either suppressed or flagged with a specific tag like unreachable.
   This could be controlled by a new flag, for instance, --enable-reachability-analysis.

Why is this needed:

The primary goal is to drastically reduce the high number of false positive alerts generated by unreachable vulnerabilities, which is a major source of alert fatigue for developers.

My research on this topic shows that this simple, low-cost static analysis method is remarkably effective. By checking for actual function calls, it's possible to filter out approximately 60% of the vulnerabilities typically reported by SBOM-based scanners.

This provides immense value by:

1. Dramatically improving the signal-to-noise ratio of scan results.
2. Allowing development and security teams to focus their limited time on vulnerabilities that pose a tangible risk.
3. Making Grype's results significantly more actionable out of the box, without requiring complex external tools or manual verification for a large portion of findings.

While this method isn't a perfect replacement for deep call-graph analysis (e.g., it may miss dynamic calls), a ~60% reduction in noise represents a massive and practical improvement for the user experience.

Additional context:

Here is a conceptual example to illustrate the feature:

1. A Python project uses the library requests==2.25.0.
2. Grype correctly identifies that this version is vulnerable to a CVE related to the requests.auth.HTTPDigestAuth function.
3. However, the project's source code only ever calls requests.get() and never imports or uses the vulnerable HTTPDigestAuth function.
4. With the proposed --enable-reachability-analysis flag, Grype would scan the source, see that HTTPDigestAuth is not called, and automatically suppress this finding or mark it as "unreachable".

This would prevent a developer from spending time investigating a vulnerability that poses no real threat to their specific application.

Thank you for considering this feature. I believe it would be a powerful enhancement to an already excellent tool. I'm happy to discuss my research findings in more detail.

[willmurphyscode]

Hi @damaoooo thank you for the issue!

We've discussed similar ideas before. The main limitation to implementing this is that many CVEs do not come with a machine-readable description of where the vulnerable code is. In your Python example, is there a machine-readable data source that would allow grype to see that this CVE only affects a particular function?

Please feel free to come to one of our Thursday community calls and discuss this with us. Here's the calendar link. We'd love to discuss your research in more detail.

[westonsteimel]

@willmurphyscode , there is (at least sometimes), in the python OSV data. They added this awhile ago : https://github.com/pypa/advisory-database/blob/244cb5e81d49bd054409bd57a51e3fd0f803afc0/README.md?plain=1#L37, but unfortunately this does not get included in the GitHub OSV data which is currently the only source we consume. It won't work particularly well yet to consume from multiple sources because you will just end up with many duplicates across many ids, which is why we need the aggregation in place prior to that. We have the same issue with go, since the go vuln db has all of the affected functions noted but we don't get that information from the GitHub advisories and don't want to bring in duplicate records

[damaoooo]

Hi @damaoooo thank you for the issue!

We've discussed similar ideas before. The main limitation to implementing this is that many CVEs do not come with a machine-readable description of where the vulnerable code is. In your Python example, is there a machine-readable data source that would allow grype to see that this CVE only affects a particular function?

Please feel free to come to one of our Thursday community calls and discuss this with us. Here's the calendar link. We'd love to discuss your research in more detail.

Thanks — and thanks for the quick reply!

We actually read the CVE descriptions manually to locate the vulnerable functions. That said, Golang’s vulnerability database does explicitly record affected symbols, which made this much easier for Go. For languages where CVE descriptions don’t name functions, I think a lightweight LLM could be used to extract likely vulnerable symbols from natural-language descriptions and map them back to package/symbol names.

I’d love to join a Thursday community call to discuss this further — thanks for the calendar link. I can present our approach and examples during the call.

[willmurphyscode]

Here's a summary of what we decided:

1. Go is probably the right language for this because Go binaries have pretty good symbol information, and the Go ecosystem already publishes information about which symbols are vulnerable.
2. Before we try to incorporate this, we should do an experiment to make sure it's work.

Here's an experiment that might work:

• Write a prototype program with basically 3 inputs: a binary compiled from Go, the result of scanning that binary with Grype, and the Go database of which symbols are affected
• This program essentially filters the Grype output by checking for a set intersection between symbols found in the Go binary and symbols found in the information about the vulnerabilities, and dropping CVEs with an empty set intersection.

We did a bunch of discussion about scripting languages, source code analysis, stripped binaries, etc. But the Go prototype would be a great step.

[willmurphyscode]

#1782 is a type of false positive that could be fixed by the go approach, because the stdlib package cmd/go shouldn't be present in the eventual binary.

[willmurphyscode]

We discussed this at our weekly livestream, for folks who missed the community call.

[damaoooo]

#1782 is a type of false positive that could be fixed by the go approach, because the stdlib package cmd/go shouldn't be present in the eventual binary.

Thanks for your reply. This is a simple proof-of-concept I wrote in Python. It can help reduce such false positives in Golang projects if both the final compiled binary and the go.mod file are available.

SBOMVerifierGoPoC

The Go vulnerability database provides a list of vulnerable functions. Although it may not be entirely comprehensive, it can still help reduce false positives by verifying them within the binary. At the source code level, there are tools that can generate call graphs to analyze reachability. However, due to dynamic features such as reflection, I believe that only the symbols present in the compiled binary can be fully trusted.