How to validate an HBOM: a step-by-step procedure

A repeatable procedure for checking a supplier or operational HBOM, from schema validation to reconciliation with the devices it describes.

Before you start

You need the HBOM under review, a field policy (for example the CERT-In Table 11 elements ^[1]), access to at least one representative device, and a place to record results. For the concepts behind each step, see HBOM validation.

Step 1: validate the schema

Run the CycloneDX CLI against the file, specifying the format and version the supplier claims:

cyclonedx validate --input-file hbom.json --input-format json --input-version v1_6 --fail-on-errors

The --fail-on-errors flag returns a non-zero exit code on validation errors, so the check can gate an intake pipeline ^[2]. For SPDX files, use an SPDX validator for the declared version. Reject files that fail; nothing else is meaningful until this passes.

Step 2: check component types and structure

Confirm that physical parts use the device type and firmware uses firmware, and that each device with firmware includes a component for the hardware itself, as the CycloneDX specification advises ^[3]. Check that nesting reaches the depth agreed in the contract.

Step 3: check field completeness

For each component, test for every element in your policy: name, version, supplier, licence (on firmware), dependencies, vulnerabilities, patch status, release date, EOL date, criticality, hashes (on firmware) and unique identifier ^[1]. Output a per-component gap list. A simple script over the JSON is enough to start; what matters is that gaps are reported individually and tracked to closure.

Step 4: reconcile with the device

Collect observations from a representative unit and compare:

• Out of band: query /redfish/v1/UpdateService/FirmwareInventory on the BMC; entries include version and manufacturer for platform firmware ^[4].
• Firmware on Linux: run fwupdmgr get-devices to list devices and firmware that fwupd detects ^[5].
• Hardware configuration: run lshw -xml for memory, mainboard, CPU and firmware details ^[6].
• SMBIOS data: run dmidecode -t system and dmidecode -t bios for manufacturer, model, serial and BIOS version ^[7].

Classify each difference as expected (documented update), benign (naming) or unexplained. Remember that dmidecode reports what the BIOS declares and is not proof on its own ^[7].

Step 5: verify firmware integrity

Compare firmware hashes in the HBOM with the vendor’s published values and with images in your repository. Where the platform supports it, confirm signature verification at update. For critical platforms, run CHIPSEC in a lab to assess firmware and platform configuration; its maintainers note it is intended for security testing ^[8]. This supports the detection principle of NIST SP 800-193 ^[9].

Step 6: check identifiers and vulnerabilities

Confirm that unique identifiers resolve: CPE names should use the hardware part value where appropriate ^[10], and part numbers should match supplier catalogues. Then run the HBOM through vulnerability correlation against vendor advisories and CISA’s KEV catalogue ^[11], and confirm the supplier’s declared vulnerabilities and patch status agree.

Step 7: check provenance declarations

For critical components, compare declared manufacturers and locations with your approved-source and restricted-entity lists. Where contracts require authorised-source purchasing, check the supplier’s declarations against it.

Step 8: record and diff

Store the validated HBOM as a dated version with the validation report. On the next delivery or collection, compare with cyclonedx diff hbom-old.json hbom-new.json --component-versions to list added, removed or modified component versions ^[2]. Unexplained changes go back to step 4.

Checklist

How IntelliXBOM helps

IntelliXBOM automates the document-level steps: it validates CycloneDX and SPDX HBOMs against required-field policies, reports gaps per component, keeps each version with diffs and correlates components with vulnerabilities and known-exploited lists. Results are stored as timestamped evidence mapped to framework controls.