osv.dev icon indicating copy to clipboard operation
osv.dev copied to clipboard

List of Vulnerable functions for CVEs

Open rohitcoder opened this issue 1 year ago • 6 comments

Is your feature request related to a problem? Please describe. I'm looking to reduce the number of false positives from SCA vulnerabilities by performing function-level reachability analysis. However, it is challenging without knowing which specific functions are vulnerable for each CVE. Currently, it seems that OSV.dev provides details on vulnerable packages, but not on the specific vulnerable functions, making it harder to prioritize or analyze vulnerabilities effectively.

Describe the solution you'd like It would be highly beneficial if OSV.dev could include a list of vulnerable functions for each CVE, where applicable. This would allow security tools to perform function-level reachability analysis to determine if the vulnerable code is actually used, reducing unnecessary vulnerability reports. Such granularity would make the data much more useful for developers and security teams looking to mitigate real risks.

Describe alternatives you've considered An alternative approach could involve manually analyzing the codebases or associated patches to determine the specific functions impacted by each CVE. However, this is not scalable, especially for large projects and multiple dependencies.

Additional context Including vulnerable functions would provide much-needed granularity in SCA analysis and could help significantly reduce false positives. Are there any plans for this, or is there any existing data that could be leveraged for this purpose?

rohitcoder avatar Sep 28 '24 10:09 rohitcoder

I just checked #2468 is a related thread, and I found this info - https://osv.dev/vulnerability/GO-2024-2961 but just wanted to check if we can get this data for maven / npm from some sources.

rohitcoder avatar Sep 28 '24 16:09 rohitcoder

Hey @rohitcoder thanks for checking out our data!

We're really beholden to our upstream data sources to provide this information, at the moment.

We totally agree that having this information enables prioritisation beyond the vulnerable library package version. The Go security advisories are something of a bright spot in this space, and are human-curated by the Go Security Team.

andrewpollock avatar Sep 30 '24 07:09 andrewpollock

Want to note that internally there's an interest in Vulnerable File analysis for OS package manager scanning which is a bit easier to implement than function-based analysis. Since we move at enterprise speed, I'll circle back in a couple months when we have a better handle of the problem space and optimal solutions.

What seems clear is that source package matching (the only data upstream distro sources provide) is insufficient for reliable vulnerability reporting. We may need to have an additional authority/standard that creates these vulnerable function/file entries data (which perhaps the respective distros confirm in their published advisory).

rhdesmond avatar Oct 02 '24 17:10 rhdesmond

@rhdesmond Thanks for this info, I would be waiting for further updates.

Just wanted to confirm if you talking about the "OSV-Scanner" project? Is this a future plan for osv scanner, or something else?

rohitcoder avatar Oct 02 '24 18:10 rohitcoder

This is not a current plan for osv-scanner, but if file-based vulnerability reporting proves useful it may be added to Osv-scanner in the future.

rhdesmond avatar Oct 02 '24 19:10 rhdesmond

Another possibility we're exploring is https://github.com/google/osv-scanner/issues/1031: where we do import-level reachability analysis.

The benefit there is we don't need vulnerable symbol information (which is often hard to get reliably).

oliverchang avatar Oct 02 '24 21:10 oliverchang

This issue has not had any activity for 60 days and will be automatically closed in two weeks

See https://github.com/google/osv.dev/blob/master/CONTRIBUTING.md for how to contribute a PR if you're interested in helping out.

github-actions[bot] avatar Dec 01 '24 22:12 github-actions[bot]

Automatically closing stale issue

github-actions[bot] avatar Dec 15 '24 22:12 github-actions[bot]