Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing 'vulnerable_configuration' & /api/cvefor/ #61

Open
oh2fih opened this issue Jul 23, 2024 · 2 comments
Open

Missing 'vulnerable_configuration' & /api/cvefor/ #61

oh2fih opened this issue Jul 23, 2024 · 2 comments
Labels

Comments

@oh2fih
Copy link

oh2fih commented Jul 23, 2024

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
Copy link
Member

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
Copy link
Member

adulau commented Jul 24, 2024

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.

@adulau adulau added the roadmap label Jul 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants