[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