Introduce Heads' SBOM (OSFF grant)

[tlaurion]

WiP, will edit before doing PRs

State of the Art (prior work done elsewhere that is significative)

• nix buildstack
  • https://arnout.engelen.eu/blog/nix-state-of-the-sbom/
    • sbomnix
    • nix-sbom-helper
• coreboot
  • Dasharo/coreboot: extending SBOM Extend SBOM Dasharo/coreboot#859
  • src/sbom: push for further CRA compliance Dasharo/coreboot#938
• linux
  • Linux kernel SBOM : https://lwn.net/Articles/1055009/
• Heads modules/* SBOM implementation:
  • https://docs.google.com/spreadsheets/d/1gKEWLxdLubOfgS1cqqY2umEX0ohYEoEy-B1i59HNVqg/edit?usp=sharing (@hughsie provided SoA)

---

Grant Grant https://opensourcefirmware.foundation/funding/

[tlaurion]

@hughsie i see a looooot of issues you opened like Mbed-TLS/mbedtls#9777. Do you have pointers to the ones that implemented what you were looking for?

This would give guidance for linuxboot/heads modules/* (without making modules/*'s SBOM non-compliance a Heads issue per se)

IE:

user@debian-13:~/heads$ ls modules/* -al | awk -F " " {'print $9'}
modules/bash
modules/busybox
modules/cairo
modules/coreboot
modules/coreboot-blobs
modules/cryptsetup
modules/cryptsetup2
modules/dasharo-ec
modules/dropbear
modules/e2fsprogs
modules/exfatprogs
modules/fbwhiptail
modules/flashprog
modules/flashrom
modules/flashtools
modules/frotz
modules/gpg
modules/gpg2
modules/hidapi
modules/hotp-verification
modules/io386
modules/ioport
modules/json-c
modules/kbd
modules/kexec
modules/libaio
modules/libassuan
modules/libgcrypt
modules/libgpg-error
modules/libhidapi-libusb
modules/libksba
modules/libnitrokey
modules/libpng
modules/libusb
modules/libusb-compat
modules/linux
modules/linuxboot
modules/lvm2
modules/mbedtls
modules/msrtools
modules/musl-cross-make
modules/ncurses
modules/newt
modules/nkstorecli
modules/npth
modules/openssl
modules/pciutils
modules/pinentry
modules/pixman
modules/popt
modules/powerpc-utils
modules/purism-blobs
modules/qrencode
modules/slang
modules/tpm2-tools
modules/tpm2-tss
modules/tpmtotp
modules/u-root
modules/util-linux
modules/zlib
modules/zstd

[hughsie]

@tlaurion does this help? https://docs.google.com/spreadsheets/d/1gKEWLxdLubOfgS1cqqY2umEX0ohYEoEy-B1i59HNVqg/edit?usp=sharing

[tlaurion]

@tlaurion does this help? https://docs.google.com/spreadsheets/d/1gKEWLxdLubOfgS1cqqY2umEX0ohYEoEy-B1i59HNVqg/edit?usp=sharing

That is a gem! Thanks @hughsie ! Edited OP.

[tlaurion]

Really relevant presentation for Heads SBOM https://fosdem.org/2026/schedule/event/ZXJD8E-sboms_for_embedded_firmware_the_zephyr_rtos_case_study/

[tlaurion]

WiP

Heads SBOM — Project Plan

Background

The Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to provide a Software Bill of Materials. An SBOM is a machine-readable inventory identifying each software component in a product — its name, version, license, supplier, and cryptographic hash. Heads produces firmware ROM images and is subject to this regulation.

Two compliance deadlines apply. Phase 1, effective 2026-09-11, requires vulnerability reporting infrastructure: a PSIRT contact point, a 24-hour notification mechanism for actively exploited vulnerabilities, a 72-hour incident reporting channel to ENISA, and registration on the ENISA single reporting platform. Phase 2, effective 2027-12-11, requires the full SBOM with per-component metadata, license tracking, cryptographic hashes, manufacturer identification, and a minimum five-year support period.

Prior Work

Coreboot SBOM Infrastructure

Upstream coreboot has included SBOM support since April 2022 (commit 1d7a9debf2, Maximilian Brune, 9elements). The architecture processes per-component CoSWID JSON templates through a Go tool called goswid, which merges them into a single uSWID container and embeds it in CBFS, coreboot's filesystem in flash. CoSWID (Concise Software Identification Tags, RFC 9393) is a binary CBOR format with a 25-byte discoverable header. It was chosen over SPDX and CycloneDX for embedded firmware because it is binary-compact, has a free specification, and does not require a filesystem for discovery.

Each component is controlled by three Kconfig options: CONFIG_SBOM_<NAME> to enable the component, CONFIG_SBOM_<NAME>_GENERATE to automatically extract version information from the binary, and CONFIG_SBOM_<NAME>_PATH to specify a manually provided CoSWID file. The master toggle is CONFIG_SBOM.

Dasharo Extensions

Dasharo (3mdeb's coreboot distribution) extended the upstream infrastructure through 13 pull requests. The two foundational PRs are:

PR #859 (merged 2026-03-18, Filip Lewinski, 3mdeb): Added CoSWID templates and extraction rules for components not covered by upstream coreboot: Intel FSP (Firmware Support Package, S/M/T components), Intel ME (Management Engine), Intel IFD (Flash Descriptor), Intel and AMD microcode, AMD AGESA, AMD openSIL, EDK2 UEFI payload, EC firmware, vboot, iPXE, SINIT ACM, and BIOS ACM.

PR #938 (merged 2026-07-23, Filip Lewinski, 3mdeb): CRA compliance work. Achieved zero errors on sbom-tools validate --standard cra. Changes included: SHA-256 cryptographic hashes on all eight vendor-supplied components using Dasharo's goswid fork (upstream goswid has hash fields commented out, and python-uswid throws NotSupportedError on payload entries without hashes); SPDX license identifiers for open-source components (edk2: BSD-2-Clause-Patent, iPXE: GPL-2.0-only, vboot: BSD-3-Clause) and upstream license-file URLs for proprietary components (FSP, ME, microcode); a new SBOM_MANUFACTURER Kconfig defaulting to BIOS_VENDOR for CRA Art. 13(16) manufacturer identification; and VBIOS, GOP, and LAN ROM blob descriptors.

Additional PRs: #947 (approved, unmerged) unifies <date>_<hash> versioning for git-backed dependencies. #948 (merged 2026-07-30) generalizes the GOP template to support AMD drivers.

Blob Version Extraction

Dasharo's src/sbom/Makefile.mk (713 lines) applies component-specific extraction methods to blobs that lack source repositories and embedded version strings:

• Intel FSP: scans the firmware descriptor image for the ASCII magic FSPH, validates the surrounding FFS GUID against the FSP specification (GUID 912740be-2284-4734-b971-84b027353f0c), parses ImageRevision (4 bytes LE at offset 12) and ExtendedImageRevision (2 bytes LE at offset 76, when HeaderRevision >= 6). SKU derived from the directory path, product-family from the text before FspBinPkg.
• Intel ME: three-stage extraction. First, strings | grep ME for ASCII version strings. Second, NFTP partition manifest parsing — locate $MN2 magic, read four 16-bit LE fields at offset +8. Third, partition extraction using one of three tools depending on image layout: ifwitool for Apollo Lake TXE, cse_serger for ME version 12+ with BPDT, or cse_fpt for ME versions 11 and below. New Kconfig CSE_BPDT_VERSION added (1.6 for ME_SPEC < 15, 1.7 for ME_SPEC >= 15).
• Microcode: one CoSWID tag per binary file, UUIDv5 generated from filename via goswid generate-tag-id. Revision at offset 4, BCD date at offsets 8-11, CPUID at offset 12.
• Intel IFD: no embedded version. Git commit hash of the repository containing the IFD binary used as version proxy. Version string scraped from README.md beside the blob.
• EC firmware: strings | grep _VERSION=.
• ACM (SINIT/BIOS): BCD date at offset 0x14 of ACM header, extracted from the built ROM via cbfstool extract. ROM deliberately excluded as a make prerequisite to avoid circular dependency.

Validation Toolchain

Two complementary tools validate different aspects of the SBOM:

• python-uswid --validate validates CoSWID structural requirements (reg-id on every entity, TagCreator and SoftwareCreator entity roles, version scheme, compiler links, REDACTED strings, payload hashes). This is a downstream concern — LVFS/fwupd integration is out of scope for this plan.
• sbom-tools validate --standard cra: validates CRA regulatory requirements — supplier identification, license tracking, vendor hash carry-through, manufacturer identification, product identification, support period, and vulnerability disclosure channels. Cannot read uSWID; operates on CycloneDX or SPDX exports.

The validated export chain is: embedded uSWID → python-uswid CycloneDX 1.6 export → sbom-tools CRA validation. Python-uswid's SPDX export drops PURL and CPE fields and is therefore unsuitable for CRA validation; it serves as a publication artifact only.

Other Firmware SBOM Projects

The Linux kernel SBOM project (TNG/KernelSbom, Luis Augenstein, v1-v3 Jan 2026) generates three SPDX 3.0.1 JSON-LD documents per build via .cmd-file dependency reconstruction. After community review, the CONFIG_SBOM Kconfig option was removed in favor of a dedicated make sbom post-build target (LKML v3 resolution). The project is not yet in mainline as of August 2026.

Zephyr RTOS integrates SPDX-based SBOM generation into CMake via west spdx, producing app, zephyr, build, and modules-deps documents. Migration to SPDX 3.0 is in progress. NTIA compliance is validated via sbomqs.

Current State

Heads Coreboot Fork Audit

The Heads build uses seven git-fork coreboot trees and six release tarball versions, serving 68 active boards (one additional board, EOL_librem_l1um, uses a coreboot 4.11 tarball that predates SBOM infrastructure and is out of scope).

Audit of the git-fork trees as of 2026-08-02:

Fork	Current commit	Commit date	Has Dasharo #859?	Has Dasharo #938?
dasharo_nv4x	281a7fec	2026-03-26	Yes	No
dasharo_v56	6de027d1	2026-01-29	No	No
dasharo_msi_z790	a5a05f13	2025-11-29	No	No
dasharo_msi_z690	be7d58da	2025-06	No	No
25.09 (upstream)	07df0883	2025-09-26	No	No
purism	bea9947a	2024-10-18	No	No
mrchromebox	ddfe3855	2026-07-09	No	No

Dasharo fork talos_2 (fc47236e, 2018-era ppc64) is defined in modules/coreboot but doesn't have SBOM support.

One fork (nv4x, pinned 8 days after #859 merged) has the extended SBOM infrastructure. No production fork has the #938 CRA compliance layer or subsequent PRs #947 and #948.

goswid Submodule

All seven forks pin the upstream goswid submodule at commit 567a1c99 (2023-01-18) from review.coreboot.org/goswid. Upstream goswid has hash fields in pkg/uswid/uswid.go commented out. The --hash and --hash-alg flags required by PR #938 exist only in Dasharo's fork (github.com/Dasharo/goswid, commit a8a285be, branch trunk). Without these flags, python-uswid throws NotSupportedError: the hash value MUST be provided on payload entries lacking hashes.

Build Environment

Heads' Nix flake (flake.nix) does not include a Go toolchain, python-uswid, sbom-tools, or sbomqs. The modules/coreboot file contains no SBOM extraction or export rules. All 48 coreboot board configuration files have # CONFIG_SBOM is not set.

Despite the disabled configuration, the SBOM infrastructure physically exists in the checked-out git-fork trees: src/sbom/ directories with Kconfig, Makefile.mk, JSON templates, and the goswid submodule are present in all built trees. A stray coreboot 26.06 tree exists in the build directory (commit 5cbf8afc, 2026-06-18) from the heads-kano branch, confirming the infrastructure is in active use.

Implementation Plan

S0: Integrate Dasharo SBOM Patches into Coreboot Forks

Bump each Dasharo fork to a release tag dated 2026-08-01 or later, which includes PRs #859, #938, #947, and #948. For non-Dasharo forks (25.09 upstream, purism, mrchromebox), backport the patches or coordinate with fork maintainers. Switch the goswid submodule in every fork from upstream (567a1c99, 9elements) to Dasharo's fork (a8a285be). Verify each fork builds successfully with CONFIG_SBOM=y.

This is the prerequisite for all subsequent SBOM work. The nv4x fork is the closest to ready, requiring only a version bump from the current commit (8 days after #859) to a commit including #938 (merged 2026-07-23). The v56, msi_z790, and msi_z690 forks are pinned to pre-#859 commits and require larger jumps. The three non-Dasharo forks require backporting.

Estimated effort: 3-5 days. Dependencies: none.

S1: Add SBOM Tools to Nix Flake

Add go (>= 1.18), python3Packages.uswid (>= 0.6.0), sbom-tools (>= 0.2.0), and sbomqs to flake.nix. These are build-host tools; no initrd changes are required.

Estimated effort: 2-3 days. Dependencies: none.

S2: Enable SBOM on a Test Board

Enable CONFIG_SBOM=y on qemu-coreboot-fbwhiptail-tpm2 (uses coreboot 25.09 git fork). Verify sbom.uswid appears in CBFS. Extract via cbfstool, validate via python-uswid --validate, export to CycloneDX. This establishes a baseline for CRA validation.

Estimated effort: 2-3 days. Dependencies: S0, S1.

S3: Wire SBOM Artifact Extraction

Extend modules/coreboot to extract sbom.uswid from CBFS after build, export to CycloneDX 1.6 and SPDX 2.3 via python-uswid, and include artifacts in the build's hashes and sizes tracking.

Estimated effort: 1 day. Dependencies: S2.

S4: Define Module Metadata Schema

Design metadata variables for modules/<name> files. Required fields: _license (SPDX identifier), _supplier (Organization name), _product (required by python-uswid SPDX export). Recommended fields: _cpe, _purl, _homepage, _summary. Optional: _patch_description, _binary_paths. Provide modules/kexec as a reference implementation.

Estimated effort: 1 day. Dependencies: none.

S5: make sbom Post-Build Target

Create a dedicated make sbom target that runs after the full build completes. For each enabled module, reads metadata variables, computes SHA-256 hashes of output binaries, and generates a CoSWID JSON fragment. Fragments are collected into a single JSON array file and passed to coreboot via CONFIG_SBOM_PAYLOAD_PATH. Coreboot's existing goswid pipeline merges the fragments with its own component templates into the final uSWID container.

This requires no new coreboot patches. CONFIG_SBOM_PAYLOAD_PATH is an existing Kconfig string option added by Dasharo PR #859. goswid's FromJSON() parser handles JSON arrays of tags natively.

Estimated effort: 4-5 days. Dependencies: S3, S4.

S6: Populate Module Metadata

Populate SBOM metadata for all modules, working in priority tiers: Tier 1 (cryptographic and security modules), Tier 2 (system and initrd tools), Tier 3 (hardware tools), Tier 4 (remaining modules), Tier 5 (blobs). For each module, determine the SPDX license identifier from the upstream source, identify the supplier organization, look up CPE and PURL identifiers, count and document patches, and cross-reference with Hughsie's upstream SBOM spreadsheet. The spreadsheet indicates that mbedtls is the only Heads module with a merged upstream SBOM template.

Estimated effort: 8-10 days. Dependencies: S4, S5.

S7: CRA Sidecar and Structural Validation

Generate a CRA sidecar JSON file per board (camelCase, 17 fields, deny_unknown_fields enforced by sbom-tools). Ensure every CoSWID tag carries reg-id: linuxboot.org on every entity (python-uswid flags reverse-DNS as invalid), a SoftwareCreator entity role, a compiler link with colloquial-version, and a product field (required by SPDX export). Add metadata.timestamp to the CycloneDX export. Record the Nix flake.lock hash as build provenance.

Estimated effort: 3-4 days. Dependencies: S5, S6.

S8: CI Integration

Add a CI step after the board build that runs python-uswid --validate on the uSWID, exports to CycloneDX, runs sbom-tools validate --standard cra and --standard cra-phase1, and archives all artifacts. Fail on validator errors. The --as-of flag handles Phase 1 severity escalation (INFO before 2026-09-11, WARN after).

Estimated effort: 2-3 days. Dependencies: S7, S1.

S9: CRA Phase 1 Reporting Channels

Document the PSIRT contact, 24-hour early-warning channel, 72-hour incident reporting channel, and ENISA platform identifier. Determine whether Heads is classified as a "manufacturer" or "open-source steward" under CRA Art. 24. Due 2026-09-11.

Estimated effort: 1-2 days. Dependencies: none.

S10: Blob Handling Policy

Apply Dasharo PR #938 methodology to Heads blob modules (coreboot-blobs, purism-blobs): SHA-256 hash on every blob, supplier set to the silicon vendor, license set to the upstream license-file URL, version extracted from the binary or proxied by repository git commit. Document the policy.

Estimated effort: 2-3 days. Dependencies: S6.

S11: Board Rollout

Enable SBOM generation for all 68 git-fork coreboot boards. Validate each board in CI. The one EOL tarball board (librem_l1um, coreboot 4.11) is documented as out of scope.

Estimated effort: 5-7 days. Dependencies: S7, S6, S10.

S12: Documentation

Write doc/sbom.md covering the architecture, module metadata schema, blob handling policy, make sbom workflow, CI validation, and CRA compliance status.

Estimated effort: 1-2 days. Dependencies: S6, S7.

Dependencies

S0 blocks all SBOM work. S1, S4, and S9 can run in parallel. S2 depends on S0 and S1. S3 depends on S2. S5 depends on S3 and S4. S7 depends on S5 and S6. S8 depends on S7 and S1. S11 depends on S7, S6, and S10. S10 depends on S6. S12 depends on S6 and S7.

Total estimated effort: 30-45 days. Critical path: S0 → S2 → S3 → S5 → S7 → S8 → S11.

Acceptance Criteria

Gate	Tool	Target
CRA Phase 2 regulatory compliance	sbom-tools validate --standard cra	0 errors
CRA Phase 1 regulatory compliance	sbom-tools validate --standard cra-phase1	0 errors
LVFS/uSWID structural compliance	python-uswid --validate	0 problems — downstream concern, out of scope

Out of Scope

• Coreboot 4.11 tarball boards (1 board, EOL) — no SBOM infrastructure
• SPDX 3.0 Build profile — not supported by python-uswid; post-processing for downstream
• BusyBox applet enumeration — one component, applet inventory in summary field
• Upstream SBOM metadata — only mbedtls has it; all other modules generate locally
• LVFS/fwupd integration and python-uswid --validate — downstream responsibility

References

Regulation and Standards

• EU Cyber Resilience Act: Regulation (EU) 2024/2847 — https://eur-lex.europa.eu/eli/reg/2024/2847/oj
• CoSWID: RFC 9393 (IETF) — https://www.rfc-editor.org/rfc/rfc9393
• ENISA CRA implementation: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• OSFF firmware SBOM specification: https://sbomspec.osfw.foundation/
• CycloneDX specification: https://cyclonedx.org/
• SPDX specification: https://spdx.dev/
• CPE (Common Platform Enumeration): https://nvd.nist.gov/products/cpe
• PURL (Package URL): https://github.com/package-url/purl-spec
• CRA Art. 14 (Phase 1, reporting obligations) and Art. 13 + Annex I (Phase 2, full SBOM): sections of https://eur-lex.europa.eu/eli/reg/2024/2847/oj
• prEN 40000-1-3 (harmonised standard, expected H2 2026): https://standards.cencenelec.eu/
• CRA Art. 13(16) (manufacturer identification) and Art. 24 (open-source steward profile): sections of https://eur-lex.europa.eu/eli/reg/2024/2847/oj

Dasharo SBOM PRs

• PR Inject Heads version string into coreboot LOCALVERSION... #859: Extended SBOM infrastructure (merged 2026-03-18) — Extend SBOM Dasharo/coreboot#859
• PR coreboot: revert building coreboot against musl-cross-make. #938: CRA compliance — hashes, licenses, blob versioning (merged 2026-07-23) — src/sbom: push for further CRA compliance Dasharo/coreboot#938
• PR Makefile: prefetch crossgcc tarballs (ftpmirror.gnu.org failing downloads on coreboot builds) #947: Unified versioning convention (approved, unmerged) — SBOM further issue fixes Dasharo/coreboot#947
• PR oem-factory-reset: set default KEY_LENGTH to 3072 and change expectation management message to console #948: AMD GOP generalization (merged 2026-07-30) — SBOM b850 blobs Dasharo/coreboot#948
• PR (WIP) (KGPE-D16) Bump to Linux 5.4.69 #946: coreboot: revert building coreboot against musl-cross-make. #938 cherry-picked to dasharo-25.12 branch — SBOM iter2 25.12 Dasharo/coreboot#946
• PR coreboot: Pass $CPUS to coreboot make target unerroneously #941: coreboot: revert building coreboot against musl-cross-make. #938 core commits on novacustom_tgl_rel_v1.6.0 — Novacustom tgl v1.6.0 SBOM fixes Dasharo/coreboot#941
• Dasharo/goswid fork: https://github.com/Dasharo/goswid (commit a8a285be, branch trunk)
• dasharo-sdk#14: Go + extraction tools in SDK Docker image (merged 2026-03-10) — Dockerfile: add golang and utils for SBOM generation Dasharo/dasharo-sdk#14
• Dasharo issue Improve rebranding docs at https://osresearch.net/Distributions/#branding #1847: SBOM breaks multijob builds — Enabling SBOM in config breaks multijob builds Dasharo/dasharo-issues#1847
• Dasharo issue Consider switching to StageX to build Heads #1877: Component-by-component SBOM gap list (requirements document) — SBOM components missing Dasharo/dasharo-issues#1877
• Dasharo issue t430-hotp-maximized - Won't build on Ubuntu 24.04.1 LTS #1878: SBOM hashes missing, LVFS detection broken — SBOM hashes missing, LVFS uswid does not detect SBOM Dasharo/dasharo-issues#1878

Coreboot

• Upstream coreboot SBOM: commit 1d7a9debf2 (Maximilian Brune, 9elements, 2022-04-14) — https://review.coreboot.org/c/coreboot/+/63639
• Upstream goswid: https://github.com/9elements/goswid (commit 567a1c99, 2023-01-18)
• Upstream coreboot 25.09: commit 07df0883 (head of 25.09 branch) — coreboot/coreboot@07df0883

Linux Kernel SBOM

• TNG/KernelSbom: https://github.com/TNG/KernelSbom (Luis Augenstein, v3 Jan 2026)
• LKML thread: https://lore.kernel.org/lkml/20260126193304.320916-1-luis.augenstein@tngtech.com/

Zephyr RTOS

• FOSDEM 2026 talk, Benjamin Cabé: https://fosdem.org/2026/schedule/event/ZXJD8E-sboms_for_embedded_firmware_the_zephyr_rtos_case_study/
• FOSDEM 2023 talk, Joshua Watt: https://archive.fosdem.org/2023/schedule/event/sbom_openembedded_yocto/
• FOSDEM 2026 talk, Marta Rybczynska: https://fosdem.org/2026/schedule/event/7YG9H7-embedded-product-with-three-sboms/
• FOSDEM 2026 talk, Maximilian Huber: https://fosdem.org/2026/schedule/event/938CKB-how_to_create_the_sbom_for_the_linux_kernel/
• FOSDEM 2026 talk, Viktor Petersson: https://fosdem.org/2026/schedule/event/UYTGWA-sbom-generation/
• OSFC 2025 talk, Christian Walter: https://vimeo.com/1132581140

Tools

• python-uswid: https://github.com/hughsie/python-uswid (version >= 0.6.0)
• sbom-tools: https://github.com/sbom-tool/sbom-tools (version >= 0.2.0)
• sbomqs: https://github.com/interlynk-io/sbomqs

Heads

• Issue Introduce Heads' SBOM (OSFF grant) #2135 (OSFF grant): Introduce Heads' SBOM (OSFF grant) #2135
• Heads repository: https://github.com/linuxboot/heads
  • modules/coreboot: https://github.com/linuxboot/heads/blob/master/modules/coreboot
  • Makefile: https://github.com/linuxboot/heads/blob/master/Makefile
  • flake.nix: https://github.com/linuxboot/heads/blob/master/flake.nix

Other

• MbedTLS upstream SBOM: Add a SBOM file in CycloneDX format Mbed-TLS/mbedtls#9777 (merged 2025-01-06)
• hughsie's "Firmware SBOMs for open source projects" (2024-11-14): https://blogs.gnome.org/hughsie/2024/11/14/firmware-sboms-for-open-source-projects/
• hughsie's SBOM compliance spreadsheet: https://docs.google.com/spreadsheets/d/1gKEWLxdLubOfgS1cqqY2umEX0ohYEoEy-B1i59HNVqg/
• Nix SBOM: sbomnix — https://github.com/tiiuae/sbomnix

[hughsie]

goswid Submodule

I would heavily suggest that you don't use goswid for this; CycloneDX and SPDX have won the standards war and everything else is irrelevant at this point.

[macpijan]

Another comment from @hughsie for reference, suggesting that "the proper" solution for corebot going forward is to natively support CycloneDX format: fwupd/fwupd#9980 (comment)

What we can do rigth now, is to extract existing SWID SBoM from coreboot firmware binary, and convert to one of the CycloneDX or SPDX externally.

OSFF firmware SBOM specification: https://sbomspec.osfw.foundation/

I think this one promoted approach like described above.

[tlaurion]

linux sbom landed under linux 7.2; this means a version bump.

As seen at https://fosdem.org/2026/schedule/event/938CKB-how_to_create_the_sbom_for_the_linux_kernel/

[tlaurion]

A lot of words of wisdom in embedded sbom: expect worse to happen.

https://fosdem.org/2026/schedule/event/7YG9H7-embedded-product-with-three-sboms/