[Buildroot] CycloneDX SBOM support

[Arnout Vandecappelle]

On 29/08/2023 01:19, Robert Smigielski wrote:
> 
> 
>       >  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.
> 
> 
> Yes I am concerned with creating a valid CycloneDX official SBOM for use in 
> other projects as an input. For example take the output file <product>.json as 
> input to Dependency Track. It does work. That is exactly what I need for my 
> daily work.
> 
>     OK. It doesn't sound like it will bring a lot of advantages for the
>     effort to maintain PURL identifiers :/

  From a pure vulnerabilities tracking point of view, it may seem it doesn't. 
However, I expect that there are vulnerabilities that are tracked in OSV for 
ecosystems like PyPI, Go, and crates.io, which don't have a corresponding CVE or 
where the CPE information is inaccurate/incorrect. And I'm very sure that there 
are vulnerabilities that are found by OSS-Fuzz which don't get a CVE (I think 
OSS-Fuzz never creates CVEs themselves, they expect the package maintainers to 
do that). Of course, the question is how valuable those OSS-Fuzz vulnerability 
reports are: they just have a reproducer, no analysis of the risk or impact.

  Anyway: creating a purl based on the PyPI, Go and crates.io ecosystems based 
on the information already in Buildroot should be rather trivial, and it has value.


>  From my view point - if Buildroot supports PURL I will add that data to my 
> project. If not, that is okay.
> 
> 
>       > each with a distinct PURL. We could start our own namespace, but
>       > that's kind of pointless unless we also issue advisories...
> 
> 
> Yes, Buildroot could consider itself a package manager, because it does that. 
> That idea is a possibility.

  IMHO, though, the idea that a package manager creates a namespace is not very 
valuable. It should be up to the actual package maintainers to decide which 
ecosystem they belong to.



>     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

  Exactly.

> Yes, the tool I wrote uses the "generic"  package. There is a place holder out 
> there in PURL for Buildroot if you want to go that way in the future.

  As I wrote above: I don't think that generic placeholder is very valuable. 
Although, it does give you a unified URI scheme that points you to the exact 
source and version that was used. But because it's not a unique identifier, i.e. 
there are many different PURIs that point to exactly the same source. E.g. for 
github automatically generated tarballs, there's a bit of freedom in how you 
construct the tarball name and we actually make use of that freedom. This means 
that you cannot compare generic PURIs from different sources and expect them to 
have a meaningful match. So it's no use for vulnerability tracking.

  BTW, is this "generic" namespace something official or something you invented?


>       >  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.
> 
> 
> If data is not in the legal-info, then no problem, the CycloneDX-Buildroot 
> project will not see it.  Note that CycloneDX has support for cargo and for go 
> already. Maybe that can help.

  I don't think there's a tool that you can feed the CycloneDX SBoM and that 
will add all the missing go/crates dependencies to it. There are tools that do 
this based on the source, though.

  However, it's not _that_ difficult to get this information from within 
buildroot. When we do the vendoring in the download step, we can ask the 
download tool (cargo / go mod) to also create a manifest of the vendored 
dependencies. In fact, I think they do that automatically. So it's "just" a 
matter of parsing this manifest and including it in the SBoM.


  Regards,
  Arnout