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 -- e.g. for ChromeOS) 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 Brotli, 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.

[eustas]

Hello. Thanks for PR.

As I see, sbom json seems to be "sealed" i.e. it does not allow properties not mentioned in the spec. JSON format itself does not allow comments. And it would be nice if the file would explain itself what it is.

On the other hand - XML allows comment and also have clear URI to schema. Are those interchangeable? If yes, I'd prefer XML version with a tiny comment at the top (one sencence + link) about sbom.

[hughsie]

As I see, sbom json seems to be "sealed" i.e. it does not allow properties not mentioned in the spec.

Yes and no; the team behind the CycloneDX specification are pretty responsive; they seem very pragmatic so far. I also think it would be 100% fine to put something like:

{
  "_comment": "See https://cyclonedx.org/ for more details about this file",
  "bomFormat": "CycloneDX",

-- it's not 100% spec compliant, but it's okay for us to be pragmatic too I think.

JSON format itself does not allow comments. And it would be nice if the file would explain itself what it is.

I'm not sure what we can do here; at least if you google for sbom.cdx.json you get some pretty good answers.

On the other hand - XML allows comment and also have clear URI to schema. Are those interchangeable?

Not really; there is a XML version of the SBOM called SWID that was quite popular a few years ago, but was rapidly overtaken by ISO SPDX (json) and OWASP CycloneDX (json). So far I've seen SBOM metadata in about 60 different projects, and I'd say the split was about 90% CycloneDX and 10% SPDX. I can certainly import a SBOM.swid.xml file in uswid but the number of tools that can import SWID XML is much much smaller than the ones that absorb SPDX and CycloneDX.

If yes, I'd prefer XML version with a tiny comment at the top (one sencence + link) about sbom.

This would look something like this:

<?xml version='1.0' encoding='utf-8'?>
<SoftwareIdentity xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd" xmlns:SHA256="http://www.w3.org/2001/04/xmlenc#sha256" xmlns:SHA512="http://www.w3.org/2001/04/xmlenc#sha512" xmlns:n8060="http://csrc.nist.gov/ns/swid/2015-extensions/1.0" xml:lang="en-US" name="Brotli" tagId="pkg:github/google/brotli@@VCS_TAG@" tagVersion="1" version="@VCS_VERSION@">
  <Entity name="Brotli developers" role="softwareCreator"/>
  <Entity name="@VCS_SBOM_AUTHORS@" role="tagCreator"/>
  <Link href="https://github.com/google/brotli" rel="see-also"/>
  <Link href="https://spdx.org/licenses/MIT.html" rel="license"/>
  <Meta summary="A generic-purpose lossless compression algorithm" cpe="cpe:2.3:a:google:brotli:@VCS_TAG@:*:*:*:*:*:*:*" type="library"/>
</SoftwareIdentity>

It's up to you what format you'd like; it's the data that's important to me, the CycloneDX JSON file format is just our recommendation.

[eustas]

If we can add comment to JSON it is enough.

I'll check soon what cpe we're tracking.

[hughsie]

If we can add comment to JSON it is enough.

I've updated the PR with your suggestion.

I'll check soon what cpe we're tracking.

The one I found was https://nvd.nist.gov/products/cpe/detail/FA6D4636-68B4-470E-A353-C047C9F973CB?namingFormat=2.3&orderBy=CPEURI&keyword=cpe%3A2.3%3Aa%3Agoogle&status=FINAL

Thanks. Richard.

[eustas]

Looks good. But I'm not sure, if @VCS_TAG@ substitution for will work: our tag name convention is vX.Y.Z, but in CPE matcher it should be just X.Y.Z

[hughsie]

our tag name convention is vX.Y.Z, but in CPE matcher it should be just X.Y.Z

Ohh good catch! This is probably something I can handle in uswid -- other projects like jansson also include the v prefix too. I've never seen a non-semver in a CPE tag so I think it probably makes sense to sanitize everything we find to hex digits plus dot.