Firmware BOMs: bridging hardware and software

Firmware is software, but it ships inside hardware, updates through different channels and runs before any operating system control. A firmware BOM records it on both sides of that line.

Why firmware needs its own treatment

Firmware provides low-level control over hardware. CycloneDX defines it as “a special type of software that provides low-level control over a device’s hardware” ^[1], and SPDX 3.0 uses almost identical wording for its firmware purpose ^[2]. It differs from ordinary software in three ways that matter for inventory. It runs before or beneath the operating system, so OS security tools may not see it. It updates through vendor-specific channels, often out of band. And it anchors trust: if firmware is compromised, controls above it can be switched off. Microsoft’s write-up of BlackLotus describes a UEFI bootkit that used CVE-2022-21894 to bypass Secure Boot and could interfere with BitLocker and Defender ^[3]; NSA published a mitigation guide for it in June 2023 ^[4].

Two layers of a firmware BOM

Most organisations can collect the first layer themselves. The second must usually come from the producer.

Collecting firmware identity

DMTF Redfish separates a FirmwareInventory collection, for platform firmware that “does not execute within a host operating system”, from a SoftwareInventory collection for host-executed components such as drivers ^[5]. Entries include version, manufacturer, release date and links to related hardware. On Linux, fwupd reports detected devices and their firmware, and the LVFS distributes vendor firmware updates ^[6][7].

Carrying firmware contents

uSWID is “a tiny tool for embedding CoSWID tags in EFI binaries”; it supports PE, FIT and other firmware images and converts between coSWID, CycloneDX and SPDX ^[8]. Embedding SBOM metadata in the image means the contents travel with the firmware, and a consumer can extract them without relying on a separate document. Where suppliers provide a separate firmware SBOM instead, link it to the firmware component in the HBOM.

Modelling it in CycloneDX

CycloneDX states that a hardware device containing firmware should include a component for the physical hardware itself ^[1]. A practical pattern: a device component for the board or controller, a nested firmware component with version and hashes, and, where available, the firmware’s own software components beneath it or in a linked BOM. See CycloneDX for hardware BOMs.

Firmware on network and storage devices

Servers are only part of the picture. Switches, routers, storage arrays, drives and network adapters all carry firmware that is updated through their own tools. Record each image against the device it runs on, with its provider, so that a single advisory can be matched across all of them.

Firmware security guidance

NIST SP 800-147 (April 2011) gives BIOS protection guidelines against unauthorised modification of system firmware ^[9]. SP 800-193 (May 2018) generalises this into platform firmware resiliency: protect, detect and recover ^[10]. A firmware BOM is the reference point for detection: you can only notice an unauthorised change if you know what should be there.

Signing and post-quantum readiness

Firmware is usually verified by signature at boot or update. NSA’s CNSA 2.0 asks for quantum-resistant software and firmware signing to be supported and preferred by 2025 and used exclusively by 2030, with LMS and XMSS approved for the purpose ^[11][12]. Recording the signing algorithm and key for each firmware image, and cross-referencing it with a CBOM, shows which devices can move and which will need replacement. The CNSA 2.0 timeline sets out the dates.

How IntelliXBOM helps

IntelliXBOM links firmware components in the HBOM to their SBOMs and cryptographic assets in the CBOM, in CycloneDX or SPDX. It correlates firmware versions with vulnerabilities, known-exploited lists and EOL data, and keeps version history so firmware changes are visible as diffs.