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 oqsprovider 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 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 couldn’t find any existing CPE values in CVEs that that reference your project, 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 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.

If it helps, there's also an open pull request for OpenSSL and quite a few other deps of OpenSSL.

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.

[baentsch]

Thanks for touching base and explaining the background, @hughsie .

The reason I've opened this pull request is because oqsprovider is either used in the build process of a firmware we care about

This gives me the creeps: We very clearly don't want anyone to think this software is something anyone should rely on, see https://github.com/open-quantum-safe/oqs-provider?tab=readme-ov-file#disclaimers : This is prototyping-and-research-only software with many known deficiencies, without serious support and many open issues that a reliable project would need to address, see e.g., "meta-issue" #483.

I'm not super familiar with your project

This confuses me a bit -- are you saying you are integrating software you are not truly familiar with? What level of familiarity should be assumed/expected for (any person) using this software/creating integrations (both, in terms of creation and reliance on/usage of this SBOM file)?

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

Sorry, I don't even know what CPE values are. Could you explain?

All told, I tend to not want this file in the project to avoid further misconceptions pertaining to the utility and quality of this software. Or is there a way to codify a "productive-use-disallowed indicator" in this description format so everyone in the supply chain knows about this limitation?

[hughsie]

This gives me the creeps: We very clearly don't want anyone to think this software is something anyone should rely on

Eeek. I'll pass that onto the firmware teams!

are you saying you are integrating software you are not truly familiar with

No me personally; what I've done is asked the various OEMs, ODMs and IBVs (e.g. AMI, Phoenix, Insyde etc) "what open source projects do you build into firmware" so that I can get them to use the accurate upstream-approved values rather than the terrible generic fallbacks. It'll also elevate the public perception of the role of open source in "closed source" firmware as at the moment most people think the "BIOS blob" is 100% closed source software when it's nothing like that in reality.

Sorry, I don't even know what CPE values are. Could you explain?

Sure, sorry. I should have expanded out CPE with a link. CPE is a cross-ecosystem method to identify different software: https://nvd.nist.gov/products/cpe -- it's only been used for software with existing CVEs, and although I could find some CVEs for oqsprovider curiously they didn't have a CPE. It's also another thing I want upstream to control, rather than letting some random CNA doing something plausible.

Or is there a way to codify a "productive-use-disallowed indicator" in this description format so everyone in the supply chain knows about this limitation?

That's a good question. I don't know of one, but we could certainly put something scary in the description. e.g. something like Open Quantum Safe provider for OpenSSL (NOT RECOMMENDED FOR PRODUCTION USE)

[baentsch]

I'll pass that onto the firmware teams!

Thanks!

most people think the "BIOS blob" is 100% closed source software when it's nothing like that in reality

Indeed, interesting. I also thought so. Even more "Eeek".

I want upstream to control, rather than letting some random CNA doing something plausible.

:-) Now begging the question what CNA is :-) But the CPE explanation (thanks for the link!) imo clearly states via

the CPE Product Dictionary will continue to grow to include all past, present and future product releases

that it applies to products -- and oqsprovider clearly is no product (in the sense that it has solid support, product management, any sort of guarantees, etc.). So maybe a lack of "CPE" already is an indication of the "entity described" is not suitable for "serious consumption" (?) and an alternative answer to

we could certainly put something scary in the description. e.g. something like Open Quantum Safe provider for OpenSSL (NOT RECOMMENDED FOR PRODUCTION USE)

This description may be misleading imo: It is technically correct but may imply it inheriting the same quality properties provided by OpenSSL -- which definitely is not the case and the reason why there's a completely separate activity within OpenSSL to make these algorithms available (see e.g., openssl/openssl#25882, openssl/openssl#25848). From that perspective, something like "Research and prototyping OSSL provider for post quantum cryptographic algorithms (NOT RECOMMENDED FOR PRODUCTION USE)" may be better.

[hughsie]

Now begging the question what CNA is

I'm terrible at expanding TLAs I'm afraid :)

oqsprovider clearly is no product

Right; I think this is correct from a strict SBOM viewpoint, but I do understand the concern. Maybe I drop the CPE line completely?

something like "Research and prototyping OSSL provider for post quantum cryptographic algorithms (NOT RECOMMENDED FOR PRODUCTION USE)" may be better.

Works for me, although I can imagine the eyebrows of a pointy-haired boss somewhere. One thing we could use is the tokens DO NOT TRUST or DO NOT SHIP which are picked up by security scanners like the LVFS to identify stuff that should never see the light of day in a production firmware.

[baentsch]

I'm terrible at expanding TLAs I'm afraid :)

TLA fortunately I know. CNA I don't.

Maybe I drop the CPE line completely?

IMO sensible -- also resolves your question above :)

Works for me, although I can imagine the eyebrows of a pointy-haired boss somewhere. One thing we could use is the tokens DO NOT TRUST or DO NOT SHIP which are picked up by security scanners like the LVFS to identify stuff that should never see the light of day in a production firmware.

Good first step -- but again relies on assumptions which (only some) scanners may pick up.

And honestly, I'd think it'd be goodness to raise more than the eyebrows of the pointy-haired bosses: They should know what they're getting (into) -- so their hairs get even more pointed :-)

More seriously: I'd really like to suggest adding a defined "do not use productively" flag in this file format so that no-one can claim ignorance -- particularly if there is more than just one FOSS package used that may bear this classification (and there's surely quite a few): This seems to me a reasonable way to convince the pointy-haired bosses of the world to pay up (by contributions, better tests, reviews, dev support time, etc) for software they'd otherwise use for free to please their money-pinching, shareholder-pleasing executives that think FOSS is a simple way to get nice PR but otherwise save development expenses. Reasonable? If so, do do know how/where to initiate that (if not already done), @hughsie ?

[hughsie]

Maybe I drop the CPE line completely?
IMO sensible -- also resolves your question above :)

Done, PR updated -- I hope that's okay.

More seriously: I'd really like to suggest adding a defined "do not use productively" flag in this file format

We already have that in the SWID format, but we didn't really support it properly. It's plain text rather than a nice boolean or enumerated type, but it also means we can use the DO NOT SHIP token too.

to please their money-pinching, shareholder-pleasing executives that think FOSS is a simple way to get nice PR but otherwise save development expenses.

I don't disagree -- I think the firmware companies have had lots of free rides so far. One of my personal reasons of making the Open Source contributions much more visible is that we can then go to the companies involved and say "90% of your OEM firmware contains OpenSSL, how much do you contribute to their ecosystem?" -- i.e. the data is in the public domain and anyone can see what's really in the firmware "binary".

Reasonable? If so, do do know how/where to initiate that (if not already done), @hughsie ?

hughsie/python-uswid#68

[hughsie@hughsie-work-lan oqs-provider (hughsie/sbom *)]$ uswid --load ./sbom.cdx.json --validate
Validation problems:
pkg:github/open-quantum-safe/oqs-provider@NOASSERTION  component: Software should not be used in production (uSWID >= v0.5.1)

[baentsch]

Thanks for these updates addressing my utility concerns @hughsie . I'm still surprised to see that there is only a "notes" section to declare actual utility of a component in this file, though.

Independently of that, I've got to ask whether this file now is semantically correct: oqsprovider depends on liboqs and openssl: Shouldn't those dependencies also be captured somehow in this file or does that happen via another mechanism (looking at cmake files, e.g.)?

[hughsie]

Thanks for these updates addressing my utility concerns @hughsie . I'm still surprised to see that there is only a "notes" section to declare actual utility of a component in this file, though.

Yes, there's nothing concrete in the spec. I'm working with some other implementers on what would be the best way to do this long term. Now it's committed to uswid, whatever we decide we'll also support the [interim?] solution I pushed here.

Independently of that, I've got to ask whether this file now is semantically correct: oqsprovider depends on liboqs

Agreed; if you approve of the direction of this PR then I'll do a similar one for liboqs; I didn't want to flood open source maintainers with unwanted PRs.

and openssl: Shouldn't those dependencies also be captured somehow in this file

It's mostly automatic; uswid adds dependencies on modules by scanning the tree. e.g. see slide 10 in https://docs.google.com/presentation/d/1OPBHYZAr9SWDrmXpistJrVqd8wdN94oOfDfFXoEjTxg/edit?usp=sharing

