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. The reason I've opened this pull request is because your project is either used in the build process of a firmware we care about (e.g. EDK II, or coreboot) or is built into the firmware binary itself. 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 containers or OS images 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 Jansson, 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. I also wasn’t 100% sure whether to mark the component as a library or application, so advice is welcome.

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.

Also, if you’re not happy with being labelled a supplier (which seems more appropriate from a SBOM point of view, but makes some open source maintainers uncomfortable) we can remove that bit.

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.

[JFreegman]

Unaffiliated bystander here. It's clear how this would reduce the amount of redundant work for the developers of closed source firmware that utilize these FOSS projects, which would in turn reduce development costs. What's not clear is how shifting this workload onto the maintainers of these projects would benefit them. Will those savings be used to compensate them for their work?

[Zer0-One]

Yeah, I'm pretty confused at why this SBoM stuff should be handled upstream at all. I don't maintain Jansson, but I do use it in several projects, both proprietary and FOSS, and on its face, this just seems like random clutter from a totally unrelated project.

[hughsie]

It's clear how this would reduce the amount of redundant work for the developers of closed source firmware that utilize these FOSS projects

Ohh it's used by open source firmware projects like coreboot too -- and also anything else that wants to generate SBOM metadata of open source components. For example it would make complete sense to use this template to add information to a Linux container -- so instead of just having jansson == 2.13.1-10.fc41.x86_64 in the SBOM you'd also get the upstream team responsible, an upstream defined licence and a link to the source code.

What's not clear is how shifting this workload onto the maintainers of these projects would benefit them.

So there's a nice answer and a not so nice answer. The nice answer is that I've done basically all the required work, and the only maintenance work required from upstream would be to modify the file if the source control location changed (e.g. moving from GitHub to GitLab) or if the project name changed -- which seems quite unlikely. All the @TOKEN@ values are designed to put the onus on the generator to populate -- which means the upstream maintenance team doesn't have to do anything additional at release time. The SBOM file doesn't even have to be in the release tarball.

The not so nice answer is that various big consumers of open source (the ones paying for it) are increasingly wanting full SBOM data for all components in their supply chain. If a specific open source library can't supply that, then the answer is for the user of that library to write one themselves (that may be wrong, or one that upstream disagrees with) -- or the nuclear option is just to stop using the library without the SBOM data and to use a different [proprietary] one instead that does. I don't think that's going to happen very much, but it's certainly a consideration when deciding what new libraries people are going to use. It's certainly not a roadblock I would want (as an open source maintainer myself) for the sake of a tiny little additional file.

Yeah, I'm pretty confused at why this SBoM stuff should be handled upstream at all.

It gives open source maintainers the power to set the SBOM fields how hey feel comfortable. e.g. some projects are happy to be suppliers, and some want to just be authors. Some want individual names listed of the maintainers, some want something like The OpenSSL Project Authors instead.

this just seems like random clutter from a totally unrelated project.

I do understand the clutter argument. I'd be fine if this was .sbom.cdx.json or hidden in doc/ instead -- what I'm trying to do is give upstream maintainers the power to do things as they want to do -- the very last thing I'd want to do is make anyone feel disempowered. I've been working on Open Source software for about 20 years now, and it's something I care very deeply for. I think having a firmware SBOM that explicitly says "Using Jansson v2.14" is something that the Jansson developer team can be very proud of, and maybe even promote the use of Jansson itself and open source software more generally. Also please bear in mind I don't work for a firmware company -- I work at Red Hat -- I don't care about closed source firmware very much, but I do care very much about the wider open source ecosystem. I wouldn't be doing any of this hard work, mostly in my spare time, if I didn't believe it was for good.

There's more information about this specific initiative here https://blogs.gnome.org/hughsie/2024/11/14/firmware-sboms-for-open-source-projects/ and also https://lvfs.readthedocs.io/en/latest/sbom.html which gives a pretty good overview of SBOMs and firmware more generally. I hope that helps.