Add a SBOM template in CycloneDX format

[hughsie]

Hi,

My name is Richard Hughes and I'm a developer at Red Hat. I'm the maintainer of fwupd and LVFS, and am trying to improve software supply chain security by encouraging OEMs, ODMs and IBVs to ship Software Bill of Materials with each firmware binary blob (SBOMs).

I'm working alongside lots of other companies proactively trying to do the right thing. Although my personal focus is on firmware, the SBOM file is in CycloneDX format (one of the most popular industry standards) which makes it also useful when building CI targets too.

I would like to contribute this template SBOM file into your project that gets included into source control with substituted values that get populated automatically. I'm not super familiar with EDK, and so I've done my best populating the project values -- but please point out any that are incorrect and I'll fix them up. I've also put the sbom.cdx.json file in what I feel is the right place, but please say if you want me to put it somewhere different or name it a different thing; the directory and sbom prefix are unimportant.

The various firmware build tools will take these incomplete SBOM files and then build them into a complete composite SBOM to represent the firmware. Having an upstream reference to what the PURL and CPE values should be means we have something we can trust; I could quite easily spin up a web-service that we say "what CPE do we use for X" -> "cpe:2.3:a:Y:Z::::::::` but we don't actually know if that's still true, up to date, or what the maintainer actually wants them to be. Putting the template upstream means we can trust the values we find in the checked out code during the build process.

I've written a bit more about this proposal here https://blogs.gnome.org/hughsie/2024/11/14/firmware-sboms-for-open-source-projects/ and there's also lot more information about firmware SBOMs here: https://lvfs.readthedocs.io/en/latest/sbom.html – many thanks for your time and all the work that you do.

[bexcran]

The PatchCheck is probably failing because one line in the commit message is 80 characters (i.e. over the 72? 73? limit).

[hughsie]

@bexcran the checkpatch seems to be lots of:

 * Line ending ('\n') is not CRLF
   File: sbom.cdx.json
   Line: {
 * Line ending ('\n') is not CRLF
   File: sbom.cdx.json
   Line:   "bomFormat": "CycloneDX",

Do you really want this with CRLF endings? I've never tested uswid (or any of the other SBOM tools) with Windows line-endings, but I'm not against starting :)

[bexcran]

Do you really want this with CRLF endings? I've never tested uswid (or any of the other SBOM tools) with Windows line-endings, but I'm not against starting :)

Unfortunately the edk2 repos are configured to require CRLF line endings unless specifically excluded - for example Makefiles need to use LF. So we probably will need to use CRLF for now, if possible.

[hughsie]

So we probably will need to use CRLF for now

Done! Thanks for explaining, TIL.

[leiflindholm]

Hi @hughsie, all for this.
I do think it should live in some subdirectory, but we don't have a good one yet. And we're starting to see significant littering of the top-level, so we will need to look into that. But that shouldn't gate the PR.

There are some aspects I'm unclear on, which ... may be better suited for the mailing list?
Like, is there a defined way of treating submodules? And if we add this file, shold we also add (minimal) documentation, and if so, what?

[hughsie]

so we will need to look into that.

Thanks.

There are some aspects I'm unclear on, which ... may be better suited for the mailing list?

Happy to discuss there; but which mailing list is most suitable?

Like, is there a defined way of treating submodules?

If you mean git submodules the plan is this: https://docs.google.com/presentation/d/1OPBHYZAr9SWDrmXpistJrVqd8wdN94oOfDfFXoEjTxg/edit?usp=sharing -- i.e. each thing like openssl (and deps, and deps of deps) gets the same kind of SBOM file. I'm about 85% through all the deps already.

And if we add this file, shold we also add (minimal) documentation, and if so, what?

Sure, I'm happy to do that too -- I'd need a little guidance on format and location. Long term they'll also be per-module data (as in new things in ShellPkg/* SignedCapsulePkg/* -- but I need to discuss more with the IBVs on whether adding SBOM information to the existing inf file is the plan, or whether duplicating information from the inf file into a new per-module SBOM file is what we want to do. I'm erring on the latter but it's a huge job and there's a lot of confounding factors because the OBVs typically don't just use edk, there's a lot of secret "value added" source too.

[leiflindholm]

Happy to discuss there; but which mailing list is most suitable?

I guess [email protected] or [email protected]. Both valid, but I tend to default towards devel.

If you mean git submodules ...

Yes, exactly, thanks.
That makes a lot of sense, but I'm wondering about things like "what about builds that don't actually use all of the submodules". It's obviously the supplier's responsibility ultimately, but I was wondering if there was anything already planned/written about how they are supposed to handle that?

[hughsie]

I'm wondering about things like "what about builds that don't actually use all of the submodules".

Yes, that's a good question I don't have a good answer for yet. I suspect we'll want something like --exclude when building the SBOM to avoid the components that are checked out but unused.