Hardware and Firmware Inventory: HBOMs and Firmware SBOMs, Chips to Boards

A hardware inventory that is useful for security records two things for every device: the physical parts it is built from, which is what a hardware bill of materials (HBOM) describes, and the firmware running on each of those parts, which belongs in a software bill of materials (SBOM). CISA's HBOM framework covers the first, CycloneDX and SPDX can carry both, and fwupd, vendor tools and Redfish let you collect firmware versions from real machines.

This post is the capstone of our hardware series. The earlier posts traced how memory, buses, motherboards and network cards evolved. Here we turn that history into one inventory model: which parts carry their own firmware, what the standards define, how to collect the data with commands you can run today, and what procurement should ask suppliers. Dates are checked against primary documents.

Key takeaways

• CISA's HBOM framework (25 September 2023) is a vocabulary, not a file format. It defines use cases, data field categories, a parent and child nesting model and a field taxonomy, with mappings to CycloneDX and SPDX where they exist. It explicitly leaves SBOM content and firmware provenance out of scope.
• CycloneDX models hardware directly. It has a device component type for chips and boards, a firmware type for the code that controls them, and guidance that a device containing firmware should be listed as two components. A cdx:device property namespace adds serial numbers, board locations, lot numbers and MAC addresses.
• SPDX 3.0.1 has no hardware profile yet. It can label a package with the purpose device, firmware or deviceDriver, and a hardware profile is being worked on in the SPDX model repository, but it is not part of the released specification.
• Almost every component in a modern machine runs its own firmware. System firmware, the CPU microcode, the management or security processor, the BMC, the TPM, every NVMe drive, every NIC, many USB and Thunderbolt controllers, and often fingerprint readers, touchpads and display chips.
• Collecting versions is easy; knowing contents is not. fwupdmgr, dmidecode, nvme, ethtool, PowerShell and Redfish give you versions. Which libraries sit inside a firmware image still depends on a vendor SBOM.
• NIST SP 800-161 Rev 1 treats hardware and firmware as part of the supply chain. It asks for component inventories that include firmware version, provenance records, anti-counterfeit controls and SBOMs for software, and it has been updated (Update 1, 1 November 2024).
• The SSDF is about software, but "software" includes code built into hardware. Its provenance practice (PS.3.2) applies to firmware producers.
• The test is the reverse lookup. When an advisory names a controller and firmware version, you should list affected machines in minutes.

Timeline: how hardware and firmware inventory got standards

What does CISA's HBOM framework define?

The HBOM framework came out of the ICT Supply Chain Risk Management Task Force, a public and private body co-chaired by CISA. Its HBOM working group wrote the framework so that vendors and buyers could exchange hardware component information in a consistent, repeatable way. CISA's publication page dates it 25 September 2023, and the PDF says "Publication: September 2023".

It defines four things.

Use cases. Three categories: compliance (government, industry or customer, and internal quality rules), security (untrusted, compromised or counterfeit products and components, assessed by geography and entity or by product and component) and availability (world events and supply concentration). Each sub-category maps to the fields it needs, so a buyer checking for single source suppliers needs different data from one checking for counterfeits.

Data field categories. HBOM header information (author, dates, product), entity name (OEM, contract manufacturer, assembly and test supplier, component manufacturer), entity location, finished good product details, component part information (type, category, part number, description), component part details (version, technical specifications) and production details (percentage sourced from a supplier, lead times, quantity, technology node).

A nesting model. The framework describes a hierarchical bill of materials. A finished good contains assemblies and kits, which contain components and semiconductors, and each assembly that can be broken down gets its own HBOM, joined to its parent by part level information. For semiconductors it recommends recording the supplier and the fab or foundry as separate data points, with assembly and test details and the process node where needed.

A field taxonomy. Appendix C names each field (for example COMP_MANUFACTURER_PN, COMP_TYPE, COMP_VERSION, COMP_HASH) and, where possible, gives the equivalent CycloneDX and SPDX field. Many fields have no equivalent, and the framework says conversion tooling should then use user defined fields and agree their meaning with the requester.

