Many organizations are increasingly focusing on software supply chain security and the role of Bills of Materials (BOMs) in identifying and managing associated risks. However, not everyone is aware that there are different types of BOMs, each designed to address specific security and compliance requirements.

In this article, we'll explore these different types in detail, breaking down complex concepts into simple, easy-to-understand language. We'll cover what each BOM is, why it matters, how it is structured, the vulnerabilities it helps identify, and the mitigation strategies organizations can implement to strengthen their security posture.

Let's get started!

The table below provides an overview of the different types of Bills of Materials, what each one represents, and the key questions it helps organizations answer.

A bill of materials is an inventory, not a security certificate. It helps people ask better questions and act faster; it does not, by itself, prove that a product is safe or vulnerable.

1. Introduction A modern product is assembled from many parts. A web service may include an operating system, open-source libraries, application code and encryption software. A connected device may also include a circuit board, processor, memory chips, radio modules and firmware. To manage risk, teams need a reliable inventory of what is actually present.

A Bill of Materials (BOM) is that inventory. The three terms in this guide answer different questions: an SBOM describes software ingredients; a CBOM describes cryptographic ingredients and where they are used; and an HBOM describes physical hardware components and, depending on the purpose, their suppliers and provenance. CycloneDX supports a common data model spanning software, hardware and cryptographic assets, while SPDX is an international open standard widely used for software supply-chain information.

A useful mental model is three camera views of one product. They overlap, but none replaces the others. A device's firmware may be software listed in an SBOM; the flash chip containing it belongs in an HBOM; and the signing algorithm or device certificate used by that firmware belongs in a CBOM.

An inventory can be partial, out of date, or uncertain. Good practice is to state what was scanned, when it was scanned, how it was built, and what the tool could not see. A scanner's silence is not proof that a component or risk is absent.

2. Structure of SBOM vs CBOM vs HBOM

A. SBOM: the software ingredient list

An SBOM is a structured, often machine-readable list of software components associated with a product. It can include the product's name and version, the component name and version, supplier information, identifiers, relationships, and the tool or process that created the inventory. The word "nested" matters: an application can depend on a library that depends on other libraries. CISA describes an SBOM as an inventory of software components and notes that VEX can accompany it to say whether a product is actually affected by a reported vulnerability.

For example, a photo application might depend on an image library, which in turn depends on a compression library. The SBOM records the chain so teams can quickly find every product that includes a vulnerable version.

B. CBOM: the cryptography inventory

A CBOM is a map of cryptographic assets and how they relate to software or systems. It can describe algorithm families, cryptographic libraries, key and certificate material, and use relationships. The inventory should not expose secret private keys. In most cases, record safe metadata such as key type, size, location or reference, certificate fingerprint and owner — not the secret value itself. CycloneDX highlights its ability to represent algorithms, keys, certificates and relationships to software components.

Example: "The gateway's TLS service uses OpenSSL; the service presents certificate fingerprint X; the certificate uses an elliptic-curve signature; an older RSA-based client connection remains enabled." That is more useful for planning a cryptographic upgrade than simply knowing a crypto library is installed.

C. HBOM: the physical-parts inventory

An HBOM describes the hardware in a product or host. Depending on the use case, it may include the finished product, subassemblies, component names, part numbers, revisions, manufacturers, suppliers, quantities, locations and provenance. A router might contain a main board, a system-on-chip (SoC), memory, flash storage, a Wi-Fi module and sensors. CISA's HBOM framework groups its fields around the BOM header, entities and locations, finished-good details, component descriptions and technical/production details. It also emphasizes that the fields selected should depend on the intended use.

HBOM scope varies in practice. An inventory collected from a live computer may discover host hardware, while a manufacturer's engineering or procurement HBOM may go deeper into board-level parts, suppliers and manufacturing locations. Do not assume a host-scanner export is a complete manufacturing supply-chain record.

In this example, the board contains a processor and memory; the processor boots firmware and an operating system; software components use a TLS implementation; and the TLS implementation uses algorithms and a device certificate. Each inventory contributes different evidence. Join them using stable product names, versions, identifiers and relationships where possible.

3. Importance of the three inventories

The practical benefit is faster impact analysis. When a newly disclosed flaw affects a library, an SBOM helps answer "Which products include it?" When a cryptographic algorithm is deprecated or a certificate expires, a CBOM helps answer "Where is it used, and what depends on it?" When a supplier or hardware component is recalled, restricted, counterfeit, or unavailable, an HBOM helps answer "Which products contain it, and what is the replacement path?"

