[Buildroot] [PATCH 01/10] support/scripts/cve.py: properly match CPEs with version '*'

[Thomas Petazzoni <thomas.petazzoni@bootlin.com>]

Hello,

On Wed, 4 Nov 2020 10:45:32 -0600
Matthew Weber <matthew.weber@collins.com> wrote:

> > So it should be taken into account. In this specific case, it is
> > combined with an AND with CPE ID
> > cpe:2.3:o:suse:suse_linux:10:*:enterprise_server:*:*:*:*:* but since
> > we don't support this kind of matching, we'd better be on the safe
> > side, and report this CVE as affecting tar, do an analysis of the CVE
> > impact, and document it in TAR_IGNORE_CVES.  
> 
> I agree, it is better to over-report and give people the option of
> setting the ignore entry or to go work with the CPE dictionary team to
> make an update to how that CVE is being mapped to the CPE.

That is the idea. And among the new CVEs that appear, there are really
some CVEs where the NVD database just specify "*", without any
combination with a particular operating system or distribution: i.e the
CVE description is so imprecise that it doesn't even say which versions
of the software component are affected.

> I was interested to know if yocto has an existing listing of CVE they
> are ignoring as well.  I looked a bit at the cve-checker[2] but I
> couldn't find any existing list or metadata within yocto but instead a
> few forked tools that all allow you to create a Software Bill Of
> Materials (SBOM) and provide a list of overall excluded CVE [1].  It
> seems better to keep the initial refinement within Buildroot or to
> push instead for making a correction in the actual CVE mapping.  If
> the user wants to whitelist it outside of Buildroot for their specific
> use case, that could be a topic for a future patchset on creation of a
> Software Bill Of Materials matching/tailored for their defconfig.
> Thoughts?

Yes, we could certainly think of allowing the user to extend the list
of ignored CVEs. I haven't tried doing <pkg>_IGNORE_CVES +=
CVE-YYYY-XYZ in external.mk from an external tree. I don't know if it's
going to play well with the expansion ordering, though.

> Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com