What it leaves out matters as much. SBOM information is out of scope, and while it records basic firmware information such as the provider and a version string, it "stops short" of a framework for firmware provenance. Appendix D admits the hardest practical problem, part and entity resolution: one part can carry several identifiers, and one generic name can cover many parts. Its own example is a 64 GB DDR4 module name that maps to 21 part numbers.

Read it as a shared dictionary for procurement, not a schema to validate files against. Our post on HBOM vs SBOM covers the conceptual split in more depth.

How do CycloneDX and SPDX represent hardware and firmware?

CycloneDX

CycloneDX has treated hardware as a first class component since well before the CISA framework, and the 1.6 and 1.7 schemas carry the same guidance. The relevant component types are:

• device: "A hardware device such as a processor or chip-set."
• firmware: software that provides low level control over a device's hardware.
• device-driver: software that operates or controls a particular type of device.
• operating-system and platform, for the OS and runtime environment.

The schema adds a rule that shapes the whole inventory: a hardware device containing firmware should be recorded as one component for the physical hardware and another of type firmware (or operating-system, if that is what runs on it). In other words, a NIC is two rows, not one. That separation is what lets you update the firmware row without pretending the card changed.

CycloneDX also maintains an official property taxonomy for devices. The cdx:device namespace includes quantity, function (Bluetooth, network, storage, microprocessor and so on), location on the board, deviceType (surface mount or through hole), serialNumber, sku, lotNumber, prodTimestamp and macAddress. There are further namespaces for links to engineering and manufacturing BOMs, radio certifications per country and authority, and GS1 identifiers such as GTINs.

Our post on CycloneDX component types for firmware and devices walks through each type with examples.

SPDX

SPDX 3.0 (April 2024) and 3.0.1 (December 2024) reorganised the specification into profiles. The released profiles are Core, Software, Security, Licensing (simple and expanded), Dataset, AI, Build, Lite and Extension. There is no hardware profile in the released specification. The SPDX 3 model repository has a profile-hardware branch, which signals that work is under way, but you cannot rely on it yet.

What SPDX 3.0.1 does have is the SoftwarePurpose vocabulary. A package can be marked device ("a chipset, processor, or electronic board"), firmware ("provides low level control over a device's hardware"), deviceDriver, diskImage or filesystemImage, among others. That is enough to say "this element is firmware" or even "this element is a board", but not enough to carry the CISA fields such as fab location, assembly and test supplier or technology node without extensions.

Which format to pick

For one document that holds hardware fields and that vulnerability tools can read, CycloneDX is the practical choice today. If suppliers already deliver SPDX, keep it for firmware SBOMs and hold hardware fields elsewhere. The CISA framework tells you which fields to ask for either way.

Which parts of a modern server or laptop run their own firmware?

More than most asset systems record. The table below is the hardware side of this series in one place. "Update channel" is how the firmware usually gets updated; vendors vary, so treat it as a starting point.

The Firmware Embedded SBOM Specification, published by the Open Source Firmware Foundation, makes the same point from the vendor side. It notes that consumer laptops ship many firmware blobs for parts such as fingerprint readers, SD card readers, touchpads, PCI retimers and Thunderbolt controllers, and that some of these have no channel to the system firmware at all. Each one is code from a supplier, often several suppliers deep.

So "is this laptop patched" has a dozen answers: a fully patched OS can still run old drive firmware and a BMC with an outdated TLS library. That is why the firmware supply chain security guide and our post on the BMC firmware supply chain treat each of these as its own supplier relationship.

How do you collect firmware versions in practice?

Three sources cover most fleets: fwupd on Linux, vendor and OS tools on any platform, and Redfish on servers. Each is described below; the step by step section later puts them together.

fwupd and the LVFS

fwupd is a Linux daemon that lets session software update device firmware on the local machine. Its documentation says it is designed for desktops but usable on phones, tablets and servers. The Linux Vendor Firmware Service (LVFS) is the portal where hardware vendors upload firmware, packaged as a cabinet archive with metadata. According to the LVFS, all major Linux distributions use it to provide metadata to clients such as fwupdmgr and GNOME Software, and hosting is free for vendors.

