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

Arnout Vandecappelle arnout at mind.be
Thu Aug 10 14:58:13 UTC 2023



On 10/08/2023 15:42, Thomas Petazzoni wrote:
> On Thu, 10 Aug 2023 15:18:42 +0200
> Arnout Vandecappelle <arnout at mind.be> wrote:
> 
>>> It could still be useful to have something to contribute new entries,
>>> for those packages that have no entry at all (regardless of their
>>> version number) in the CPE database.
>>
>>    This makes no sense at all. The only reason to have a CPE database entry is in
>> order to link it to a CVE. If there is already a CVE, then it should already
>> have a CPE entry. If there's no CVE yet, then will the first person to ever
>> submit a CVE for it use the same ID?
> 
> Well, that would be my expectation indeed. A package in Buildroot has
> no CPE in the database, no CVE. We submit a CPE to the NVD database. My
> hope (but perhaps I'm dreaming too much) is that the day there is a CVE
> on this software component that CPE identifier that was submitted will
> be used, and therefore our CVE tracking will work.

  There is a decent change that they would, I guess. On the other hand, I guess 
it's more likely that the CVE's CPE entry would be created by the maintainer of 
the project, and I guess they would just assume that there is no CPE entry yet 
and create something, without searching for a pre-existing name. They may even 
search for it, see that it exists already, and decide that it's a conflict and 
choose a different name...


> Maybe I'm dreaming here, but if it doesn't work like this, it basically
> means that for any package in Buildroot that never had any CVE, we have
> absolutely no guarantee that we will properly notice when the first CVE
> gets reported. Maybe that's life and we have to live with it, but it
> kinda sucks.

  Yup. That's why I claimed in my EOSS-ELC talk that the CPE approach is broken :-)

  Regards,
  Arnout



More information about the buildroot mailing list