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

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

Thomas, All,

On 2024-04-10 22:10 +0200, Thomas Petazzoni spake thusly:
> On Wed, 10 Apr 2024 21:26:09 +0200
> Arnout Vandecappelle <arnout@mind.be> wrote:
> > > 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.  
> >   Huh? It's equally worthless as the images created by Buildroot then. Those are 
> > also uncontrollable. Of course, you have no guarantee that the SBoM corresponds 
> > to the image that gets shipped to customers, but that's not really relevant. You 
> > can still use the SBoM to see which packages get installed, which patches are 
> > applied, which CVEs apply, which licenses are used, etc.
> Yes, I agree the argument from Yann here is a bit dubious, but do we
> care?

What I meant here, is that the environment on a developper's machine is
unknown, so there is no way one can produce an SBOm there, that is
meaningful. If the developper has an override-srcdir or a local.mk with
arbitrary stuff, then this is not reproducible, and this should not be
used to tag a release.

Where an SBOM is usefull, is when it is generated for a release, so that
it can traval along it. A release should be done in a constrained,
reproducible environment, like a CD pipeline.

> >   And anyway, I don't think it's very relevant if this SBoM generation happens 
> > on a developer machine or in CI. In either case, I don't think we want to rely 
> > on a host-installed Python version.
> Why?

Indeed, why? As far as I see, such a script would only need modules from
the stdlib (json, maybe subprocess, re, and similar). We'd just need to
state that Buildroot requires a python3.8+ on the host, which to be
honest would hugely help in simpifying our other scripts...

We indeed currently do not require such a python to be present, as
that's not part of our requirements.

> > > We should now drop printvars.  
> >   OMG, I completely forgot about show-vars! But indeed, we still need to keep 
> > show-vars. And we should drop printvars.
> We don't care about backward compatibility?

Yes, but printvars is riddled with issues, and show-vars as been around
for a while already...

> > > 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  
> >   Anyway, for me replacing show-info is not the most important thing, it's more 
> > a nice-to-have. What I don't want is to generate CycloneDX by post-processing 
> > the show-info output, because it turns out that that is still fairly complicated 
> > and it's just easier to directly generate CycloneDX from make.
> Why is it "fairly complicated"? It sounds to me that post-processing
> show-info into a simple and nice Python script to generate CycloneDX is
> not at all "fairly complicated" but rather "fairly simpler" than doing
> it in make.

Here 's even a little patch that would allow to write everything in
python, and generate the thign as part of the standard build process
(which I would not suggest, but for the sake of the argument):

    commit ccf4722ae0a9755aa73c9c1eaa2a6935b77d7a7c
    Author:     Yann E. MORIN <yann.morin.1998@free.fr>
    AuthorDate: Wed Apr 10 22:25:11 2024 +0200
    Commit:     Yann E. MORIN <yann.morin.1998@free.fr>
    CommitDate: Wed Apr 10 22:42:51 2024 +0200

        Makefile: cyclonedx from show-info ezpz

        Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

    diff --git a/Makefile b/Makefile
    index d1caec63b5..344f72244a 100644
    --- a/Makefile
    +++ b/Makefile
    @@ -497,7 +497,7 @@ export BASE_DIR
     #
     ################################################################################

    -all: world
    +all: world sbom-all

     # Include legacy before the other things, because package .mk files
     # may rely on it.
    @@ -918,20 +918,37 @@ check-dependencies:
         @cd "$(CONFIG_DIR)"; \
         $(TOPDIR)/support/scripts/graph-depends -C

    +SHOW_INFO = \
    +    $(call clean-json, \
    +           { $(foreach p, \
    +                   $(sort $(foreach i,$(PACKAGES) $(TARGETS_ROOTFS), \
    +                                   $(i) \
    +                                   $($(call UPPERCASE,$(i))_FINAL_RECURSIVE_DEPENDENCIES) \
    +                           ) \
    +                   ), \
    +                   $(call json-info,$(call UPPERCASE,$(p)))$(comma) \
    +           ) } \
    +    ) \
    +
     .PHONY: show-info
     show-info:
         @:
    -    $(info $(call clean-json, \
    -                   { $(foreach p, \
    -                           $(sort $(foreach i,$(PACKAGES) $(TARGETS_ROOTFS), \
    -                                           $(i) \
    -                                           $($(call UPPERCASE,$(i))_FINAL_RECURSIVE_DEPENDENCIES) \
    -                                   ) \
    -                           ), \
    -                           $(call json-info,$(call UPPERCASE,$(p)))$(comma) \
    -                   ) } \
    -           ) \
    -    )
    +    # Use $(foreach...) like for show-vars, just in case
    +    $(foreach i,$(SHOW_INFO),$(info $(i)))
    +
    +sbom-all: sbom-buildroot sbom-cyclonedx
    +
    +.PHONY: $(O)/info.json
    +$(O)/info.json:
    +    $(file > $(@),$(SHOW_INFO))
    +
    +.PHONY: sbom-buildroot
    +sbom-buildroot: $(O)/sbom.json
    +    @:
    +
    +.PHONY: sbom-cyclonedx
    +sbom-cyclonedx: $(O)/sbom.json world legal-info
    +    $(TOPDIR)/support/scripts/cyclonedx --show-info=$(<) --legal-info=$(LEGAL_INFO_DIR)

     .PHONY: pkg-stats
     pkg-stats:

Also: badly tab-mangled, but that's just for the example, not meant to
be applied. Totally untested, although I already had the SHOW_INFO
variable implemented a while back already, and IIRC that was working.

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