List of Vulnerable functions for CVEs

[rohitcoder]

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]

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.

[andrewpollock]

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.

[rhdesmond]

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).

[rohitcoder]

@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?

[rhdesmond]

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.

[oliverchang]

Another possibility we're exploring is google/osv-scanner#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).

[github-actions]

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]

Automatically closing stale issue