Direct osv.dev and/or GHSA support

[chadlwilson]

Is your feature request related to a problem? Please describe.

Currently, the challenges with the NVD program are very much in people's minds (courtesy of @marcelstoer)

• https://www.infosecurity-magazine.com/news/nist-vulnerability-database/
• https://www.linkedin.com/posts/danlorenc_nist-cybersecurity-nvd-activity-7174758648173232128-td0s
• https://docs.google.com/document/d/1y6JXhh52b1OMxLMQyl_WH0R2-85iYEBzjSm_fhv8-GY/edit

As a result of the NVD analysis delays, the utility of ODC for some language ecosystems has decreased very markedly for discovery of new vulnerabilities (for those where it supports only NVD + OSSIndex, especially Java where ODC is one of the few tools that are Gradle/Maven-aware enough to work on transitives without lockfiles (as required by osv-scanner & GitHub; but still uncommon in the Java ecosystem).

While we hope the NVD can get back on its feet, there still seems utility in evaluating how we could expand ODC to complement with alternate sources as risk mitigation, even where they are less "indepedent" than an NVD or OSSIndex analysis, and don't come with a maintainer-independent assessment of the CVSS base score.

#6039 has been raised focused on addressing the false positive problem with current CPE heuristics, however I felt it perhaps sensible to have a more "direct" report or opportunity for discussion.

Describe the solution you'd like

Support for use of the osv.dev database via database dumps, otherwise co-erced or interpreted into the ODC formats.

• ideally with a re-orientation around both CPE and purl identifiers and ability to de-duplicate between them when grouping by "product" or library

Describe alternatives you've considered

• Support for Anchore's NVD data overrides?
• CVEList support? (not sure if there are "proper' product identifiers here)
• GSD support? (thx @marcelstoer)
• Direct GHSA support; but possibly makes more sense to use osv.dev as an aggregator since it covers more, and the schema/format is the same.
• Using a different tool such as osv-scanner or trivy.

Additional context

Is there perhaps any call-to-action / call-for-help the maintainers would like to communicate to the community? Personally I'm quite conscious that ODC also can feel at times like it might be similar to the NVD in this image, so am unsure how realistic this is.

I believe courtesy of both xkcd and someone from the NIST Support Open Letter

[marcelstoer]

I don't want this to turn into a broad "let's use source X" discussion, but I feel that GSD should maybe be added to the list of alternatives.

[chadlwilson]

Related to jeremylong/Open-Vulnerability-Project#70

[jeremylong]

I have been planning to move to a different data source for a while. Doing so would have many benefits. I haven't started this effort as it will be a non-trivial effort.

When selecting a data source the biggest concern is how the local DB can be easily updated. The OSV datadumps don't appear to have any index of what was updated recently - so you just have to download the entire thing when you want to update? Or am I missing something?

If we go with just the straight GHSA, the open-vulnerability-client already has the capability. Plus everything in GHSA has the equivalent of a PURL so there would be way fewer FP.

GSD is interesting, we'd have to basically git pull to update the local files and then process the new/updated items. However, this has the problem that many of the entries have the equivalent of a CPE, not a PURL. As such, we'd still end up with more fuzzy matching that results in FP.