CISA HBOM Framework Explained: Fields, Taxonomy and Use Cases

The CISA Hardware Bill of Materials (HBOM) Framework, published on 25 September 2023, is a voluntary vocabulary that tells hardware vendors and buyers which facts to exchange about the parts inside a product and how to name them. It defines three use case categories (compliance, security and availability), seven data field categories, 47 named fields and a parent and child nesting model, with partial mappings to CycloneDX and SPDX. It is not a file format, and it leaves software and firmware provenance out of scope.

We read the 33 page PDF in full and checked the rules it relies on against their primary sources. This post explains, in our own words, why the framework exists, how its use cases decide which fields you ask for, every field in the taxonomy, how the fields map to CycloneDX and SPDX, and where the document is thin or inconsistent. For the broader picture first, see our explainer on HBOM vs SBOM.

Key takeaways

• It is a shared vocabulary, not a file format. It gives field names, a nesting structure and guidance on which fields fit which purpose. It suggests spreadsheets and maps some fields to CycloneDX and SPDX.
• Use is voluntary, and it is not proof of compliance. The document says so explicitly.
• Three use case categories split into eight sub-categories. Compliance (government, industry or customer, internal and quality), security (geography and entity, product and component) and availability (world events, clustering for risk, clustering for optimisation).
• The use case decides the fields. A mapping table says which of the seven field categories each sub-category needs.
• Only about ten of the 47 fields map one to one to CycloneDX or SPDX. Every location field needs a custom property agreed between producer and requester.
• The document names its own gaps: part and entity name resolution, HBOM integrity and provenance, roles and rights, and fuller format mapping.

Timeline: where the framework came from

What is the CISA HBOM framework?

The framework was written by the HBOM Working Group of the ICT SCRM Task Force, a public and private body co-chaired by CISA, through its National Risk Management Center, and by representatives of the IT and Communications critical infrastructure sectors. The working group drew members from federal agencies, national laboratories, research organisations and IT and telecom companies.

Its goal is a consistent, repeatable way for vendors to tell purchasers about the hardware components in products they buy, so purchasers can evaluate and reduce supply chain risk. It delivers three things: a naming method for component attributes (every fact gets a lowercase field name such as comp_manufacturer_pn, a type, a description and an example), a consistent structure for describing components from a finished product down to a single capacitor, and guidance on what to include for a given purpose.

The practical content sits in four appendices: A covers use cases and the mapping of use cases to field categories, B covers format and nesting, C is the field taxonomy with a quick reference table, and D lists out of scope topics and future work.

The prefix "fga" runs through the field names. The taxonomy never expands it, but every fga field describes the finished good that is the subject of that HBOM, while "comp" fields describe a child component.

Why did CISA publish it?

Section 1.1 points to earlier Task Force work. Its threat evaluation report concluded that hardware components carry economic risk as well as security risk from untrusted or compromised parts. Its COVID-19 report found that customers need more visibility into sub-tier suppliers that are the only source or sit in a single region.

It also names a compliance driver: laws banning equipment with components made by forced labour. So the framework is at least as much about who made things, where, and how fragile the sourcing is, as about vulnerabilities.

What is in scope and what is not?

Section 1.3 sets the boundaries. In scope: consistent attribute names, a consistent format for describing components, guidance on what to include per purpose, and the HBOM as it stands at the time of sale. It also records basic firmware information, specifically who provides the firmware for a component.

Out of scope:

• SBOM information. The framework calls SBOM data crucial, tries to stay consistent with CycloneDX and SPDX, and recommends future work so HBOM and SBOM frameworks can merge.
• Firmware provenance. It names the firmware provider but stops short of examining the provenance and other attributes of that firmware.
• Lifecycle updates. It notes HBOMs may need updating, for example when the vendor changes the product version, but defines no update process.

Section 1.2 adds that requesting an HBOM is one activity among several. Purchasers should also send cybersecurity questionnaires, such as the Task Force's vendor template, and request SBOMs. It is frank that current formats need help to be portable, and that true interoperability will need broader industry discussion and proof of concept testing. If firmware is your real concern, our post on why firmware below the OS goes unpatched covers what this framework leaves out.

What are the HBOM use cases?

Appendix A starts from three reasons a purchaser asks for an HBOM: spotting security risks in components, spotting a supply chain that is not diversified enough, and checking compliance with laws that ban certain components. These checks can be proactive, part of an audit, or a reaction to an event.

A real use case often fits several sub-categories. The framework handles this with a precedence rule: classify each use case once, checking compliance first, then security, then availability. A country of origin review driven by a federal restriction is therefore a compliance case, even though its motive is plainly security. This matters for templates, because the compliance columns usually need the widest set of fields.

