Software Bill of Materials

[Richard Hughes]

On Thu, 17 Mar 2022 at 22:21, Patrick Williams <patrick at stwcx.xyz> wrote:
> there appears to be a good amount to digest.

Yes, agreed!

> I believe most of our BMC images actually are much simpler than you've laid out
> here.  Typically it really is just the BMC code and images for any other devices
> are updated independently.  For the BMC that means u-boot, kernel, rootfs.

Ahh, no binary BSP/FSP does make things a lot easier.

> Do you know if there has been any effort put into this at a Yocto level?
> bitbake already has all the source code used to build our image and all the
> metadata about how it was built.  It seems like they could add the SBoM to their
> build process, if you wanted it on each package in the rootfs.

Not bitbake, but there are people doing the same kind of thing in the
EDK2 tree, i.e. generating the SWID metadata at build time
automatically with a "vendor.ini" file in the toplevel to provide
entity details.

> Alternatively, would something as simple as the git-commit of the Yocto
> metadata used to build the image be sufficient for a SBoM?

It's some of the metadata we need, but it's not the "who built" part
-- which is the most important bit from a SBoM point of view.

> The Yocto metadata
> itself contains hashes (or git-commits) of the source for each package
> bitbake built.  I don't know how far down into the onion you're expected to peel
> for whatever these SBoM hashes are.

That's a valid question. I'm guessing less granularity is fine -- as
it's not like your kernel was built by a different legal entity to the
openbmc binaries -- it's all done at the same time.

> I'm not really sure where to go from here.  It seems like, since we've built
> everything on top of Yocto, having someone go write a bbclass that creates
> whatever coSWID data you want from existing information the bitbake recipes
> already have would be the start.

Agree. I'll take this discussion to the Yocto mailing list, and then I
guess OpenBMC gets this "for free" too. Many thanks for the speedy
reply, it's most appreciated.

Richard.