Inventories also improve routine operations: asset ownership, patch planning, software licensing, lifecycle decisions, supplier resilience and audit readiness. They are useful only when they are refreshed as products change and when there is a response process behind the data. A static BOM quickly becomes a historical snapshot.

4. Standards and tools

A format is not a scanner. CycloneDX or SPDX defines how to express information; a separate tool discovers, validates, enriches or analyzes that information. One product can publish both SPDX and CycloneDX exports if consumers need different formats, but avoid silently losing fields when converting between them.

5. How to perform SBOM vs CBOM vs HBOM using open-source tools

Use a representative, trusted project or device. Pin the product version, preserve the output and note the tool version, date, scope and any permissions required. Treat all commands below as illustrative; consult the tool's current installation instructions and run scans in a controlled environment.

A. Create and scan an SBOM

Syft can inventory a local project or container image and export CycloneDX or SPDX. For example:

Create a CycloneDX SBOM for a project directory

syft ./my-project -o cyclonedx-json=./sbom.cdx.json

Or inspect / export an image

syft alpine:latest -o spdx-json=./image.spdx.json

Then scan the generated SBOM with Grype, or scan it with Trivy. Grype supports SBOM input; Trivy documents both CycloneDX and SPDX input.

grype sbom:./sbom.cdx.json trivy sbom ./sbom.cdx.json

A beginner-friendly routine is: (1) build the exact release artifact, (2) generate the BOM from that artifact and its build evidence, (3) scan it, (4) check important findings against the upstream advisory and product context, (5) update or replace affected components, then (6) regenerate and rescan. For source-first scanning or guided fixes, OSV-Scanner can scan a repository recursively; review any automated change before merging.

B. Create a CBOM

For code-centric crypto discovery, cdxgen supports CBOM workflows, while CBOMkit provides source scanning, viewing and policy checks. Coverage differs by language and library. The CBOMkit project explicitly warns that scanning a repository without building it can reduce accuracy for some Java code; a build-aware pipeline can improve results.

cdxgen examples (check current CLI version and project-specific options)

cbom -t java -o cbom.json

Include source-derived crypto for a JavaScript / TypeScript project

cdxgen — include-crypto -o cbom.json /path/to/project

Dynamic trace around a test command, where supported

tracebom — cbom-output cbom-runtime.json — npm test

Review the output with a human who understands the application. Confirm that the inventory names where an algorithm is used, whether it is actually active, the certificate/key reference and ownership, and whether the observed configuration matches the deployed system. Never put secret key bytes, passwords, tokens or private certificate material in a shared BOM. Use a safe reference or fingerprint instead.

For a CBOM, "vulnerability scanning" is not just matching package versions. The important questions include whether algorithms are allowed, whether key sizes and certificate validity are appropriate, whether a crypto library has a security flaw, and where a cryptographic dependency sits in the system. A CBOM makes those checks more targeted; it does not perform them automatically.

C. Create an HBOM

For a live host, cdxgen offers a hardware-specific hbom command. The current guide lists supported host collectors and command options; installed utilities, operating system, processor architecture and privileges affect the result. By default, some sensitive identifiers are redacted.

Generate a host hardware BOM

hbom -o hbom.json

Ask the tool to validate its output, if supported by installed version

hbom -o hbom.json — validate

Collect a merged hardware + runtime host view (where supported)

hbom — include-runtime -o host-view.json

Inspect missing utilities / permission-sensitive collection

hbom diagnostics

For a product-level HBOM, gather and reconcile engineering BOMs, procurement/ERP data and supplier disclosures. Normalize manufacturer names and part numbers; record revision and quantity; connect components to parent assemblies; and mark unknown, substituted or unverified information. Ask suppliers for updates when a part or manufacturing location changes. CISA's framework explains that HBOM data requirements vary by use case and that component/supplier identity resolution can be difficult.

Protect serial numbers, MAC addresses, production locations and other sensitive supply-chain identifiers. Collect and distribute only the detail needed for the task, and restrict access where exposure could create privacy or security risk.

6. Vulnerabilities associated with SBOM vs CBOM vs HBOM

A BOM is primarily an inventory. Vulnerability tools compare that inventory with vulnerability information or policy. The risk categories differ by what each inventory can see:

Vulnerability databases and product naming are imperfect. An SBOM may list a package under a name that does not match an advisory. A CBOM may detect an algorithm in test code that is not present in production. An HBOM may use a rebranded part number or omit deeper subcomponents. Findings therefore need evidence and context before they become incident claims.