Which fields does each use case need?

Table 3 groups every field into seven categories, and Table 4 says which categories each sub-category requires. Counts below come from the quick reference table in section C.8.

A footnote adds useful flexibility: the category mapping is required, but within each category you choose the pertinent fields. If a sub-category needs entity location, you must cover location, but you can agree on ISO codes only.

Header, entity name and part information are universal, so build those first. Location is skipped for internal quality and product and component security; production details serve availability. One wrinkle: as we read the matrix, Table 4 ticks production details for product and component security, while each production field in Appendix C lists security as not applicable. More on that under gaps.

How do the worked examples use the fields?

Compliance with the UFLPA. CBP describes the law as a rebuttable presumption that goods mined, produced or manufactured wholly or in part in the Xinjiang region, or by an entity on the UFLPA Entity List, are barred from import under 19 U.S.C. 1307. Because that reaches any component or material, knowing the finished good's manufacturer is not enough. The framework uses entity name and location fields to compare against the region and the list, then header, finished good and part fields to see which products are affected. It adds that its examples are not legal advice.

Availability after a regional shutdown. The second example uses the temporary shutdown of non-essential business in Shenzhen under China's zero-COVID policy. Query entity location for anything in Shenzhen, compile affected products from the header, finished good and part information, then use production details to judge the impact and plan contingencies. This is where machine readable location codes pay off.

Restricted countries or entities. For U.S. federal rules restricting certain origins or suppliers, the framework asks for header, entity name, entity location, finished good details, part information and part details. Restricted content can be the finished good, a component, or handling by a restricted entity or in a restricted place. Because restriction lists change, a supplier attestation is, in the framework's words, "not helpful except for a specific point in time." An HBOM can be checked again whenever a list is amended. A footnote cautions that using the framework is not evidence of compliance that any agency must accept.

For context, FAR 52.204-25, which implements Section 889, defines covered equipment by naming specific producers and any subsidiary or affiliate of them, and requires contractors to report covered equipment found during contract performance. That subsidiary language is why the entity resolution problem below matters.

How does the HBOM format work?

Appendix B recommends HBOM information for any product, kit or assembly that can be broken down further, which yields a hierarchical bill of materials. Its Figure 1 shows a Finished Good X made of Assembly X1, Kit X2 and two components; Assembly X1 holds two components and a semiconductor; Kit X2 holds a component and Assembly W2, which holds two more. The warning attached is the core idea: the facts you need may be hidden at the assembly or kit level, so make the granularity fine enough.

The nesting approach, suggested for spreadsheets, gives every parent its own HBOM, joined through part level information:

An OEM that buys in an assembly needs that maker's HBOM to fill the lower levels.

Table 6 separates who owns the product from who builds it. fga_supplier and fga_supplier_loc hold the OEM and its headquarters; fga_main_manufacturer and fga_main_location hold the contract manufacturer and its factory, or the OEM again if it builds in house. Collapsing these into one column loses exactly the fact a sanctions or disaster query needs.

For semiconductors, the framework asks for the supplier and the fab or foundry as separate data points, plus assembly and test details and the technology node if needed. Packaging and test are often a separate step in a separate country.

The full HBOM field taxonomy, field by field

Appendix C gives each field a type, description, example, CycloneDX and SPDX equivalents and a use case mapping. Its C.1 to C.7 headings and the C.8 quick reference group a few fields differently; we follow C.8, which matches Table 4. Unless noted, fields are strings and apply to every use case.

Header, finished good and entity name

Entity location

Each location appears up to three times, marked as substitutable options: free text, decimal degree coordinates (also a string) and an ISO 3166-2 country and subdivision code such as US-MA. All fifteen apply to government and industry compliance, geography and entity security, and all availability sub-categories.

In a template, insist on the ISO code: short, unambiguous and easy to query.

Component part information and details

Production details (availability only)

Note what is absent: no lifecycle or end of life status, no authorised distributor flag, no customs style country of origin, and firmware appears only as a version string. The framework expects you to add fields your use case needs.

How do HBOM fields map to CycloneDX and SPDX?

Section B.2 offers one to one mappings where possible. These are all the fields Appendix C maps:

Everything else has no mapping, hbom_std_version is marked "do not map", and hbom_creation_date has none even though CycloneDX's metadata timestamp is often read as creation time. Four things matter before you write conversion code.

