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.