For inventory, the useful fwupdmgr actions are get-devices (every device fwupd can see, with versions), get-releases (all installable versions for a device), get-updates, get-history and security (the Host Security ID attributes). The man page notes that adding the JSON output option is the way to parse results in scripts. For air gapped fleets, the LVFS documents offline options: deploying firmware in an immutable image, mirroring public firmware and exporting a shared directory.

fwupd only reports devices that have a plugin. A drive, NIC or dock whose vendor does not ship firmware through the LVFS may be invisible to it, which is why you still need the next two sources.

Vendor and OS tools

Every OS exposes some firmware versions through standard interfaces: SMBIOS for the board, system firmware and memory modules; the NVMe Identify Controller data and firmware log page for drives; ethtool -i for NIC firmware on Linux; PCI and USB enumeration for the vendor and device IDs that advisories match on; and Get-Tpm or /sys/class/tpm for the TPM. In nvme-cli 3.0 and later the firmware log command is nvme log fw, with the older fw-log name kept as a deprecated alias. Vendor tools fill the remaining gaps for drives, NICs, RAID controllers and docks. Record which tool produced each value, because two tools can report the same firmware with different version strings.

Redfish on servers

Redfish is DMTF's REST API for server management, served by the BMC. Its SoftwareInventory schema describes "an inventory of software components" and lists BIOS, BMC firmware, firmware for other devices, system drivers and provider software as examples. Each entry can carry Version, SoftwareId, Manufacturer, ReleaseDate, LowestSupportedVersion, Updateable, WriteProtected and AdditionalVersions, which break out bootloader, kernel, microcode, OS distribution and factory configuration versions. Entries can also hold a Measurement defined by SPDM, so a BMC can report a firmware hash obtained from the device itself.

Redfish also exposes hardware inventory: memory modules under the system's Memory collection (manufacturer, part number, serial number, capacity), drives under Storage (recent schema versions recommend a FirmwareVersion property, while older implementations report firmware in Revision), and network adapters with a FirmwarePackageVersion per controller. On a fleet of servers, Redfish is the closest thing to an HBOM and firmware SBOM you can pull from the machine itself. Our motherboard post covers the shift from IPMI to Redfish in more detail.

SPDM: getting the answer from the device, not the host

The Security Protocol and Data Model (DMTF DSP0274) defines messages between two devices for "authentication of hardware identities and firmware measurements". Version 1.3.0 is dated 28 June 2023. It lets a BMC or host ask a NIC, drive or GPU to prove which device it is and report signed firmware measurements, instead of trusting a driver's version string. Support varies, so record SPDM support as its own field. The bus evolution post covers SPDM alongside PCIe IDE and TDISP.

What belongs in an HBOM vs an SBOM?

The simplest rule: if you can hold it, it goes in the HBOM. If it can be replaced without touching a screwdriver, it goes in an SBOM. Firmware sits exactly on the line, which is why CycloneDX says to record it as a separate component linked to the device.

In practice, HBOM fields live in an asset system because they change only with hardware, and firmware SBOMs live in an SBOM repository because they change with every update. The hardware and software in one bill of materials post shows how device makers combine the two into a single CycloneDX file when they need to ship one.

How do you handle vendor supplied firmware with no SBOM?

This is the normal case today. In order of preference:

1. Ask for it, in writing, with a format. Name CycloneDX or SPDX, ask for firmware SBOMs per release, and ask whether the vendor follows the Firmware Embedded SBOM Specification. That specification asks firmware and component vendors to embed SBOM metadata in the firmware itself using the coSWID format with CBOR encoding, chosen because it is small and can act as a superset of SPDX and CycloneDX. Precompiled UEFI binaries should carry it in a .sbom section covered by their Authenticode signature, and OEMs should also publish an SPDX or CycloneDX export on the public device page. If your vendor does this, the SBOM travels with the firmware and cannot be stripped by an intermediary who does not care about it.
2. Use what the update channel already publishes. LVFS metadata lists firmware versions, release notes and device GUIDs. Vendor security advisories often list affected firmware versions even when no SBOM exists. Store both against the device record.
3. Record the version and the gap. A firmware row with a version and "SBOM: not supplied" is still useful. It lets you answer "which machines run version X" when an advisory lands, and it lets procurement see which suppliers are behind.
4. Treat binary analysis as an estimate. Analysing update packages can suggest what is inside, but it does not replace a vendor SBOM, and your license may restrict it.
5. Push accountability back into contracts. NIST SP 800-161 Rev 1 says provenance should be documented for systems, components and associated data, and that SBOMs complement but do not replace vulnerability management and vendor risk assessments. That language belongs in your supplier requirements.