For software, tools such as Grype, Trivy and OSV-Scanner connect package identities to known advisories. For crypto, findings may come from algorithm-policy checks, certificate analysis, code review or vendor advisories. For hardware, teams often need manufacturer security notices, firmware bulletins and supplier data in addition to common vulnerability identifiers. Dependency-Track supports portfolio monitoring and multiple intelligence sources.

A scanner reporting "no findings" does not certify safety. It may mean the database has no matching advisory, the version could not be identified, a collector missed a component, the issue is not represented in that tool, or the inventory is incomplete. Always review scan coverage and data freshness.

7. Mitigation in SBOM vs CBOM vs HBOM

Mitigate software risks — SBOM

Start by checking whether the affected component and exact version are present in the deployed build. Confirm the advisory and fixed version. Upgrade or replace the component, rebuild the product, test compatibility, and regenerate the SBOM. If the code is not affected, or is not reachable in the product, document the evidence and communicate status using a VEX process where appropriate. Do not suppress a finding solely because it is inconvenient.

Mitigate cryptographic risks — CBOM

Prioritize exposed or prohibited algorithms, weak parameters, expired certificates and crypto libraries with relevant security fixes. Replace weak or obsolete mechanisms with approved alternatives; rotate or reissue keys/certificates when indicated; protect secrets in a key-management service; and design software so crypto providers and algorithms can be changed with limited disruption. For post-quantum migration, first discover where public-key algorithms and certificates are used, then test new standards in a controlled migration plan. NIST's migration work emphasizes discovery and a staged transition to post-quantum cryptography.

Mitigate hardware and supply-chain risks — HBOM

Confirm the exact component revision, manufacturer and affected product range with the vendor. Apply firmware updates or configuration changes; replace or isolate affected components when updates are unavailable; and plan alternate suppliers or parts for availability risks. Validate substitutions and provenance when receiving parts. Where the root cause is uncertain, preserve evidence and coordinate with the manufacturer rather than asserting a defect based only on a similar part name.

Triage before action

A sound triage decision combines four questions: (1) Is the component really present? (2) Is the vulnerable feature enabled or reachable? (3) What exposure and business impact follow? (4) What is the safest fix or compensating control? Record the owner, decision, evidence, due date and next review. Use temporary isolation, feature disablement, access limits or monitoring when immediate patching is not feasible, and set an expiry date for temporary controls.

8. Best practices

· Generate from the released artifact, not only from a developer's machine. Keep build and scan steps reproducible, and match each BOM to a product name, version and release.

· Automate updates in CI/CD and at major product changes. Refresh inventories when dependencies, firmware, hardware revisions, certificates or runtime configuration change.

· State scope and completeness honestly. Identify the scan method, timestamp, tool version, target, known blind spots and whether the BOM is complete, partial or unknown.

· Use stable identifiers and explicit relationships. Include versions, suppliers and hashes where practical; for hardware, normalize part numbers and revisions. Record where the evidence came from.

· Protect sensitive data. Do not publish private keys or secrets. Review serials, MAC addresses, supplier locations, internal package names and exploit details before sharing.

· Validate structure and quality. Check schema conformance, duplicate or ambiguous components, missing versions, unresolved dependencies and unexpected empty inventories.

· Keep BOMs linked to vulnerability response. Assign finding owners, prioritize based on exposure and impact, track fixes to closure, and add VEX or equivalent status with evidence when findings are not applicable.

· Maintain an authoritative source and history. Store versioned files with access controls, retention rules and integrity evidence; avoid multiple untracked "latest" copies.

· Combine supplier evidence with internal discovery. A product SBOM or host HBOM cannot reveal every upstream production fact. Request supplier details and record confidence and provenance.

· Treat tools as evidence generators, not oracles. Review supported ecosystems, freshness of vulnerability feeds, detection limitations and permission boundaries before relying on results.

· Plan for change. Assign clear ownership across engineering, security, procurement and operations; define the response path for a vulnerable library, unsafe crypto, hardware recall or supplier interruption

A. Quick comparison and glossary

The Key takeaway: By understanding and maintaining these Bills of Materials, organizations can improve visibility, identify vulnerabilities, manage supply chain risks, and make more informed security decisions.

In today's evolving threat landscape, adopting the right combination of BOMs is no longer just a good security practice — it's an important step toward building a more resilient and secure ecosystem