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 OpenSSL (or pkcs11-provider more specifically), 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.

Reviewer's checklist:

• Any issues marked for closing are addressed
• There is a test suite reasonably covering new functionality or modifications
• This feature/change has adequate documentation added
• Code conform to coding style that today cannot yet be enforced via the check style test
• Commits have short titles and sensible commit messages
• Coverity Scan has run if needed (code PR) and no new defects were found

[simo5]

@hughsie there isn't a lot of data in this file, what maintenance on it is expected?
My only concern is that info in this file will become stale and incorrect.
Is there any reason why that data can't be completely extracted automatically just form the github project?

[hughsie]

there isn't a lot of data in this file, what maintenance on it is expected?

Very little. I'll need updating if pkcs11-provider changes it's name, license or version control -- but otherwise it's static.

My only concern is that info in this file will become stale and incorrect.

Right; I think it's much less likely to be stale upstream than the BIOS vendors hardcoding it. Also we have a dumping ground which I'm really trying to push upstream: https://github.com/hughsie/uswid-data -- e.g. see https://docs.google.com/spreadsheets/d/1gKEWLxdLubOfgS1cqqY2umEX0ohYEoEy-B1i59HNVqg/edit?usp=sharing

Is there any reason why that data can't be completely extracted automatically just form the github project?

We wanted to provide something trusted that the upstream project could modify -- e.g. some upstream projects don't always want to be listed as a supplier, some just want to be authors. It's also dangerous to assume that the CPE is the github URL (although it is in the case of pkcs11-provider...) and that the superset license of the project is defined in ./COPYING or ./LICENSE. We do have an importer that works from pkconfig files too, although putting the CPE name and SPDX license there is a bit weird -- but more importantly most build tools expect to ingest a SPDX or CycloneDX file with minimal post-processing.

All the firmware OEMs are being leaned on heavily to produce SBOMs for system software and I think it's much better to put the upstream communities in control of what gets shown. Hence this PR :)

[simo5]

@hughsie do you have time to fix the style (you can use make check-style-fix and amend) and add an exception for the license check in .reuse/dep5 ?

[hughsie]

do you have time to fix the style

Of course! I'm the instigator, I can fix up issues :)

[simo5]

Thank you for the contribution!