[Buildroot] [PATCH] support/scripts/cve.py: switch to NVD JSON version 2.0

[Daniel Lang]

On 09.08.23 22:59, Thomas Petazzoni via buildroot wrote:
> On Wed, 9 Aug 2023 22:31:11 +0200
> Arnout Vandecappelle <arnout at mind.be> wrote:
>
>>   Using the CPE database is actually useless. I think we should drop it.
>
> When I read this, I disagreed...
>
>>   It actually doesn't matter at all if a CPE entry (including the version) is
>> found in the CPE database. If there's a CVE for it, then the entry will exist.
>> But usually, the CVE will have a version range. In that case, we anyway match
>> the version range without caring at all if the specific version exists in the
>> CPE database or not.
>>
>>   So, I think we should just construct a CPE string and match it against the
>> CVEs, without consulting the CPE database at all.

That's what pkg-stats does anyway.
CPEs are checked separately, not for each CVE.

>>
>>   It _does_ make sense to do a lookup in the CPE database for the CPE string,
>> but with * as the version part. This allows us to validate if the
>> vendor/project/etc. are set correctly. But that's something we can do in
>> individual API calls for each package, like we do for release-monitoring.

The problem here is, that the new API (even the one for CPEs) constrains us
to a 6 second timeout between requests [0]. We currently have ~700 packages
with CPEs. This would come out to 4200 seconds or about 70 minutes, each time
we run pkg-stats for all packages.
The only way around this is requesting an API key [1] which allows "50 requests
in a rolling 30 seconds window". NVD still recommends to sleep in between
requests...

>
> ... but then you say we should still use the CPE database, and I agree
> on the why we should use it: to have some reasonable certainty that the
> CPE ID we create in Buildroot for each package has a chance of matching
> the CPEs that will be associated to the CVEs that will perhaps one day
> be reported against this software package. So yes, perhaps we should
> just match in the CPE database with version set to '*', so that we
> don't care if the CPE database isn't aware of the latest releases of
> software packages, which it rarely is.

On that "latest release" note, we have a second, probably rarely used,
use case for CPEs which is support/scripts/gen-missing-cpe. This script
tries to generate a XML structure for each version that isn't registered
in the database. For this script a lot of information about the CPE needs
to be stored.
Side note here: I'm not sure that script will works correctly.
When I tested it I got a file for polkit 122 that contained 0.120 as version.

>
> Thomas

Regards
Daniel

[0]: https://nvd.nist.gov/developers/start-here
[1]: https://nvd.nist.gov/developers/request-an-api-key