Once the others are committed (e.g. see https://docs.google.com/spreadsheets/d/1gKEWLxdLubOfgS1cqqY2umEX0ohYEoEy-B1i59HNVqg/edit?usp=sharing for progress...) then we can also add explicit deps too if this would make you more comfortable.

i.e. don't think this PR is "fire and forget" -- it's likely you'll hear from me again if the NTIA adds additional "required elements" or if we expand the scope of how deps are collected. :)

[SWilson4]

It's mostly automatic; uswid adds dependencies on modules by scanning the tree. e.g. see slide 10 in https://docs.google.com/presentation/d/1OPBHYZAr9SWDrmXpistJrVqd8wdN94oOfDfFXoEjTxg/edit?usp=sharing

Once the others are committed (e.g. see https://docs.google.com/spreadsheets/d/1gKEWLxdLubOfgS1cqqY2umEX0ohYEoEy-B1i59HNVqg/edit?usp=sharing for progress...) then we can also add explicit deps too if this would make you more comfortable.

I noticed in this spreadsheet that oqs-provider is "needed for" OpenSSL. I'm guessing that oqs-provider was added as a dependency because OpenSSL's git repo has oqs-provider as a submodule—is this correct? If so, is there another path that leads to oqs-provider as a dependency, or is the OpenSSL git submodule the only one?

If an auto-detected OpenSSL git submodule is indeed the only reason for its inclusion in the above table, then I feel like the statement

oqsprovider 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

is a little strong: as far as I am aware, the use of oqs-provider in the "build process" of OpenSSL is limited to CI testing as an (important) example of an external crypto provider. The actual build steps do not rely on oqs-provider at all. In particular, a bug or a vulnerability in oqs-provider would not compromise the OpenSSL build. It is a very "soft" dependency. Perhaps this points to the need for a third category in the statement above?

If the only (known) path leading from "firmware we care about" to oqs-provider is firmware --> OpenSSL --> oqs-provider (but only for testing), then I for one will breathe a sigh of relief :)

[baentsch]

I for one will breathe a sigh of relief :)

Same here. +2 actually :). Didn't look at the spreadsheet, so thanks for the diligence, @SWilson4 !

@hughsie if this "spreadsheet-only" dependency is the only reason for this PR (?), then, please, let's close this PR without merge: OpenSSL will use an entirely different code base for PQC -- not yet landed, but in "final approach" using pilot terminology :) oqsprovider indeed (also for OpenSSL as well as many other venues) first and foremost is a testbed.

[hughsie]

if this "spreadsheet-only" dependency is the only reason for this PR (?), then, please, let's close this PR without merge

So, the spreadsheet was populated by the IBVs on my asking what deps they use -- so I have a sneaking suspicion one of them is actually doing what you feared. If we merge this then the DO NOT TRUST bubbles all the way up to the final firmware binary and then it'll be blocked on the LVFS before deployment.

i.e. I think merging the DO NOT TRUST note still makes a lot of sense after learning all about the bigger picture of where oqs is at. It also means I can identify any firmware doing the wrong thing and then have some stern words with the supplier.

[baentsch]

OK under the proviso that the note in the file regarding (limited) utility indeed "bubbles up" in the supply chain and is not getting dropped somewhere along the way (i.e., mere presence of SBOM template lets users falsely assume this is supported product software). --Greetings from your random guy from Nebraska, err Switzerland :)

[hughsie]

and is not getting dropped somewhere along the way

Right; I'll make this crystal clear in the UEFI meeting today. I'm also going to try and flush out who added the spreadsheet line :)

Greetings from your random guy from Nebraska, err Switzerland :)

I hear you in "the one English bloke that builds all of fwupd and LVFS" :/

[baentsch]

Thanks, @hughsie -- Oh, and can't resist asking about the TLA IBV: Hopefully none in https://acronyms.thefreedictionary.com/IBV !?! :-)

[hughsie]

Oh, and can't resist asking about the TLA IBV

I DID IT AGAIN. Sorry! :) IBV is "independent BIOS vendor", aka. Insyde, AMI and Phoenix are the big three.