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 Wuffs, 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 couldn’t find any existing CVEs that reference your project (a good thing!), so I’ve created a CPE reference that seems plausible. Please let me know if you know of a better CPE to use.

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 Google 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.

[nigeltao]

I'm largely OK with this but I'm not very familiar with this area. I asked my Google colleague B.L., who has more SBOM experience. I'll quote extracts of what he told me below but the general vibe was also a little confusion, in that he thought SBOMs were more for releases instead of libraries (and even more so for open source libraries). Anyway...

---

You said:

I couldn’t find any existing CVEs that reference your project (a good thing!), so I’ve created a CPE reference that seems plausible. Please let me know if you know of a better CPE to use...

Having an upstream reference to what the PURL and CPE values should be means we have something we can trust;

I don't know how PURLs and CPEs are used but I'll note that your JSON file mentions "cpe" but not "purl". Also, B.L. said:

I think in this case, a PURL would also be helpful - and perhaps more fitting for open source libraries, if any of the purl types make sense.

CPEs generally I've seen more for product use, and not sure if its as useful in this case. My opinion would be to use PURLs here instead of a CPE.

---

You said:

Also, if you’re not happy with Google 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.

B.L. said:

If Google is the one producing the release and distributing it, then Google is the supplier of the software... If the SBOM is for the distributed binary... then "Google LLC." as supplier sounds good. If its for the library, I think I'd defer to [another set of colleagues for advice].

I'll ask that other set of colleagues for their advice. Let me get back to you.

---

Coming back to me (instead of my colleague B.L.)...

Wuffs has no dependencies. Should we represent that explicitly in the JSON template somehow?

---

There is also the https://github.com/google/wuffs-mirror-release-c repo, which basically mirrors the release/c directory of this repo. For example, coreboot's copy of wuffs comes from the mirror repo.

Should I also update the mirror repo to also pick up doc/sbom.cdx.json?

---

A final unrelated tangent.

I've written a bit more about this proposal here https://blogs.gnome.org/hughsie/2024/11/14/firmware-sboms-for-open-source-projects/

Ah, b.g.o. I also used to write at https://blogs.gnome.org/nigeltao/ but that was a looooong time ago.

[nigeltao]

I'll note that your JSON file mentions "cpe" but not "purl"

Ah, your JSON file says:

"bom-ref": "pkg:github/google/wuffs@@VCS_TAG@"

Is that a github PURL key-value pair, even though that line doesn't literally contain the string "purl"?

[hughsie]

I don't know how PURLs and CPEs are used but I'll note that your JSON file mentions "cpe" but not "purl".

Right, as you noticed the PURL is what I chose as the bomRef. If you'd rather make it explicit (i.e. move it to the purl attribute) that's completely fine -- the tools will just "move" it to the bomRef at build time.

Wuffs has no dependencies. Should we represent that explicitly in the JSON template somehow?

The deps are autopopulated by fwupd right now, so no deps section plus no submodules would get you no deps. I don't think you can specify "none" in CycloneDX now.

Should I also update the mirror repo to also pick up doc/sbom.cdx.json?

I didn't know about this, but I think so. Lets get this one good enough to merge and then I can do another PR if you'd like.

but that was a looooong time ago

Well, it's great to meet another old GNOMEie. :)