osv.dev icon indicating copy to clipboard operation
osv.dev copied to clipboard

Support CPE search

Open oliverchang opened this issue 3 years ago • 6 comments

To help with existing clients depending on CPEs, we should add a search functionality to our API to allow searching for vulnerabilities by CPE.

This would require some work to map our package IDs to CPEs where possible.

oliverchang avatar Apr 21 '22 02:04 oliverchang

I support this issue, however how would you do the mapping of the vulnerability to each CPE? The NIST one is quite a pain to map and search on your own database. Maybe just remap, vendor solution version and the OS/environment?

nvattai avatar Mar 22 '24 13:03 nvattai

@nvattai do you have any specific examples of CPEs you'd like to be searching for?

andrewpollock avatar Mar 24 '24 23:03 andrewpollock

Hello @andrewpollock, thanks for asking. Yes, I have some CPE's that at the moment are problematic and grouped them by problems:

  1. Exact version matching Take for example the entry DSA-5586-1. The corresponding CPE down to the the release should be: cpe:2.3:a:openbsd:openssh:9.2:p1:::::: searching for openssh 9.2 in OSV does not yield any results because the version in the json is 1:9.2p1-2+deb12u1. This could probably be resolved by avoiding exact version search, or parsing these versions in semver. Same story goes for .NET Core

  2. CPE solution matching Searching the NVD for Apache, the CPE is the following: cpe:2.3:a:apache:http_server:2.4.54:::::::*. However, in OSV the solution does not always matches. So to get the vulnerabilities that match with Apache HTTP server I need to search Apache 2.4.54. I resolved this by a simple map on client side, so no big issue and I find the OSV approach more intuitive.

Let me know if it helps you or I can contribute to this feature.

nvattai avatar Mar 26 '24 15:03 nvattai

Let me know if it helps you or I can contribute to this feature.

So you have an understanding of my current thinking, I'm trying to think this through in a test-driven development manner, with some concrete test cases that fail, and then get them to work.

I think in the first instance, the API would need to be extended to support searching by a CPE string, hence my interest in better understanding exactly how a CPE string would be desired to be supplied for searching purposes.

I do think this rapidly devolves into a rat's nest of edge cases with versions, as reading between the lines, the primary use case is going to be with binary package version numbers?

andrewpollock avatar Apr 08 '24 02:04 andrewpollock

This issue has not had any activity for 60 days and will be automatically closed in two weeks

github-actions[bot] avatar Jul 30 '24 07:07 github-actions[bot]

@andrewpollock

I have a real example: vendor=Pcre, product=Pcre, version=8.35. I would expect the search at minimum to support something like "name":"pcre:pcre" and "version":"8.35". As far as I know, pcre v1 was never published from git so commit ID search is not possible.

https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&isCpeNameSearch=true&seach_type=all&query=cpe:/a:pcre:pcre:8.35

https://www.cvedetails.com/vulnerability-list/vendor_id-3265/product_id-5715/version_id-533724/Pcre-Pcre-8.35.html

From official-cpe-dictionary_v2.3.xml

  <cpe-item name="cpe:/a:pcre:pcre:8.35">
    <title xml:lang="en-US">PCRE 8.35</title>
    <references>
      <reference href="http://pcre.org/">Product</reference>
      <reference href="http://vcs.pcre.org/pcre/code/tags/">Change Log</reference>
    </references>
    <cpe-23:cpe23-item name="cpe:2.3:a:pcre:pcre:8.35:*:*:*:*:*:*:*"/>
  </cpe-item>

egonk avatar May 20 '25 10:05 egonk