Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a SBOM template in CycloneDX format #650

Merged
merged 1 commit into from
Nov 29, 2024
Merged

Conversation

hughsie
Copy link
Contributor

@hughsie hughsie commented Nov 25, 2024

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 pugixml that gets included into source control with substituted values that get populated automatically. I'm not super familiar with your project, 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.

hughsie added a commit to hughsie/uswid-data that referenced this pull request Nov 25, 2024
@zeux
Copy link
Owner

zeux commented Nov 25, 2024

I'm fine with including this if this helps package maintenance. Is it possible to move this file into scripts/ folder? I've tried to keep the root folder clean of various build and configuration files to the extent possible, as it makes it easier to browse the repository contents. Not sure what the restrictions on the build firmware tool are.

pugixml is most definitely a library. I don't really know what "cpe:2.3:a:" means, so I can't comment on whether that is correct or not :)

Improve supply chain security by including a SBOM file with substituted values.

This will be used to construct a composite platform SBOM.

Signed-off-by: Richard Hughes <[email protected]>
@hughsie
Copy link
Contributor Author

hughsie commented Nov 26, 2024

I'm fine with including this if this helps package maintenance.

Thanks!

Is it possible to move this file into scripts/ folder?

Absolutely, PR updated.

I don't really know what "cpe:2.3:a:" means, so I can't comment on whether that is correct or not :)

Ahh, it's a standard prefix, e.g. https://nvd.nist.gov/products/cpe/detail/DBE1F6C9-6048-48A0-B837-98A6097D58BA?namingFormat=2.2&orderBy=CPEURI&keyword=cpe%3A2.3%3Aa%3Aopenssl%3Aopenssl&status=FINAL

@zeux zeux merged commit 4bc1441 into zeux:master Nov 29, 2024
24 checks passed
@hughsie hughsie deleted the hughsie/sbom branch November 29, 2024 16:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants