HBOM generation: collecting hardware and firmware inventory

An HBOM is assembled, not scanned. Good generation combines what the supplier declares with what the device reports, and records which is which.

Four sources of truth

Step 0: decide scope and depth

Decide which estates come first and how deep each HBOM should go. For most organisations, replaceable modules and all firmware-bearing components are the right depth for operational HBOMs; component-level detail with locations is reserved for critical products, where the CISA taxonomy’s provenance fields matter most.

Step 1: start from the supplier declaration

Where suppliers provide HBOMs, they are the most reliable source for what sits below the management interface: sub-assemblies, component manufacturers, manufacturing and assembly locations, and date codes. The CISA framework recommends a parent-child structure in which a product breaks down into assemblies and components, each linked by part identifiers ^[1]. Ask for it in procurement (see HBOM procurement requirements).

Step 2: collect in band

On hosts you control, lshw reports memory configuration, firmware version, mainboard and CPU details ^[2], dmidecode reads SMBIOS for manufacturer, model, serial and BIOS version ^[4], and fwupdmgr get-devices lists devices fwupd can see, with their firmware ^[3]. Record the tool and version with each observation so that later reviewers know how a value was obtained.

Step 3: collect out of band

For servers, Redfish is the most consistent route. Its update service exposes a FirmwareInventory collection for platform firmware that “does not execute within a host operating system” and a SoftwareInventory collection for host-executed components such as drivers; entries include version, manufacturer, release date and links to related hardware resources ^[5]. A request to /redfish/v1/UpdateService/FirmwareInventory on a BMC returns the collection without an agent on the host.

Step 4: normalise identifiers

Merging only works if identifiers agree. Normalise manufacturer names, keep both supplier and manufacturer part numbers (the CISA taxonomy distinguishes them ^[1]), record serial numbers for instances, and assign CPE names where they exist; CPE 2.3 distinguishes hardware from operating systems and applications through its part attribute ^[6]. A consistent unique identifier per component also satisfies one of CERT-In’s minimum elements ^[7].

Step 5: express it in CycloneDX or SPDX

In CycloneDX, represent the physical part as a device component and its firmware as a firmware component; the specification says “a hardware device containing firmware SHOULD include a component for the physical hardware itself” ^[8]. Nest sub-assemblies as child components and use dependencies for relationships. Attach hashes to firmware images where available. The CycloneDX for hardware BOMs article gives an example.

Step 6: mark provenance of each value

Keep a property on each field or component that says whether it was declared by the supplier, observed in band or observed out of band. When the sources disagree, for example a different firmware version or an unexpected module, that disagreement is a finding, not noise. It feeds directly into HBOM validation.

Step 7: regenerate on change

Regenerate the operational HBOM after firmware updates, part replacements and RMAs, and on a schedule. Each run becomes a new version that can be compared with the last, which is the basis of HBOM management.

How IntelliXBOM helps

IntelliXBOM generates and ingests HBOMs in CycloneDX and SPDX, merges supplier and collected data, and keeps each run as a version with component-level diffs. It then correlates devices and firmware with vulnerabilities, EOL dates and business services.