The SPDX clause numbers follow an older 2.x layout. In SPDX 2.2.2, Creator and Created are clauses 6.8 and 6.9, and the package fields are in clause 7 (name 7.1, identifier 7.2, version 7.3, supplier 7.5, verification code 7.9, checksum 7.10). Map by field name.

SPDX 3.0.1 has no hardware profile. Its profiles are core, software, security, build, AI, dataset, licensing, lite and extension. A package's purpose can be device (a chipset, processor or board), firmware or deviceDriver, but there are no released properties for locations or production details.

CycloneDX has more hardware structure than the framework uses. CycloneDX 1.6 defines a device component type and says a device containing firmware should be described as one component for the hardware and another of type firmware. It has a component level manufacturer object, a closer fit for comp_manufacturer than supplier. The official cdx:device property namespace adds quantity, function, board location, package type, serial number, SKU, lot number, production timestamp and MAC address, which line up with unmapped CISA fields such as quantity and comp_datecode.

Country of origin is not one field. The framework's own example: a single "country of origin" field cannot take the several CISA location fields one to one, and the right mapping depends on the user. For unmapped fields it says to create user defined fields and explain them clearly to the requester. In CycloneDX that means properties under an agreed namespace.

Step by step: turning the taxonomy into a working HBOM exchange

The framework gives you names, not tooling. Here is a short path from the PDF to an HBOM you can validate and query, using jq and the CycloneDX CLI.

1. Pick the use cases, then the fields

Write down which sub-categories you need and take the union of field categories from Table 4. A contractor checking Section 889 exposure needs the government column; a team worried about a single source part needs the availability columns.

2. Start with one CSV per nesting level

hbom_std_version,hbom_creation_date,hbom_author,fga_supplier,fga_num,fga_description,fga_type,fga_version,fga_main_manufacturer,fga_main_loc_code,comp_manufacturer,comp_manufacturer_pn,comp_supplier_pn,comp_description,comp_type,comp_part_type,comp_version,comp_mfg_loc_code,assy_and_test_supplier,assy_and_test_loc_code,quantity,lead_times,supplier_sourced_pctg,comp_datecode
1.0,2026-10-20,J. Rivera,ExampleCo,GW-200,Industrial gateway rev C,hardware,HW 3.2,ExampleCM,CN-GD,ChipCo,SOC-8841,100045,Application SoC,hardware,semiconductor,FW 13.3.3,TW-HSZ,PackCo,MY-07,1,84,1.0,2532
1.0,2026-10-20,J. Rivera,ExampleCo,GW-200,Industrial gateway rev C,hardware,HW 3.2,ExampleCM,CN-GD,NetPhyCo,PHY-1G-22,100112,Gigabit Ethernet PHY,hardware,semiconductor,,US-TX,PackCo,MY-07,2,56,0.5,2528

All names and part numbers are invented. A bought in assembly, such as a radio module, gets its own CSV with that module as the finished good, joined on its part number.

3. Convert to CycloneDX

Mapped fields go into native CycloneDX fields. Unmapped CISA fields go into properties with an hbom: prefix you agree with the supplier, and official cdx:device names where they exist.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-20T00:00:00Z",
    "authors": [ { "name": "J. Rivera" } ],
    "component": {
      "type": "device",
      "bom-ref": "fg-gw-200",
      "name": "GW-200",
      "version": "HW 3.2",
      "supplier": { "name": "ExampleCo" },
      "manufacturer": { "name": "ExampleCM" },
      "properties": [
        { "name": "hbom:hbom_std_version", "value": "1.0" },
        { "name": "hbom:fga_main_loc_code", "value": "CN-GD" }
      ]
    }
  },
  "components": [
    {
      "type": "device",
      "bom-ref": "soc-8841",
      "name": "SOC-8841",
      "description": "Application SoC",
      "manufacturer": { "name": "ChipCo" },
      "properties": [
        { "name": "hbom:comp_supplier_pn", "value": "100045" },
        { "name": "hbom:comp_mfg_loc_code", "value": "TW-HSZ" },
        { "name": "hbom:assy_and_test_loc_code", "value": "MY-07" },
        { "name": "hbom:lead_times", "value": "84" },
        { "name": "cdx:device:quantity", "value": "1" },
        { "name": "cdx:device:lotNumber", "value": "2532" }
      ]
    },
    {
      "type": "firmware",
      "bom-ref": "soc-8841-fw",
      "name": "SOC-8841 boot firmware",
      "version": "13.3.3",
      "supplier": { "name": "ChipCo" }
    }
  ],
  "dependencies": [
    { "ref": "fg-gw-200", "dependsOn": [ "soc-8841" ] },
    { "ref": "soc-8841", "dependsOn": [ "soc-8841-fw" ] }
  ]
}

Three choices go beyond the framework on purpose. Firmware is its own firmware component, as CycloneDX recommends, so a firmware update does not rewrite the hardware record. The maker goes into manufacturer, leaving supplier for the distributor. And comp_hash is omitted, because a placeholder is worse than nothing.

4. Validate and check completeness

# Schema check against CycloneDX 1.6 (CycloneDX CLI)
cyclonedx validate --input-file gw-200.cdx.json --input-format json --input-version v1_6 --fail-on-errors

# List hardware components that lack a manufacturing location code
jq -r '.components[] | select(.type=="device")
  | select([.properties[]?.name] | index("hbom:comp_mfg_loc_code") | not)
  | .name' gw-200.cdx.json

An empty result from the second command is what you want.

5. Run the framework's example query

The Shenzhen example becomes a query over location codes. Shenzhen sits in Guangdong, ISO 3166-2 code CN-GD:

for f in hboms/*.cdx.json; do
  jq -r --arg code "CN-GD" --arg file "$f" '
    [.metadata.component] + .components | .[]
    | select(any(.properties[]?; (.name|endswith("loc_code")) and .value==$code))
    | "\($file)\t\(.name)"' "$f"
done

The restricted entity check works the same way on manufacturer and supplier names, rerun whenever a list changes.

What gaps and criticisms does the framework itself acknowledge?

We focus on what the document states or shows, since that is what we could verify.

Part and entity resolution

Appendix D's longest item is naming. Suppliers use different nomenclature, which makes HBOMs hard to evaluate and hard to link to the matching SBOM. The framework borrows the framing of NTIA's 2021 paper on software identification and says hardware has the same problem in both directions: one generic product name covering many SKUs or part numbers, and one part written several ways, with and without dashes, or as a marketing name and a part number.

Company names vary too, and DUNS, SAM and CAGE identifiers do not cover every small or foreign maker. Acquisitions rebrand part numbers. Corporate structure matters as well: the framework uses Section 889's coverage of subsidiaries and affiliates to show that a restricted entity's equipment may be sold under another brand, and recommends checking every permutation.

Integrity, roles and operations

Future work includes how to convey and verify the provenance, pedigree and integrity of HBOMs. Today there is no signing or attestation guidance, so an HBOM is a supplier claim. The framework also leaves open who produces, shares and protects HBOMs, whether they are internal or public, whether they are for people or machines, what rights customers have to receive them, and which contract clauses are needed when suppliers do not provide them freely.

Format translation

Only some fields map to CycloneDX and SPDX, other formats were not evaluated, and the Department of Defense's Catalog Data Standard is named as unmapped. The authors suggest working with the CycloneDX, SPDX and Catalog Data Standard communities.

Inconsistencies we found while reading

These are small, but they bite anyone who writes code straight from the PDF.

On the hash point: a hash of a capacitor means nothing, a hash of a firmware image means a lot, and a unique SoC identifier is something else again. Settle which you want first.

For security teams the biggest gap is by design: no vulnerability or end of support fields, and firmware gets only a version and a provider. An HBOM alone cannot tell you whether a device is exposed, which is why our hardware and firmware inventory guide records firmware SBOMs alongside it.

How do procurement teams use the framework in practice?

1. Name the use case in the request. "An HBOM covering the compliance: government and security: geography and entity sub-categories of the CISA HBOM Framework" tells the supplier which categories you expect.
2. Fix fields and formats in a contract exhibit. List field names, ISO 3166-2 codes for locations, ISO 8601 dates, nesting depth, file format and, for CycloneDX, the version and property namespace.
3. Ask for nesting where it matters. For bought in radio, power and compute modules, ask for the sub-tier HBOM or at least the semiconductors with fab and assembly and test locations.
4. Set refresh triggers. The framework suggests a new HBOM when the product version changes. Add component substitutions and factory changes.
5. Pair it with a questionnaire and SBOMs, as Section 1.2 recommends.
6. Run acceptance checks for completeness, part numbers and entity names, and rerun screening whenever lists change.

Device makers on the other side can read our post on hardware and software in one bill of materials for IoT devices.

How does the HBOM framework relate to SBOMs and firmware?

The two connect through the part identifier, so naming must match. Our post on using SBOMs in incident response shows that lookup working, and motherboard evolution from chipsets to BIOS, UEFI, TPM and BMC covers which board parts carry their own firmware.

Where Safeguard fits, honestly

Safeguard does not generate HBOMs, does not collect hardware inventory, and does not scan firmware images or devices. Building an HBOM to the CISA taxonomy is work for your suppliers, your ERP or PLM data and your procurement process.

The overlap is the software half that the framework leaves out of scope. Safeguard analyses SBOMs in SPDX and CycloneDX and accepts SBOMs you upload, including firmware SBOMs from hardware vendors (safeguard scan --sbom vendor-firmware-sbom.json from the CLI). It matches declared components against vulnerability databases, shows which of your projects and products contain a given component and version, and accepts CSAF and VEX uploads so a vendor's "not affected" statement sits next to the finding. Its third party risk module can request SBOMs from suppliers and track responses, which pairs naturally with an HBOM request. All of it depends on the vendor declaring what is inside its firmware.

Common mistakes

• Asking for every field. The design is use case driven; a 47 field request signals no plan for the data.
• Treating the HBOM as proof of compliance. The framework says it is not.
• Accepting a one time attestation instead of data you can re-query when lists change.
• Collapsing OEM and manufacturer into one column.
• Stopping at the assembly when the facts sit inside a bought in module.
• Free text locations only. Ask for ISO 3166-2 codes.
• Mapping by SPDX clause number instead of field name.
• Filling hash fields with placeholders before agreeing what they mean.
• Expecting the HBOM to answer vulnerability questions. Request the firmware SBOM too.
• Never refreshing after product, component or factory changes.

FAQ

What is the CISA HBOM framework?

A voluntary framework published by CISA on 25 September 2023, written by the ICT SCRM Task Force's HBOM working group. It defines use cases, field categories, a field taxonomy and a nesting structure so vendors and purchasers can exchange consistent information about hardware components.

Is the CISA HBOM framework mandatory?

No. It is meant for voluntary, flexible use. It becomes binding only if a contract or another rule adopts it.

How many fields are in the CISA HBOM taxonomy?

The quick reference lists 47 fields in seven categories: 7 header, 3 finished good product details, 5 entity name, 15 entity location, 7 component part information, 3 component part details and 7 production details.

What are the HBOM use cases in the CISA framework?

Compliance, security and availability, split into eight sub-categories: government, industry or customer, and internal and quality compliance; geography and entity, and product and component security; world events, clustering for risk and clustering for optimisation.

Does the CISA HBOM framework cover firmware?

Only lightly. Version fields can hold firmware versions and it records the firmware provider, but SBOM information and firmware provenance are out of scope.

Can I write a CISA HBOM in CycloneDX or SPDX?

Yes, with custom fields. The framework defines no file format of its own. About ten fields have equivalents; the rest, including all location fields, need user defined properties. SPDX 3.0.1 has no hardware profile.

What is the difference between an HBOM and an SBOM?

An HBOM lists physical parts, makers, locations and supply facts. An SBOM lists software components, including those inside firmware. You usually need both, linked by part identifiers. See our HBOM vs SBOM explainer.

Does an HBOM help with Section 889 and the UFLPA?

It helps you check. Entity and location fields let you compare a product's supply chain against covered entities or regions. It does not prove compliance, and the framework recommends qualified legal advice.

Fix it without waiting for upstream

An HBOM tells you which chips and boards you bought, but the services, collectors and dashboards that store and query those HBOMs, and the firmware and management software on the devices themselves, are built from open source components that need patching like any other software. The fit with hardware is indirect: nothing below changes a chip or a supplier, but it keeps the open source code you build and ship around that hardware current.

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 tooling around an HBOM program, such as a converter that turns supplier spreadsheets into CycloneDX or the service that stores and queries 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 a procurement or product security workstation where you want to check a supplier's firmware SBOM, delivered alongside its HBOM, 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 named in a firmware advisory, as long as the vendor's SBOM is in your Safeguard inventory. The HBOM side of that question still lives in your own records.

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, ICT Supply Chain Risk Management Task Force
• CISA, ICT SCRM Task Force Vendor Template
• NTIA, Software Identification Challenges and Guidance (PDF)
• U.S. Customs and Border Protection, Uyghur Forced Labor Prevention Act
• FAR 52.204-25, Prohibition on Contracting for Certain Telecommunications and Video Surveillance Services or Equipment
• CycloneDX, Hardware Bill of Materials (HBOM) capability
• CycloneDX 1.6 JSON reference
• CycloneDX property taxonomy, cdx:device namespace
• SPDX 2.2.2, Package information
• SPDX 2.2.2, Document creation information
• SPDX 3.0.1, SoftwarePurpose vocabulary
• SPDX 3.0.1, ProfileIdentifierType vocabulary

Last reviewed: 23 October 2026.