Add a SBOM file 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 both) 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 libspdm, 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.

Also, if you’re uncomfortable with being labelled a supplier (which seems more appropriate from a SBOM point of view, but makes some open source maintainers uncomfortable) we can change the tag to “authors” as the tool that ingests this data can accept either.

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.

[steven-bellock]

Semi-related issue: #2845 and @HeikeGilg for visibility.

@hughsie how does the CycloneDX distinguish between development branches and "official" releases?

[hughsie]

how does the CycloneDX distinguish between development branches and "official" releases

We're using the git tag, so in the SBOM file you'd get something like 3.5.0 as the version for an official release, and something like 3.5.0-12-d0da67f3 for an unofficial git checkout. There are some examples here: https://github.com/hughsie/python-uswid?tab=readme-ov-file#substituted-values

[steven-bellock]

So ideally we'll have an automated tag / release process that auto-fills the appropriate tokens.

[jyao1]

@hughsie, CI failed due to no "Signed-off-by" tag. Would you please to add it?

[hughsie]

So ideally we'll have an automated tag / release process that auto-fills the appropriate tokens.

Ahh, this is done, magically. If you check out tag 3.5.0 as part of the firmware build process the VCS_VERSION in the libspdm SBOM file will be exactly that; if you check out main then the VCS tag will be something like 3.5.0-12-d0da67f3. There's a load more detail in https://docs.google.com/presentation/d/1OPBHYZAr9SWDrmXpistJrVqd8wdN94oOfDfFXoEjTxg/edit?usp=sharing if you'd like to see the bigger picture.

CI failed due to no "Signed-off-by" tag. Would you please to add it?

The original commit had it, I think the github "accept suggestion" probably confused it. I've rebased and updated the PR, thanks all!

[steven-bellock]

GitHub releases that are downloaded, for example https://github.com/DMTF/libspdm/archive/refs/tags/3.5.0.zip, do not contain a .git directory; it's just the files, and so presumably the release process would need to fill in any fields that depend on Git.

[hughsie]

@steven-bellock right, that's true. In the two cases I personally care about (coreboot and EDK II) libspdm is checked out as a git submodule, and I'm not sure how many people use tarballs like that now. What we do in fwupd is additionally use the uswid tool to populate the values at release time, i.e. https://github.com/fwupd/fwupd/blob/main/contrib/meson.build#L15 -- I'm not entirely sure how to do the same thing with cmake, but I think it should be broadly similar. The only fly in the ointment is that the .zip file generated by github won't have this generated file, but will have the source file. I'm open for ideas really.

[steven-bellock]

For SBOMs, this becomes a larger question for the DMTF. In particular the entire DMTF should standardize on an SBOM format(s). I'll bring this up at the larger DMTF working groups like SPDM and the Technical Committee.

[hughsie]

For SBOMs, this becomes a larger question for the DMTF.

Probably true.

In particular the entire DMTF should standardize on an SBOM format(s).

DMTF does have an SBOM format: SWID -- it's just a shame hardly nobody uses it. If they do want to use SWID out of principal rather than SPDX (ISO) or CycloneDX let me know as the uswid tool can import/export in SWID format too and I can re-do the pull request to use that.

I'll bring this up at the larger DMTF working groups like SPDM and the Technical Committee.

Great, thanks. I'm happy to be malleable; the trusted data is the bit I care about, the format less so.