Re: [Buildroot] CycloneDX SBOM support

From: Peter Korsgaard <peter@korsgaard.com>
To: Robert Smigielski <ptdropper@gmail.com>
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] CycloneDX SBOM support
Date: Mon, 28 Aug 2023 16:57:10 +0200	[thread overview]
Message-ID: <87r0nn5i61.fsf@48ers.dk> (raw)
In-Reply-To: <CABWt4eu5oYECnC+=68QWgkJywrPKLq5_CDcrFeZm+Um8gRYksA@mail.gmail.com> (Robert Smigielski's message of "Mon, 28 Aug 2023 08:11:34 -0400")

>>>>> "Robert" == Robert Smigielski <ptdropper@gmail.com> writes:

Hi,

 > At this time I'm reading up on the difference between CPE and PURL. While
 > we have CPE information in their currently, it may be beneficial to have
 > PURL for some of the packages. I'm still new to the concept of what those
 > two formats provide. Your feedback is most welcome. Glad you are finding
 > this useful.

Conceptually they seem quite similar, with PURL being more generic, but
I fail to see how we could use PURLS in Buildroot, E.G. how to do the
equivalent of the CPE matching we use to figure out if the version of a
package in Buildroot is vulnerable to a specific CVE?

I gave your generateBuildrootSBOM.py script a quick try here, and
noticed a few things:

- The purl links seems wrong (missing slash between site and filename):
  "purl": "pkg:generic/busybox@1.36.1?download_url=https://www.busybox.net/downloadsbusybox-1.36.1.tar.bz2"

- The patches are not mentioned in the SBOM. Adding the show-info data
  does bring the CPE identifiers, but E.G. doesn't include _IGNORE_CVES
  data (that we use to signal that a vulnerability is either not
  applicable to Buildroot or fixed by a backported patch). I don't know
  much about cyclonedx, but judging from
  https://github.com/DependencyTrack/dependency-track/issues/919 it
  sounds like such info can be represented in the SBOM.

- Latest version in git is 1.0.4 (using an non-annotated tag, whereas
  1.0.3 was annotated), but on pypi there is (only) a 1.0.5, which seems
  to match the 1.0.4 sources. It is marked as needing python > 3.10, and
  doesn't pull in the dependencies, so it doesn't work very well

- The output filename is used as a prefix, with .json .one.xml and .xml
  variants. I understand why you do this, but it is a bit confusing
  still. Is there any real use of the non-JSON formats / available
  tooling to convert if needed?

Is there a specific reason why you are maintaining it separately from
Buildroot? Given the fairly tight link to the Buildroot details that
may change in the future (not to mention ease of use/discovery) it seems
to me to be something that would be interesting to ship together with
our other python based tooling inside Buildroot?

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot