Hardware Bill of Materials (HBOM): The Complete Guide

A hardware bill of materials (HBOM) is a structured list of the physical parts inside a product, such as chips, boards, modules and assemblies, with who made each one, its part number, where it was made and assembled, and which firmware it ships with. Buyers use it to check compliance rules, spot untrusted or counterfeit parts and find single points of failure in supply. CISA published a voluntary HBOM framework in September 2023 that defines the use cases and field names, and CycloneDX can carry those fields in a machine readable file today.

This guide covers what goes into an HBOM, who writes and reads it, the CISA taxonomy, formats, a worked example and how an HBOM connects to SBOMs, firmware and cryptography inventories. For the short conceptual split, read HBOM vs SBOM first. If you want commands that collect firmware versions from real laptops and servers, our hardware and firmware inventory guide does that.

Key takeaways

• An HBOM answers "what is this product physically made of, by whom and where".
• CISA's framework is a vocabulary, not a file format. Published 25 September 2023 by the ICT Supply Chain Risk Management Task Force, it defines three use case categories, seven field categories, a parent and child nesting model and named fields such as COMP_MANUFACTURER_PN and COMP_MFG_LOC_CODE. Use is voluntary.
• Different questions need different fields. A forced labour compliance check needs entity names and locations; a counterfeit check needs part numbers, date codes and supplier type; an availability check needs lead times and sourcing percentages.
• CycloneDX is the practical machine readable home. It has device and firmware component types, a manufacturer field since 1.6, and an official cdx:device property namespace for serial numbers, lot numbers and board locations.
• Firmware is the bridge. An HBOM names the firmware each part ships with; the firmware's own contents belong in a firmware SBOM, and any cryptography it uses can go in a cryptography BOM (CBOM).
• Identity resolution is the hard part. CISA's own appendix shows one generic memory module name mapping to 21 part numbers.
• An HBOM supports compliance; it does not prove it. CISA states that using the framework does not mean a company has complied with any US regulation.

Timeline: where HBOMs came from

What is a hardware bill of materials?

An engineering BOM records how a product is designed, a manufacturing BOM records what the factory needs to assemble it, and both are working documents inside the maker's systems. A security HBOM borrows that structure but serves a different reader: the buyer who has to decide whether a product is safe to deploy, legal to buy and likely to stay available.

CISA's framework states the goal plainly. The Task Force's HBOM working group wanted "a consistent, repeatable way" for vendors to describe the hardware components in products to the people who buy them, so that buyers can evaluate and reduce supply chain risk. It captures component information at the time of sale, and a new HBOM may be reasonable when the product version changes.

Three things make an HBOM different from the BOM a factory already has:

1. It is shared across a trust boundary. The supplier chooses what to disclose, and both sides must agree what each field means.
2. It records entities and places, not just parts. It says who made a part, where, and through which distributor it was bought.
3. It is organised around risk questions. CISA maps every field to the use cases that need it, so a buyer asking about forced labour rules gets a different subset of fields from one asking about counterfeit parts.

An HBOM is also not an asset inventory. It describes what one model is built from; your asset system says where the units are. Join them by model and hardware revision.

What goes in an HBOM?

Most HBOM confusion starts with the word "parts". A useful HBOM records seven kinds of information, which map closely to CISA's field categories.

Parts and assemblies

The core of the HBOM is the list of components: integrated circuits, discrete parts such as resistors and capacitors, circuit assemblies, modules, connectors and antennas. CISA's COMP_PART_TYPE holds the category, COMP_DESCRIPTION a human description and QUANTITY the count per unit.

Depth is a choice. Listing every passive part rarely helps security; most buyers care first about anything programmable or radio capable (processors, systems on chip, memory, storage controllers, network and wireless modules, security chips) and anything with a single source of supply.

Manufacturers, suppliers and the entities behind them

CISA separates several roles that a casual list merges:

• FGA_SUPPLIER: the finished good OEM, the brand on the box.
• FGA_MAIN_MANUFACTURER: whoever actually builds the product. If the OEM uses a contract manufacturer, that contract manufacturer goes here.
• FGA_ALT_MANUFACTURER: a second builder used if the first is unavailable.
• COMP_MANUFACTURER: the component maker, and for semiconductors the fab name as well.
• COMP_SUPPLIER: who the part was bought from, if not directly from the manufacturer.
• ASSY_AND_TEST_SUPPLIER: for semiconductors, the company that packaged and tested the die.

That split matters because a chip can be designed, fabricated and packaged by three companies in three countries. CISA's semiconductor example records each as a separate data point, plus the technology node.

Part numbers and identifiers

COMP_MANUFACTURER_PN holds the manufacturer's part number, COMP_SUPPLIER_PN holds the buyer's or supplier's internal ERP number, COMP_PART_CODE holds an industry standard code such as an SMD capacitor code, and COMP_HASH and FGA_HASH hold an intrinsic identifier. COMP_OPT_NAME allows a project specific name.

Part numbers are the join key for matching advisories, counterfeit alerts and end of life notices, and the field most likely to be inconsistent.

Firmware

CISA's FGA_VERSION and COMP_VERSION fields take "Hardware, and/or Software, and/or Firmware version number, as shipped from the supplier", with examples such as "Firmware Version 13.3.3.2". The framework records who provides the firmware and its version, but says it "stops short" of a framework for firmware provenance.

So name the firmware each programmable part ships with, and point to a separate firmware SBOM for its contents. CycloneDX's schema says a hardware device containing firmware should be recorded as one component for the physical hardware and another of type firmware for the software on it.

Country of origin and locations

This is the largest field group in the CISA taxonomy. For the OEM headquarters, the main manufacturing site, the alternate site, the component manufacturing site and the semiconductor assembly and test site, CISA offers three interchangeable ways to express a location: a free text address, latitude and longitude, or an ISO 3166 country and subdivision code such as "US-MA". It labels them "Option 1 of 3" through "Option 3 of 3".

Prefer the ISO code form. CISA also warns that a single "Country of Origin" field in another format cannot map one to one onto these location fields, because origin can mean the OEM's home, the assembly site or the fab, and the right answer depends on the rule you are checking.

Lifecycle status

The standards are thin here. CISA's taxonomy has no dedicated end of life or lifecycle status field. Its use case table does mention adherence to product change notifications as an internal and quality compliance example, and its production fields include LEADTIMES (supplier lead time in days) and SUPPLIER_SOURCED_PCTG (share sourced from this supplier when a part is multi sourced). CycloneDX's lifecycles metadata describes the phase in which a BOM was produced (design, pre-build, build, post-build, operations, discovery, decommission), not whether a part is still made.

If you need lifecycle status, agree a property name with your supplier (for example acme:lifecycle:status with values such as active, not recommended for new designs, last time buy and obsolete) plus a date. CISA's advice for any field without an equivalent is a user defined field whose meaning both parties agree.

Production details

The last group covers sourcing and physical details: SUPPLIER_SOURCED_PCTG, LEADTIMES, QUANTITY, TECHNOLOGY_NODE for semiconductors, COMP_PART_SIZE_VAL and COMP_PART_SIZE_UNIT, COMP_DATASHEET as a URL, and COMP_DATECODE for the component timestamp, lot date code or lot number. Date and lot codes let a counterfeit investigation trace one batch.

Field summary

Who produces an HBOM and who consumes it?

An HBOM is assembled from several layers of the supply chain, and each layer knows only part of the truth.

The OEM is usually the author of record. On the buyer side, agree up front who owns the file once it arrives, where it is stored and when it is refreshed.

CISA treats these roles as open questions. Its Appendix D raises who should produce, gather, publish, share and protect HBOMs, whether HBOMs are internal to a supply chain or public, whether they are for humans or automation, what rights customers have to get them, and what contract clauses are needed if they are not given freely. None is settled yet.

How does the CISA HBOM framework organise the data?

Use case categories

CISA defines three categories, each with sub-categories:

When a use case fits more than one category, CISA classifies it by the first match in the order compliance, security, availability.

Field categories and the mapping between them

The seven field categories are HBOM header information, entity name, entity location, finished good product details, component part information, component part details and production details. CISA's Table 4 maps each use case to the categories it needs, and each field in Appendix C carries a "Use Case Mapping" line.

This mapping is the most practical part. It turns "send us your HBOM" into "send us the fields listed for the government compliance and product level security use cases", which a supplier can actually scope and price.

The worked examples

The framework includes three examples. One applies HBOMs to forced labour import rules, one queries entity locations after a regional shutdown in Shenzhen, China, and the third checks supplier country of origin against US federal security restrictions and makes a point worth repeating: because restricted lists change, an attestation from a supplier is "not helpful except for a specific point in time", while the HBOM stays useful when the list is amended.

The nesting model

CISA recommends an HBOM for any product, kit or assembly that can be broken down further, joined to its parent by part level information. Its Figure 1 example yields four nested HBOMs, and for spreadsheets it suggests one tab per assembly level. It also warns that key information "may be hidden at the assembly/kit level", so the granularity has to match the use case.

HBOM formats compared

There is no single HBOM file format. You will meet three approaches.

Spreadsheet in the CISA layout

Many first HBOMs arrive as a spreadsheet with one tab per assembly. That suits human review, but spreadsheets drift and nobody validates them, so they break down at scale.

CycloneDX

CycloneDX, an OWASP project, describes its HBOM capability as inventorying hardware components "for IoT, ICS, and other types of embedded and connected devices", alongside associated firmware and configurations. The pieces you will use are:

• The device component type, defined in the schema as "a hardware device such as a processor or chip-set".
• The firmware component type, "a special type of software that provides low-level control over a device's hardware".
• The manufacturer field on components, added in 1.6, distinct from supplier, which "may often be the manufacturer, but may also be a distributor or repackager". That distinction maps neatly onto CISA's manufacturer and supplier split.
• Nested components and the dependencies graph, which carry the parent and child structure.
• The official cdx:device property namespace: quantity, function, location on the board, deviceType (such as SMD or through hole), serialNumber, sku, lotNumber, prodTimestamp and macAddress. Related namespaces link to engineering and manufacturing BOMs, radio certifications and GS1 identifiers.

CycloneDX has no native fields for manufacturing location, technology node or lead time. Carry those as properties with an agreed prefix, or with the CISA field name as the property name, which keeps the mapping obvious.

SPDX 3.0.1

SPDX 3.0.1's SoftwarePurpose vocabulary includes device ("refers to a chipset, processor, or electronic board"), firmware ("provides low level control over a device's hardware") and deviceDriver. That lets you say what an element is. The released specification has no hardware profile, so fab location, assembly and test supplier, technology node and date codes need extensions. Keep SPDX firmware SBOMs if suppliers send them.

Which to choose

For most teams the answer is: use CISA's field names as your dictionary, CycloneDX as your file, and a spreadsheet export only when a human reviewer asks for one.

Worked example: an HBOM for a small industrial gateway

The example below builds an HBOM for a fictional cellular industrial IoT gateway, "Example GW-200", hardware revision C. All companies and part numbers are placeholders. The point is the structure, which you can copy.

Step 1: write down the use case first

Before anyone touches a spreadsheet, decide which CISA use cases you need. For this gateway, assume the buyer is a utility that must check government restrictions on telecom equipment, wants component level security information, and cares about availability because the units are installed for ten years. That selects the government compliance, product level security and world events availability use cases, and with them nearly every field group.

Step 2: break the product down

Example GW-200 rev C (finished good)
├── Main board assembly MB-200 rev 4
│   ├── Application SoC (semiconductor)          firmware: boot ROM + bootloader
│   ├── LPDDR4 memory, 1 GB (semiconductor)
│   ├── eMMC storage, 8 GB (semiconductor)       firmware: eMMC controller firmware
│   ├── Secure element (semiconductor)           firmware: secure element OS
│   ├── Ethernet PHY x2 (semiconductor)
│   └── Passives, connectors (summarised)
├── Cellular module CM-4G (assembly)            firmware: modem firmware
│   ├── Baseband chipset (semiconductor)
│   └── RF front end (semiconductor)
├── Power supply unit PSU-24 (assembly)
└── Enclosure and antenna kit KIT-ANT (kit)

That gives four HBOMs in CISA terms: the finished good, the main board, the cellular module and the power supply.

Step 3: fill the CISA fields for the parts that matter

A slice of the main board HBOM, using the CISA field names as columns:

The location codes are placeholders in ISO 3166 style.

Step 4: write the same data as CycloneDX

The fragment below shows the finished good, the main board, the SoC with its firmware nested as CycloneDX recommends, and CISA fields carried as properties. It is trimmed to two components to stay readable.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-23T09:00:00Z",
    "lifecycles": [ { "phase": "post-build" } ],
    "authors": [ { "name": "Example OEM product security" } ],
    "component": {
      "type": "device",
      "bom-ref": "gw200-revC",
      "name": "Example GW-200",
      "version": "rev C",
      "manufacturer": { "name": "Example Contract Manufacturing" },
      "supplier": { "name": "Example OEM" },
      "properties": [
        { "name": "cisa:hbom:FGA_MAIN_LOC_CODE", "value": "XX-07" },
        { "name": "cisa:hbom:FGA_SUPPLIER_LOC", "value": "XX-08" }
      ]
    }
  },
  "components": [
    {
      "type": "device",
      "bom-ref": "mb200-rev4",
      "name": "MB-200 main board",
      "version": "rev 4",
      "manufacturer": { "name": "Example Contract Manufacturing" },
      "components": [
        {
          "type": "device",
          "bom-ref": "soc",
          "name": "EX-SOC-A53-Q",
          "description": "Application SoC",
          "manufacturer": { "name": "Example Silicon" },
          "supplier": { "name": "Example Authorized Distributor" },
          "properties": [
            { "name": "cdx:device:function", "value": "microprocessor" },
            { "name": "cdx:device:location", "value": "U1" },
            { "name": "cdx:device:deviceType", "value": "SMD" },
            { "name": "cdx:device:lotNumber", "value": "2631" },
            { "name": "cisa:hbom:COMP_MFG_LOC_CODE", "value": "XX-01" },
            { "name": "cisa:hbom:ASSY_AND_TEST_LOC_CODE", "value": "XX-02" },
            { "name": "cisa:hbom:TECHNOLOGY_NODE", "value": "28nm" },
            { "name": "cisa:hbom:LEADTIMES", "value": "84" },
            { "name": "example:lifecycle:status", "value": "active" }
          ],
          "components": [
            {
              "type": "firmware",
              "bom-ref": "soc-bootloader",
              "name": "GW-200 bootloader",
              "version": "2.4.1",
              "supplier": { "name": "Example OEM" },
              "externalReferences": [
                { "type": "bom", "url": "https://example.com/sbom/gw200-bootloader-2.4.1.cdx.json" }
              ]
            }
          ]
        },
        {
          "type": "device",
          "bom-ref": "secure-element",
          "name": "EX-SE-050",
          "manufacturer": { "name": "Example Secure" },
          "properties": [
            { "name": "cdx:device:function", "value": "security" },
            { "name": "cdx:device:location", "value": "U7" },
            { "name": "cisa:hbom:TECHNOLOGY_NODE", "value": "40nm" }
          ],
          "components": [
            { "type": "firmware", "bom-ref": "se-os", "name": "Secure element OS", "version": "7.2" }
          ]
        }
      ]
    }
  ],
  "dependencies": [
    { "ref": "gw200-revC", "dependsOn": [ "mb200-rev4" ] },
    { "ref": "mb200-rev4", "dependsOn": [ "soc", "secure-element" ] },
    { "ref": "soc", "dependsOn": [ "soc-bootloader" ] },
    { "ref": "secure-element", "dependsOn": [ "se-os" ] }
  ]
}

Three design choices are worth copying. The firmware is a child of the chip it runs on, so a firmware update changes one record without implying new hardware. The firmware component links to its own SBOM through an external reference instead of copying its contents. And every CISA field without a native CycloneDX home uses a cisa:hbom: property named after the CISA field, so a reviewer can map it back without a lookup table. The cisa:hbom: and example: prefixes are our conventions, not official CycloneDX namespaces.

Step 5: validate it

Validate against the schema before you share or ingest anything. The official CycloneDX CLI does this and can fail a build on errors:

# Validate a CycloneDX 1.6 JSON HBOM; non-zero exit on errors
cyclonedx validate --input-file gw200-revC.hbom.cdx.json \
  --input-format json --input-version v1_6 --fail-on-errors

Schema validation only proves the file is well formed. It does not prove a part number is real or a location is correct. Add checks for the properties each use case requires.

Step 6: query it

Once HBOMs are files, the questions in CISA's examples become one line queries. With jq:

# Every device with its manufacturer and component manufacturing location
jq -r '.. | objects | select(.type? == "device") |
  [.name, (.manufacturer.name // "-"),
   ((.properties // [])[] | select(.name=="cisa:hbom:COMP_MFG_LOC_CODE") | .value)] | @tsv' \
  gw200-revC.hbom.cdx.json

# Every firmware component and version, for matching against advisories
jq -r '.. | objects | select(.type? == "firmware") | [.name, .version] | @tsv' \
  gw200-revC.hbom.cdx.json

# Devices whose lead time is over 90 days (availability use case)
jq -r '.. | objects | select(.type? == "device") |
  select((.properties // [])[] | select(.name=="cisa:hbom:LEADTIMES") | (.value|tonumber) > 90) | .name' \
  gw200-revC.hbom.cdx.json

Step 7: version and refresh

Give each HBOM a serial number and increment version when you correct it. Issue a new HBOM, not an edit, when the hardware revision changes or a substitute part is approved. Store it beside its firmware SBOMs, keyed by model and revision, and join it to your asset inventory.

How does an HBOM fit with SBOM, FBOM and CBOM?

Each BOM describes a different layer. Mixing them up is a common reason HBOM projects stall.

SBOM

CISA's 2026 Minimum Elements, published 29 July 2026, replace the 2021 NTIA minimum elements for SBOMs. There is no equivalent list for HBOMs; the HBOM framework puts SBOM information out of scope and recommends future work so the two can merge.

Firmware SBOM, or FBOM

"FBOM" is an informal name, not a separate standard. A firmware bill of materials is an SBOM whose subject is a firmware image. It is hard to get because several parties assemble firmware. The Open Source Firmware Foundation's Firmware Embedded SBOM Specification (0.10, 21 February 2024) describes a firmware vendor writing most of the source, an ODM adding code and binaries, and an OEM extending and shipping it, and proposes embedding the SBOM in the image so it travels with the binary.

In an HBOM, the firmware component carries the shipped version and a reference to the firmware SBOM. Our post on CycloneDX component types for firmware and devices covers the modelling detail, and why firmware below the OS goes unpatched explains why those versions drift.

CBOM

CycloneDX describes its Cryptography Bill of Materials as transparency into "cryptographic assets like algorithms, keys, and certificates" and their relationships to software components, aimed largely at post-quantum migration. In the 1.6 schema the cryptographic-asset component type covers "algorithms, protocols, certificates, keys, tokens, and secrets". For hardware it matters most for secure elements, TPMs and modems. Our post on post-quantum migration covers why that inventory is suddenly urgent.

How they link

The chain runs from the HBOM's device, to its nested firmware component, to the firmware SBOM, to a CBOM of cryptographic assets. For keeping these in one file, see our post on hardware and software in one bill of materials for IoT devices.

What rules and guidance drive HBOM requests?

No US federal rule requires a CISA style HBOM by name. Several rules create questions an HBOM helps answer.

FAR 52.204-25 covers named producers and "any subsidiary or affiliate of such entities", so check corporate structures, not just the label. DFARS 252.246-7008 defines an electronic part as an integrated circuit, a discrete component or a circuit assembly; recording each part's supplier and channel makes its sourcing hierarchy auditable.

The hard problem: part and entity resolution

CISA's Appendix D is unusually candid. It says that variations in supplier nomenclature "can hinder HBOM content evaluations" and make it hard to link a product's SBOM to its HBOM. Its examples show both directions of the problem:

• One generic name, many parts. A generic DDR4 64 GB memory module name covers 21 different part numbers, and a phone model name covers various SKUs by colour and storage.
• Many identifiers, one part. The same part number written with and without hyphens, or a marketing name and an internal part number for the same chip.
• Many names, one company. "Corp", "Corporation" and the bare name, or a full legal name and its abbreviation.
• Rebranding after acquisitions. An acquired company's part number replaced by the acquirer's, with both still in circulation.

Identifier systems such as DUNS, SAM and CAGE help but, CISA notes, miss many small or foreign manufacturers.

What works in practice:

1. Normalise part numbers on ingest. Uppercase, strip spaces and punctuation, and keep the original string alongside the normalised one.
2. Keep an alias table for companies. Map every spelling, subsidiary and acquired brand to one canonical entity, and include known affiliates for any restricted list you check.
3. Prefer manufacturer part numbers over descriptions. "64 GB DDR4" is a description; only the full manufacturer part number identifies the part.
4. Test the reverse lookup. Take a recent advisory or restricted entity update and time how long it takes to list affected products. If it takes more than minutes, fix identifiers before adding fields.

Where Safeguard fits, honestly

Safeguard does not generate HBOMs. It does not inventory hardware, read part numbers or lot codes off boards, scan firmware images or manage devices, and it does not analyse hardware fields such as fab location or technology node. Building the HBOM is work for your suppliers and your own product, procurement and asset systems.

Safeguard helps with the software beside every HBOM. It generates and analyses SBOMs in SPDX and CycloneDX, and accepts SBOMs you upload, including firmware SBOMs that a hardware vendor gives you (safeguard scan --sbom vendor-firmware-sbom.json from the CLI). It matches the software components declared in those SBOMs against vulnerability databases and shows which of your projects and products contain a given component and version. It accepts CSAF and VEX uploads, so a vendor's statement that a firmware build is not affected can be recorded next to the finding. Its third party risk module can request SBOMs from suppliers and track them. All of this depends on the supplier declaring what is inside the firmware; Safeguard does not discover the contents of a firmware binary on its own.

Common mistakes

• Asking for "the HBOM" without a use case. Suppliers then send either everything or nothing. Name the CISA use cases and the fields you need.
• Treating the HBOM as an asset inventory. An HBOM describes a model and revision. You still need to know which deployed units match it.
• One component for a chip and its firmware. Firmware changes far more often than silicon. Record them separately and nest the firmware under the device.
• A single "country of origin" field. Origin can mean the OEM's home, the assembly site, the fab or the assembly and test site. Record the ones your rule actually needs.
• Stopping at the assembly level. CISA warns that key information can hide inside a kit or assembly. If a module contains a radio chip or a secure element, break it down.
• Treating an HBOM or attestation as proof of compliance. CISA says the framework is not evidence of compliance by itself, and an attestation is only valid at a point in time.
• Never refreshing it. Tie a new HBOM to every hardware revision or approved substitute part.

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, suppliers, part numbers, firmware versions, manufacturing locations and production details.

What is the difference between an HBOM and an SBOM?

An HBOM lists physical parts and the companies and places behind them; an SBOM lists software components and their versions and dependencies. Firmware is where they meet: the HBOM names the firmware a part ships with, and a firmware SBOM lists what is inside it.

What should be included in an HBOM?

At minimum: the product and revision, each significant component's manufacturer, supplier and part number, the firmware version on each programmable part, and the locations your rules require. Add lot codes for counterfeit tracing and lead times for availability.

Is there a standard HBOM format?

There is a standard vocabulary, CISA's 2023 HBOM framework, and a standard file format that supports hardware, CycloneDX, which is also published as ECMA-424. CISA's fields map onto CycloneDX where an equivalent exists and otherwise go into named properties. SPDX 3.0.1 can label elements as devices or firmware but has no released hardware profile.

Is an HBOM required by law?

No US federal rule requires a CISA style HBOM by name, and CISA describes the framework as voluntary. Rules such as FAR 52.204-25 and DFARS 252.246-7008 create obligations that an HBOM helps you meet, and some contracts and sector regulators ask for hardware component information.

Does an HBOM include firmware?

Yes, at the level of who provides it and which version ships. CISA's version fields explicitly accept firmware versions. The framework stops short of firmware provenance, so the firmware's contents belong in a separate firmware SBOM linked from the HBOM.

What is an FBOM or firmware bill of materials?

FBOM is an informal term for an SBOM whose subject is a firmware image. There is no separate FBOM standard; CycloneDX has a firmware component type, SPDX has a firmware purpose, and the Open Source Firmware Foundation has a draft specification for embedding an SBOM inside firmware images.

What is a CBOM and how does it relate to an HBOM?

A CBOM, or cryptography bill of materials, lists cryptographic assets such as algorithms, keys, certificates and protocols. CycloneDX added the cryptographic-asset component type in 1.6.

Fix it without waiting for upstream

An HBOM tells you which firmware each part ships with, and that firmware, the device drivers and the management tools around it are built from open source components that need the same patch discipline as any application. The block below covers that software side and the open source you build and ship yourself; it does not patch silicon or vendor firmware, which still has to come from the vendor.

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 software around an HBOM program, such as the scripts that validate and query HBOM files or the service that stores them, 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 firmware SBOMs received from suppliers under NDA, scanned on a machine you control.

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 software component named in a firmware advisory, as long as the supplier's firmware 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 (HBOM) Framework for Supply Chain Risk Management (PDF)
• CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• CycloneDX, Hardware Bill of Materials (HBOM) capability
• CycloneDX, Cryptography Bill of Materials (CBOM) capability
• CycloneDX 1.6 JSON reference
• CycloneDX 1.6 JSON schema
• CycloneDX property taxonomy, cdx:device namespace
• CycloneDX specification releases
• CycloneDX CLI, validate command
• Ecma International, ECMA-424 CycloneDX Bill of materials specification
• SPDX 3.0.1, SoftwarePurpose vocabulary
• Open Source Firmware Foundation, Firmware Embedded SBOM Specification
• NIST SP 800-161 Rev 1 Update 1, Cybersecurity Supply Chain Risk Management Practices
• FAR 52.204-25, Prohibition on Contracting for Certain Telecommunications and Video Surveillance Services or Equipment
• DFARS 252.246-7008, Sources of Electronic Parts

Last reviewed: 23 October 2026.