Missing 'vulnerable_configuration' & /api/cvefor/

[oh2fih]

Compared to CVE-Search, the vulnerability-lookup is missing an important feature: the vulnerable_configuration field containing the affected configurations as CPE 2.3 strings. Furthermore, it is missing the ability to search for CVEs by CPE strings, i.e., the /api/cvefor/ endpoint.

This is an important feature, because the /api/cvefor/ endpoint can be used for enriching data that already has CPE information, e.g., results from Nmap, with related vulnerabilities. While it seems the public CVE-Search instance is already missing this data (either on purpose or as a side effect of using old v4.2.2), it is still a feature frequently used in local installations.

Would it be possible to get this feature implemented in vulnerability-lookup before CVE-Search will be deprecated (by the end of this year)?

[cedricbonhomme]

Hello,

We know and indeed this is a nice feature. We will investigate how to implement it properly in vulnerability lookup. By properly, I mean that the processing must be fast.
We are aware that other features are still missing at the moment (CAPEC, etc.). And we are not against re-implementing certain features. The more features we can keep, the best it is. I agree that this is important for some users.

I had a quick look at the code of cve-search concerning /api/cvefor, here.
The main difficulty is that we want a solution for all our different sources (only when possible). And of course first we must find a way to do that efficiently with redis/kvrocks for a single source... I think this will be way more different.
The support and correlation of the different sources is one of the priorities in vulnerability-lookup.

About cve-search "depreciation", this is not exactly what I understood from our discussion and the message you are referring to (on the CIRCL Mastodon instance).
The message is about the service operated by us. It will be replaced. The cve-search instance we are operating is really maxing out. Not only in terms of bandwidth, but as well in terms of CPU due to the database.
If you have your own cve-search instance I do not think that this is a huge problem for you. Our service has reached its limits.
We could do some statistics with our logs in order to see the endpoints that are really used the most.

[adulau]

The main issue is to find a way to make /api/cvefor working fo non-CVE source as many sources don't contain the exact same version with versioning. We will most probably restrict /api/cvefor for NVD and CVEs sources then a new versatile endpoint will be added at later stage for having another way to pivot from software name (outside CPE 2.3 only also for CVE without CPE which happens for a specific period of time as also mentioned in cve-search/cve-search#1097).

As mentioned by @cedricbonhomme , the depreciation is about the public service which is running at its limit right now and need to be replaced by a faster service.