Re: [Buildroot] CycloneDX SBOM support

[Peter Korsgaard <peter@korsgaard.com>]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hello,

 >  I mentioned PURL vs CPE in my talk at ELC this year. You can look it
 >  up on youtube. It was near the end of the talk.

OK, I'll have a look.


 >> 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 think Robert is not necessarily primarily concerned with finding
 >  vulnerabilities, but rather with constructing a meaningful and
 > accurate SBoM (which is what dependencytrack does).

True. The monitoring stuff seems quite interesting for vulnerabilities
though.


 >  That said, it you want to use PURLs for vulnerabilities, you have to
 >  use a vulnerability database that uses PURLs. To my knowledge, there
 > is just one "open source" one: https://osv.dev. (There's also Sonatype
 > which can be used gratis but is not free.) Since there are many, many
 > CVEs that don't make it into OSV, using _only_ PURLs is certainly not
 > enough. But we could combine the two.

OK. It doesn't sound like it will bring a lot of advantages for the
effort to maintain PURL identifiers :/


 >  Another issue with PURLs is: which one do we use? PURLs are organised
 >  around ecosystems. For PyPI it's clear, but for your typical C
 > library/application it's less so. E.g. openssl appears in the Debian,
 > Alpine, AlmaLinux, RPM, RockyLinux ecosystems (and possibly more),
 > each with a distinct PURL. We could start our own namespace, but
 > that's kind of pointless unless we also issue advisories...

I guess we should use the one matching where we get the source code from
(if any). The cyclonedx tool uses a "generic"
pkg:generic/$name?download_url=$site/$tarball, so we could default to
that and just use pypi/github/whatever for the special cases where there
is a more accurate one.


 >  There's by the way another issue (which also exists for the CPE-based
 >  approach): our "BoM" for the cargo and go packages is not correct: we
 > vendor the dependencies, but they're not taken into account in the
 > BoM. The tarball we put in legal-info does include the vendored
 > dependencies, but they're not mentioned in the manifest, and we don't
 > scan their vulnerabilities.

True. I am not sure of a good way how to fix that though. That shouldn't
stop us from generating a good SBOM for all the other packages.

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