fix(get-cves): Store cpe update values and use to correctly fetch cves

[tomdottom]

Draft outline of bugfix addressing #5517

• Add new column to store update value from Cpe 2.3 URI
• Populate new column when loading from NVD data source (updating other sources awaiting review of draft and general solution)
• Update SQL Select to use update column when searching data from NVD source
• Add test

Todo:

• Maybe move test to a more appropriate file
• After updating other data sources; get rid of OR where condition in SQL (if possible)
• Update other data sources which return affected data
  • curl_source.py
  • gad_source.py
  • osv_source.py
  • purl2cpe_source.py
  • redhat_source.py
  • rsd_source.py
• Delete commented dead code

[tomdottom]

@ffontaine could you cast an eye over the general solution in this draft PR and provide some preliminary feedback?

I've run this against the binary that caused me too find this bug, and it is reporting all expected CVEs.

My biggest outstanding question is if ProductInfo has to be updated with an update/patch field and then this used when performing db searches? If so the would mean updating every version parser, and other parsers which extract information for the ProductInfo object.

Things to note:

• I'm unsure of the information contained in other data sources, so for the time being I've split select conditions into those for NVD sources, and those other sources
  https://github.com/ossf/cve-bin-tool/pull/5523/changes#diff-9ff600501eb405c831259dc06591800710d4216dfe357cfc7c24dacdbfa25442L146
• def _load_cve_data is really only to be able to reuse downloaded data during testing and speed things up. It can be remove before merging if you have any objections to it.
• I may have missed some technique, but the CVEDB (and CVEScanner) fought against been tested a bit. Did I miss something here?

Cheers,

Tom

[ffontaine]

Sorry for the late answer, here is a first round of comments:

• version_update appears to be very specific to NVD/NIST. To the best of my knowledge, other data sources such as OSV do not provide this type of field. Given that, I’m not sure whether adding a dedicated versionUpdate field inside cvedb.py is the right approach or even necessary. A simpler solution might be to merge version and version_update into a single version string (for example, by updating decode_cpe22 and decode_cpe23). @alex-ter, I’d be interested in your thoughts on this.
• Remove commented-out dead code.

[tomdottom]

@ffontaine thanks for those pointers. I'll take a look at the OSV data and highlighted functions, and update this fix accordingly.

[alex-ter]

• version_update appears to be very specific to NVD/NIST. To the best of my knowledge, other data sources such as OSV do not provide this type of field. Given that, I’m not sure whether adding a dedicated versionUpdate field inside cvedb.py is the right approach or even necessary. A simpler solution might be to merge version and version_update into a single version string (for example, by updating decode_cpe22 and decode_cpe23). @alex-ter, I’d be interested in your thoughts on this.

I also think correcting the CPE decoding functions is the best approach here. Indeed the CPE's "update" is practically a part of the "version" in cve-bin-tool's terminology + this will require no changes to the DB format, which is a significant simplification. Now, OTMH there may be some complications in range construction/comparisons that need to be worked out, but still this minimizes change while achieving the goal, and arguably in a more logically consistent way.