What should procurement ask suppliers?

These questions turn the standards into a purchase checklist for servers, laptops, network gear and embedded devices.

Ask before the purchase; answers are much harder to get after it. Our post on NIST CSF 2.0 ID.AM-01 hardware inventory maps the same idea to the CSF.

How do you link a hardware advisory to affected fleet devices?

Hardware advisories usually name one of three things: a product model (a server or laptop), a component (a NIC controller, a drive model, a BMC SoC) or a firmware component inside them (a library in the BMC image, a module in the UEFI code). Each needs a different join.

1. Normalise identifiers. Store PCI vendor and device IDs, USB IDs, NVMe model numbers, SMBIOS product names and CPE or purl where the vendor publishes them. The CISA framework warns that the same part can carry several names; IDs are more stable than marketing names.
2. Join on component and version range. An advisory that says "controller X, firmware before 2.4" becomes a query on the firmware rows linked to devices of type X. This is why the separate firmware component matters.
3. Join on SBOM contents for embedded software. If a BMC image ships an affected TLS library and the vendor supplied an SBOM, the match is on the library and version inside that SBOM. Without the SBOM, you depend on the vendor's advisory listing its own affected firmware versions.
4. Apply VEX. Many firmware advisories are "affected component present, not exploitable in this configuration". Vendor VEX or CSAF statements let you close those without a site visit.
5. Produce a work list: machine, location, current and target firmware, update channel.

This is the same workflow as using SBOMs to find affected products fast, with hardware identifiers added to the join.

What do NIST SP 800-161 and the SSDF say about hardware?

NIST SP 800-161 Rev 1

SP 800-161 Rev 1 (5 May 2022, updated by errata on 1 November 2024) is NIST's cybersecurity supply chain risk management guide. Its abstract names the risks in hardware terms: products that may contain malicious functionality, are counterfeit, or are vulnerable because of poor manufacturing and development practices. The parts most relevant to inventory are:

• System component inventory (CM-8). The supplemental guidance covers automated location tracking, assigning components to systems so critical components can be tracked, and SBOMs for open source projects. Its C-SCRM plan template asks for hardware components with model, serial number, "component revision number (e.g., firmware version)", physical location down to the rack, and vendor names.
• Provenance (SR-4). Provenance should be documented for systems, components and associated data throughout the life cycle. SBOMs are recommended for purchased, open source and in-house software, should satisfy the minimum elements, and should be digitally signed. The guidance warns that SBOMs are complementary, not a substitute for vulnerability management or vendor risk assessments.
• Component authenticity (SR-11). Anti-counterfeit policies and procedures, training, configuration control for component service and repair, and anti-counterfeit scanning for critical components at a minimum.
• Integrity. Controls cover automatic firmware updates and code authentication with digital signatures.

NIST SP 800-193

SP 800-193 (May 2018) covers platform firmware resiliency: protecting firmware against unauthorized changes, detecting changes that happen anyway, and recovering rapidly and securely. NIST describes the platform as "a collection of fundamental hardware and firmware components needed to boot and operate a system". It is aimed at OEMs and component suppliers, which makes it a good source of procurement questions. See NIST SP 800-193 protect, detect, recover explained and hardware root of trust for device makers.

The SSDF

The SSDF (SP 800-218, version 1.1, February 2022) is a set of secure software development practices. It does not cover hardware manufacturing, but its introduction defines the software development life cycle as covering "software (including code built into hardware)". So firmware producers are inside its scope. The practices that matter most here:

• PS.3.2: collect, safeguard, maintain and share provenance data for all components of each software release, for example in an SBOM, and update it every time a component changes.
• PW.4.1 and PW.4.4: acquire well secured third party components and keep verifying them through their life cycle, including checking for publicly known vulnerabilities that vendors have not fixed.

