Re: [Buildroot] [RFC PATCH 0/5] Support SBOM in CycloneDX format

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Arnout, All,

On 2024-04-09 14:17 +0200, Arnout Vandecappelle spake thusly:
> On 08/04/2024 21:15, Yann E. MORIN wrote:
> > On 2024-04-07 23:15 +0200, Thomas Petazzoni via buildroot spake thusly:
> > > On Thu,  4 Apr 2024 14:43:24 +0200
> > > Thomas Perale <thomas.perale@essensium.com> wrote:
> > > > This RFC patch series propose to add support for the CycloneDX
> > > > SBOM format.
[--SNIP--]

> > On 2024-04-07 23:15 +0200, Thomas Petazzoni via buildroot spake thusly:
> > > My initial reaction is whether it is really the right solution to have
> > > "make" spit out the CycloneDX format, or whether we should use "make
> > > show-info", and then process the JSON output using some Python script
> > > to generate the CycloneDX SBoM.
[--SNIP--]

> On 08/04/2024 21:15, Yann E. MORIN wrote:
> > This was also my reaction: when I introduced show-info,
[--SNIP--]

On 2024-04-09 14:17 +0200, Arnout Vandecappelle spake thusly:
>  My premise is that we should (in the longer term) _always_ generate the
> CycloneDX SBoM as part of the world target, so without needing a separate
> "make cyclonedx" step. I think we need to kind of force people to generate
> SBoMs, so there is no excuse not to have it.

An SBOM is totally worthless when generated on the developers machines,
as the build environment there is uncontrollable; it is useless during
development as well [0]. An SBOM only ever makes sense when generated in
a delivery pipeline, like in a CI/CD pipeline.

[0] except in the rare cases of those developpers explicitly looking at
or working on the SBOM: evaluating the SBOM, fixing bugs in the SBOM
generation tooling, adding SBOM-related metadata...

>  This has a number of implications: it has to be quite lightweight (because
> it is called for every build), so that basically limits it so make and shell
> (I didn't like the idea of "always build host-python"). It should also be
> possible to generate it without internet connection on condition that a
> 'make source' was called before (that's why the license list in
> support/misc/cyclonedx-spdx.mk is stored in the git repo and not downloaded
> while building). On the other hand, the cyclonedx generation can depend on
> the presence of downloads and build artifacts, if that is needed.
> 
>  On that background, with the addition of cyclonedx, we now have 5 things
> that do somewhat similar things: cyclonedx, legal-info, show-info,
> pkg-stats, and printvars.

Forget about printvars: it is unusable and legacy. We have show-vars
instead, which does provide a reliable extract of the internal
variables (except for those that need a $(@) or $(@D) or such, because
there is no actual target in that case, and thus it is not possible to
properly extract the internal state of variables).

We should now drop printvars.

> So a second goal is to try to unify all that in a
> single mechanism. And because cyclonedx is a standard, it makes sense to me
> to try to use that as the primary mechanism, and make the others derivations
> from it.

The nice things about standards, is that there are so many to pick from.
;-)

SPDX is also an SBOM standard, which predates cyclonedx by 6 years. It
is more mature (older!), so why don't we settle on that instead?

> - For show-info: as long as the same information is available in the
> cyclonedx file, we can simply use the cyclonedx file and deprecate show-info
> (possibly with a conversion script, which is allowed to be written in
> python, but might even be possible to write with jq, to convert to the
> legacy format).

I strongly disagree. show-info has other usages than generating an SBOM,
and contains a lot of info that does not belong in a SBOM. For example,
as you noticed, the package infra is mising in cyclonedx, and there is
no reason to add it there, while it has its place in show-info.

Another example, is that (AFAICS) there is no dedicated way to describe
reverse depdndencies in cylonedx, except by injected an arbitrary
property, which means that it does not really fit... show-info provides
that.

More generally: there is information that belongs to show-info, as it is
usefull for generating various reports, that have absolutely no meaning
in an SBOM, and so there is no reason to inject those in cyclonedx just
because something else may need it. That's what show-info is for.

And as Thomas said, if show-info is missing data, we can easily add it.

> - For legal-info, it's quite obvious that cyclonedx should basically replace
> that - though legal-info currently still does a number of additional steps
> (e.g. collect the actual source) that cyclonedx doesn't cover. I also think
> the manifest.csv file makes a lot of sense. I'm not sure how to solve that,
> but I can imagine that there could still be an explicit legal-info target
> that consumes the cyclonedx file and does some additional steps.

Or the other way around: cyclonedx consumes the output of legal-info.

> - For pkg-stats, it turns out that DependencyTrack already covers a large
> number of features that we have in there (CVEs, obviously, but also upstream
> version). Some very buildroot-specific things are not in there (e.g. the
> package's infra) but it could be possible to add those to DependencyTrack.
> - For printvars I have no solution, I guess it will have to stay.

See above: we should drop it in favour of show-vars. But yes, this wil
have to stay, indeed.

>  So, why is it not a Python script based on show-info? Because I want the
> CycloneDX file to be _always_ generated, which means no Python. And
> processing JSON in shell is horror, then it's better to just generate it
> twice.

As I said above: it does not make sense to always generate it, because
it is only relevant when it is generated in a controlled environment,
like a delivery pipeline for a delivery tag (or such), and not during
development on developers machines.

[--SNIP--]
> > > > - [ ] Find a solution to handle versioning. The "version" property
> > > >        should be incremented every SBOM generation.
> > Also I don't see how that versioning works.
>  In my understanding, the version should be updated every time you edit a
> CycloneDX file. So we always generate version 1. It is updated by tools that
> _process_ CycloneDX, e.g. to annotate with additional information.

Ah, so there are tools that have to run on the cyclonedx data after it
has been generated, because they need to inject data we have no way to
know in Buildroot?

This means that those tools can very well consume show-info to generate
the final cyclonedx, to begin with...

>  IMHO the cyclonedx file should be bit-for-bit reproducible, so this must
> _definitely_ generate the same version.

I do agree that it should be reproducible, but then I don't see how this
articulates around the "version property should be incremented every
SBOM generation."

Note that, if the version really has to be incremented every time the
cyclonedx data is generated, we could just use the UNIX timestamp, with
milli- or microsecond precision, which is in practice going to be
monotonically incrementing. It's not going to be a sequential +1 every
time, though...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot