Implementing GCVE?

[SkripteDT]

Hi all,

would it be helpful to implement the GCVE approach from CIRCLE in DT? Have a loo at:

https://gcve.eu/about/

It could lead to less sleepless nights ...

What do you think?

Jörg

[SkripteDT]

The ENISA vulnerability DB https://euvd.enisa.europa.eu/ looks interesting too: They provide alternative IDs to get rid of double entries ...

Jörg

[nscuro]

I've seen this but am wondering what the immediate value proposition for a DT integration would be. Quoting their FAQ:

The EUVD service builds upon the CVE system and vulnerabilities in the scope of the CVE numbering service receive a CVE. In addition, the EUVD data aggregates and enriches the vulnerability information and lists an EUVD ID on top of the CVE when new vulnerability entries are created. To allow further cross referencing, the CVE identifier and additional vulnerability identifiers are listed when available.

So this depends on CVE. It is not clear what happens if a GHSA (or any other identifier) is created before a CVE. It also remains to be seen how ENISA will deal with cases where there is no 1:1 mapping between two identifiers.

Technically it doesn't get rid of double entries, it makes the situation worse by introducing yet another ID that needs mapping.

As for the data itself:

The EUVD collects and references vulnerability information collected from existing databases (such as MITRE’s CVE DB, GitHub's Advisory Database, JVN iPedia, GSD-Database), adds additional information via references to advisories and alerts issued by national CSIRTs, mitigation and patching guidelines published by vendors, and enriches it with exploited vulnerability markings (such as CISA KEV) and FIRST’s Exploit Prediction scores (EPSS).

I have not seen any useful matching data on their website yet. It seems to evolve around the concept of products (i.e. Oracle Java SE), and doesn't provide PURLs or even CPEs. For the vulnerabilities affecting libraries, it doesn't provide product information at all(?). This makes it hard to impossible to leverage it for what DT needs.

But at the very least the EUVD identifiers would be nice to have in DT. Same thing for GCVE.

[nscuro]

Related: DependencyTrack/vuln-db#37

[SkripteDT]

Thank you @nscuro,

Technically it doesn't get rid of double entries, it makes the situation worse by introducing yet another ID that needs mapping.

Technically spoken you're completely right. At the other hand this data source looks like a chance to get rid of a lot of double entries. A lot of my GitHub entries have a CVE-number. I havn't done a research, how many of them have both. I'd hope the problems you're mentioning would be minor. I could handle them manually.