NIST published an initial public draft of SSDF Rev 1 on 17 December 2025; its comment period closed on 30 January 2026. Until it is final, version 1.1 is the reference.

Where does each hardware series post's history show up as an inventory field?

Each post in this series ended with "inventory this". Here is what each one contributes to the record, so the history becomes a schema.

Step by step: build a hardware and firmware inventory for one machine

These steps are read only. Nothing below updates firmware or writes to a device. If you later run fwupdmgr update or a vendor flashing tool, do it with a recovery plan: mains power, your disk encryption recovery key, and on servers a BMC console.

1. Board, system firmware and memory (Linux)

# System, board and firmware identity from SMBIOS
sudo dmidecode -t system -t baseboard -t bios | grep -E 'Manufacturer|Product Name|Version|Serial Number|Release Date'

# Memory modules: one block per populated slot
sudo dmidecode -t memory | grep -E 'Locator:|Size:|Type:|Speed:|Manufacturer:|Part Number:|Serial Number:' | grep -v 'No Module'

# CPU model and microcode revision
grep -m1 -E 'model name' /proc/cpuinfo; grep -m1 microcode /proc/cpuinfo

2. Storage, network, PCI and USB (Linux)

# NVMe drives: model (mn), serial (sn) and firmware revision (fr)
sudo nvme list
sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn|fr) '

# Firmware slots on the drive (nvme-cli 3.0 and later; older versions use: nvme fw-log)
sudo nvme log fw /dev/nvme0

# NIC driver and firmware version (replace eth0 with your interface)
ethtool -i eth0 | grep -E 'driver|version|firmware-version|bus-info'

# Stable vendor and device IDs for every PCI and USB device
lspci -nn
lsusb

# TPM major version, where the kernel exposes it
cat /sys/class/tpm/tpm0/tpm_version_major 2>/dev/null

3. Ask fwupd for everything it can see (Linux)

# Every device with a fwupd plugin, as JSON for parsing
fwupdmgr get-devices --json | jq '.Devices[] | {Name, Vendor, Version, Plugin}'

# Platform security attributes (Host Security ID)
fwupdmgr security

# Firmware update history recorded by fwupd
fwupdmgr get-history

Compare the fwupd list with step 2. Anything in lspci or nvme list that fwupd does not report needs a vendor tool for its firmware version.

4. The same facts on Windows (PowerShell, elevated)

# System firmware
Get-CimInstance Win32_BIOS | Select-Object Manufacturer, SMBIOSBIOSVersion, ReleaseDate

# Board
Get-CimInstance Win32_BaseBoard | Select-Object Manufacturer, Product, Version, SerialNumber

# Memory modules
Get-CimInstance Win32_PhysicalMemory | Select-Object BankLabel, Manufacturer, PartNumber, SerialNumber, Capacity, Speed

# Drives with firmware version
Get-PhysicalDisk | Select-Object FriendlyName, SerialNumber, FirmwareVersion, MediaType

# TPM presence and firmware
Get-Tpm | Select-Object TpmPresent, TpmReady, ManufacturerIdTxt, ManufacturerVersion

# Network adapters (firmware usually needs the vendor tool)
Get-NetAdapter | Select-Object Name, InterfaceDescription, DriverVersion, MacAddress

5. Pull inventory from a BMC over Redfish (servers)

# Use a read only account on the management network, never across the internet
BMC=https://bmc.example.internal

# Firmware and software components the BMC knows about
curl -s -u "$BMC_USER" "$BMC/redfish/v1/UpdateService/FirmwareInventory" | jq -r '.Members[]."@odata.id"'

# Fetch each entry for name, version, release date and updateability
curl -s -u "$BMC_USER" "$BMC/redfish/v1/UpdateService/FirmwareInventory/BMC" \
  | jq '{Name, Version, ReleaseDate, Updateable, Manufacturer}'

# Memory modules on the first system
curl -s -u "$BMC_USER" "$BMC/redfish/v1/Systems" | jq -r '.Members[0]."@odata.id"'
# then: GET <system>/Memory and each member for Manufacturer, PartNumber, SerialNumber, CapacityMiB

Member IDs vary by vendor, so walk the collections rather than hard coding paths.

6. Write it as a CycloneDX HBOM with linked firmware

