* [Lvfs-announce] Adding SBoM metadata to firmware images
@ 2022-10-08 12:20 Richard Hughes
0 siblings, 0 replies; only message in thread
From: Richard Hughes @ 2022-10-08 12:20 UTC (permalink / raw
To: lvfs-announce
Hi all,
I’m going to soon merge a pull request which indicates to end users
which firmware contains a Software Bill of Materials. You can see a
screenshot in https://gitlab.com/fwupd/lvfs-website/-/merge_requests/1376
Why is SBoM important?
* The US government tells everyone it is
* Soon the US government (via an anticipated updated Executive Order)
is going to make a SBoM a _hard requirement_ for software (including
device firmware) sold to the US government
* It is probably a good thing to provide to end-users for security
So what do I want you to do?
Some vendors are already shipping SBoM metadata, and for those of you
that are, I really appreciate you being proactive with this and no
further action is required.
For the other vendors you need to start providing this data otherwise
you might have to scramble in the future. I should stress that SBoM
should be a requirement for ALL firmware, e.g. mouse, radio-receiver,
modem, gamepad – not just UEFI system firmware.
Okay, so we have to do something!
I want you to include the SBoM metadata in the next version of your
firmware binary. Let's do an example for a fictitious mouse:
Lets create an example.ini file:
[uSWID]
tag-id = acbd84ff-9898-4922-8ade-dd4bbe2e40ba
software-name = Runtime
software-version = 1.2.3
version-scheme = multipartnumeric
product = MN100
summary = MN100 Left Handed Mouse
colloquial-version = b2ed6f1ed8587bf01a2951d74512a70f1a512d38
[uSWID-Entity:TagCreator]
name = Hughski Limited
regid = hughski.com
extra-roles = SoftwareCreator
$ pip install uswid
$ uswid --load example.ini --save ./blob.uswid --compress
The tag ID is either a random UUID, or a string, e.g. “mn100-runtime”.
The ID should be unique enough to identify the internal firmware part,
so you’d use the same tag-id for version 1.2.4 of the firmware on the
next release, but NOT for the MN900 model, if you see what I mean. The
tag ID only actually needs to be unique within the individual SBoM,
and the LVFS isn't comparing them between uploads.
The colloquial-version should be the version control hash of the
source that was used to build the firmware blob – but like a lot of
the other fields – it is optional. Also note that the firmware doesn’t
have to be public; the colloquial-version can just be a hash value
that’s only really useful as an internal employee. See
https://github.com/hughsie/python-uswid/blob/main/README.md for a lot
more help on each field.
Then once you have generated a blob.uswid file (or whatever filename)
it can then be included into the firmware binary blob itself. This can
either be included in free space somewhere (at any offset) or included
into the source code or into the DATA section by the linker. The only
requirement is that the uSWID blob is unmodified and contiguous, i.e.
not split across pages or sections within the firmware artefact.
Remember that you might also need multiple ini files if you have a
bootloader or radio component; each generated lump of firmware from a
different entity or source-tree needs to be described with an accurate
SoftwareCreator so we know where it came from. If this makes you
nervous (e.g. you don't want people to know that Broadcom provides
your radio firmware) then ask me for more details as there's a way to
mask this from prying eyes.
Ideally, the example.ini is going to be auto-generated by the firmware
build system (as it can then auto-include dependencies into the SBoM),
although hand-generating it is fine too. If you then upload this new
firmware to the LVFS, it searches for the uSWID blob and if found, an
HTML and XML SWID download becomes available. Most importantly, the
little “cross” turns into a “tick”.
If you already include a SBoM in a non-uSWID (but open-access format)
also let me know and I'll add a parser to the LVFS so the tick
appears. There is also tooling for uSWID/coSWID in other languages
too, e.g. golang if that would be easier for you to integrate -- I
also don't mind if you write the uSWID blob using something entirely
custom; the specification is fully open.
Any questions (off list) most welcome, although a lot of them are
going to be covered in the uSWID README. Thanks.
Richard
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2022-10-08 12:20 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-08 12:20 [Lvfs-announce] Adding SBoM metadata to firmware images Richard Hughes
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.