The fragment below shows one NIC recorded the way CycloneDX recommends: a device component with hardware properties and a nested firmware component. Values are placeholders.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "component": {
      "type": "device",
      "bom-ref": "server-rack12-u07",
      "name": "Example 2U server",
      "manufacturer": { "name": "Example OEM" },
      "version": "board-rev-B"
    }
  },
  "components": [
    {
      "type": "device",
      "bom-ref": "nic-slot3",
      "name": "Example 25GbE controller",
      "manufacturer": { "name": "Example NIC maker" },
      "properties": [
        { "name": "cdx:device:function", "value": "network" },
        { "name": "cdx:device:location", "value": "PCIe slot 3" },
        { "name": "cdx:device:serialNumber", "value": "SN-PLACEHOLDER" },
        { "name": "cdx:device:macAddress", "value": "00:00:5e:00:53:01" }
      ],
      "components": [
        {
          "type": "firmware",
          "bom-ref": "nic-slot3-fw",
          "name": "Example 25GbE controller firmware",
          "version": "22.31.1014",
          "supplier": { "name": "Example NIC maker" }
        }
      ]
    }
  ],
  "dependencies": [
    { "ref": "server-rack12-u07", "dependsOn": ["nic-slot3"] },
    { "ref": "nic-slot3", "dependsOn": ["nic-slot3-fw"] }
  ]
}

If the vendor supplies a firmware SBOM, reference it from the firmware component with an external reference rather than copying its contents. That keeps the HBOM stable while the firmware SBOM changes with each release.

7. Store, refresh and query

Load one record per machine into your asset system and firmware SBOMs into your SBOM repository, refreshing after every firmware update. Then test the reverse lookup: take a recent NIC or drive firmware advisory and time how long listing affected machines takes. If it is more than a few minutes, normalise your identifiers.

Where Safeguard fits, honestly

Safeguard does not produce HBOMs, scan firmware images, read SPI flash, verify SPDM measurements or manage devices, and it is not an endpoint product. Collecting the hardware inventory in this post is work for your asset system, fwupd, vendor tools and Redfish.

The overlap is the software side. Safeguard generates and analyses SBOMs in SPDX and CycloneDX, and accepts uploaded SBOMs, including ones a hardware or firmware vendor gives you (safeguard scan --sbom vendor-bmc-sbom.json from the CLI). It matches the components declared in those SBOMs against vulnerability databases, shows which of your projects and products contain a given component and version, and accepts CSAF and VEX uploads so vendor "not affected" statements can be recorded. Its third party risk module can request SBOMs from suppliers and track their status. All of this depends on the vendor declaring the components; Safeguard does not discover what is inside a firmware binary on its own. It also covers the software you build to run on this hardware, which is where most teams can act fastest.

Common mistakes

• Recording the device and not the firmware. "Rack server" or "25GbE NIC" is not enough. Advisories are per controller and firmware version.
• One row for device and firmware. Updating firmware then overwrites the hardware record, and you lose history. Keep them as linked records, as CycloneDX recommends.
• Trusting marketing names as identifiers. The CISA framework's 64 GB DDR4 example covers 21 part numbers. Use part numbers and PCI or USB IDs.
• Assuming fwupd sees everything. It reports only devices with plugins. Cross check against lspci, lsusb and nvme list.
• Forgetting the BMC is a computer. It has an OS, a web server, TLS and SSH. It needs a firmware SBOM and a patch schedule like any server.
• Collecting once. Firmware changes with updates and repairs. NIST SP 800-161 asks for configuration control for component service and repair for this reason.
• Asking for an HBOM after the contract is signed. You have the most influence over a supplier before the purchase. Put HBOM, firmware SBOM and support period requirements in the RFP.
• Treating an SBOM as the whole program. NIST is explicit that SBOMs complement vulnerability management and vendor risk assessment; they do not replace them.
• Exposing serial numbers and MAC addresses carelessly. An HBOM with serials, locations and MACs is sensitive. Restrict who can read it.

FAQ

What is a hardware bill of materials (HBOM)?

An HBOM is a structured list of the physical components in a product, such as chips, boards, modules and assemblies, with their manufacturers, part numbers and, depending on the use case, locations and production details. CISA's 2023 framework defines a shared set of HBOM fields and use cases for buyers and suppliers.

What is the difference between an HBOM and an SBOM?

An HBOM lists physical parts. An SBOM lists software components, including firmware and the libraries inside it. Firmware links the two: record the device in the HBOM and its firmware as a separate component with its own SBOM.

Does CycloneDX support hardware?

Yes. CycloneDX has device and firmware component types, recommends recording a device and its firmware as separate components, and has an official cdx:device property namespace for serial numbers, board locations, lot numbers and MAC addresses.

Does SPDX 3.0 have a hardware profile?

Not in the released specification. SPDX 3.0.1 can label packages with the purposes device, firmware and deviceDriver. A hardware profile is being developed in the SPDX model repository but is not part of 3.0.1.

How do I list firmware versions on Linux?

Run fwupdmgr get-devices for devices fwupd supports, then fill gaps with dmidecode for system firmware, nvme id-ctrl for drive firmware, ethtool -i for NIC firmware and vendor tools for anything else.

How do I get firmware inventory from a server BMC?

Query the Redfish UpdateService/FirmwareInventory collection. Each entry follows DMTF's SoftwareInventory schema with name, version, release date and whether it can be updated. Use a read only account on an isolated management network.

What should I ask a hardware vendor about firmware security?

Ask for firmware SBOMs per release, the update channel and support period, how firmware is protected, detected and recovered under NIST SP 800-193, whether components support SPDM, whether they publish VEX or CSAF advisories and whether Secure Boot uses production keys.

What is SPDM and why does it matter for inventory?

SPDM is a DMTF protocol for authenticating hardware identity and firmware measurements between devices. It lets a host or BMC ask a NIC or drive to prove what it is and what firmware it runs, rather than trusting a reported version string.

Fix it without waiting for upstream

When a server or laptop is rebuilt, reflashed or replaced, it pulls operating system packages, drivers, agents and application dependencies again, and BMC and appliance images ship open source components of their own. The fit with hardware itself is indirect: nothing below touches firmware or hardware, but it keeps the open source software you build and run on that hardware current and fixed.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real terminal session with the Safeguard CLI. It reads a vulnerability finding and its advisory, asks before each command, upgrades a dependency, runs the tests with your approval and pushes nothing. The same flow applies to the inventory scripts and services in this post, such as the collector that queries Redfish or the dashboard that stores firmware versions, which carry their own open source dependencies.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code and runs scans from the terminal. That suits a management workstation on an isolated network, where you want to scan a vendor supplied firmware or BMC SBOM without sending it anywhere else.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask which of your projects and products contain a component that a firmware advisory names, as long as the vendor's SBOM is in your Safeguard inventory.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard at safeguard.sh/download and read the CLI documentation.

Quick check

Sources

• CISA, Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management (publication page)
• CISA, A Hardware Bill of Materials Framework for Supply Chain Risk Management (PDF)
• CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• NIST SP 800-161 Rev 1, Cybersecurity Supply Chain Risk Management Practices
• NIST SP 800-161 Rev 1 PDF
• NIST SP 800-218, Secure Software Development Framework 1.1
• NIST SP 800-218 Rev 1, initial public draft
• NIST SP 800-193, Platform Firmware Resiliency Guidelines
• NIST SP 800-147, BIOS Protection Guidelines
• CycloneDX 1.6 JSON reference
• CycloneDX 1.7 JSON reference
• CycloneDX, Hardware Bill of Materials capability
• CycloneDX property taxonomy, cdx:device namespace
• CycloneDX specification releases
• SPDX 3.0.1, SoftwarePurpose vocabulary
• SPDX 3.0.1, ProfileIdentifierType vocabulary
• SPDX specification releases
• DMTF Redfish SoftwareInventory schema
• DMTF Redfish Developer Hub
• DMTF DSP0274, Security Protocol and Data Model (SPDM) 1.3.0
• Linux Vendor Firmware Service
• LVFS documentation
• fwupdmgr manual
• Open Source Firmware Foundation, Firmware Embedded SBOM Specification
• nvme-cli documentation, nvme log fw

Last reviewed: 23 October 2026.