# CBOM: The Cryptographic Bill of Materials Standard **Source**: https://quantumsequrity.com/blog/cbom-crypto-bill-of-materials **Category**: Operations --- [← Back to Blog](../../blog.html) Operations # CBOM: The Cryptographic Bill of Materials Standard 11 min read The software industry has spent the better part of a decade getting comfortable with the Software Bill of Materials, or SBOM. The format is now familiar: an SPDX or CycloneDX document that lists every component of a software product, its version, its license, its known vulnerabilities. SBOMs are mandated by U.S. Executive Order 14028 for software sold to the federal government, and the format has become the lingua franca of supply-chain transparency. But an SBOM does not tell you what cryptography a piece of software uses. It tells you which libraries are linked. The cryptographic primitives buried inside those libraries, the parameters chosen at runtime, the certificates trusted by default, the random number generators used: all of that is invisible at the SBOM layer. The Cryptographic Bill of Materials, or CBOM, is the missing piece. This article explains what CBOM is, why CycloneDX 1.6 added it, how it relates to NIST and CISA guidance, and how to start producing one for your own software today. ## Why CBOM Exists Cryptographic discovery is the first step in any post-quantum migration. NIST SP 1800-38, CISA's PQCI roadmap, and the U.S. Office of Management and Budget's Memorandum M-23-02 all explicitly call out the need for organizations to inventory their cryptography. The output of that inventory needs to live somewhere. It needs to be machine-readable, vendor-neutral, and shareable across organizations and tools. Before CBOM, the answer was a spreadsheet. Each organization built its own format, often manually. The output could not be exchanged between tools. A vendor could not give a customer a clean cryptographic disclosure. A purchaser could not aggregate cryptographic posture across hundreds of suppliers. CBOM fixes this. It defines a structured format for cryptographic assets, embedded in CycloneDX, the industry-standard SBOM format from OWASP. ## CycloneDX 1.6 and the CBOM Extension CycloneDX is an open-source SBOM standard maintained under the OWASP Foundation. Version 1.6, released in mid-2024, introduced first-class support for cryptographic asset documentation. The relevant additions: - A `cryptoProperties` field on components, capturing things like algorithm family, parameter set, key size, and lifecycle metadata. - New asset types including `algorithm`, `certificate`, `protocol`, `related-crypto-material`, `cryptographic-asset`. - Schema fields for protocol negotiation parameters (TLS cipher suites, IKE proposals). - Hooks for declaring NIST FIPS validation status. The CBOM extension is a strict superset of CycloneDX. A CBOM document is also a valid SBOM. You can ingest it into any tool that already speaks CycloneDX, and the cryptographic fields are simply additional metadata. The full schema lives at the CycloneDX project on GitHub and is referenced in the OWASP CycloneDX documentation site. ## What a CBOM Captures A complete CBOM entry for a single cryptographic asset includes: - **Asset type**: algorithm, certificate, protocol, key, related-crypto-material - **Identifier**: a unique reference (component PURL, certificate fingerprint, etc.) - **Algorithm family**: AES, RSA, ECDSA, ML-KEM, etc. - **Parameter set**: AES-256-GCM, RSA-2048, P-256, ML-KEM-768 - **Implementation**: the library or hardware module providing the implementation - **NIST validation status**: FIPS 140-3 certificate number, validation status - **Cryptoperiod**: originator usage period, recipient usage period - **Lifecycle**: current state (active, deprecated, retired) - **Compliance mappings**: CNSA 2.0, NIST SP 800-131A, FIPS 140-3 - **Quantum readiness**: quantum-resistant flag, hybrid construction notes For example, a CBOM entry for an ML-KEM-768 implementation might look like (CycloneDX JSON, abbreviated): ```json { "type": "cryptographic-asset", "name": "ML-KEM-768", "cryptoProperties": { "assetType": "algorithm", "algorithmProperties": { "primitive": "kem", "parameterSetIdentifier": "ML-KEM-768", "executionEnvironment": "software-plain-ram", "implementationPlatform": "x86_64", "certificationLevel": ["fips140-3"], "cryptoFunctions": ["encapsulate", "decapsulate"], "nistQuantumSecurityLevel": 3 }, "oid": "2.16.840.1.101.3.4.4.2" } } ``` This is structured, parseable, and tool-agnostic. A consumer can filter for "all NIST-quantum-security-level-3 KEMs" or "all algorithms with quantum readiness false" and get answers. ## CBOM and SPDX SPDX is the other major SBOM format, maintained under the Linux Foundation. As of SPDX 3.0 (released 2024), there is preliminary support for cryptographic descriptions but the depth is less than CycloneDX 1.6 CBOM. SPDX 3.0 introduced "profiles" including a Security profile that can carry some cryptographic data, but the schema is less prescriptive. The pragmatic answer is: if you produce CBOM today, use CycloneDX 1.6. If you have an SPDX-only pipeline, generate CycloneDX in parallel for cryptographic disclosures, or wait for SPDX to mature. Many organizations now produce both formats automatically. ## CBOM and NIST IR 8547 NIST Internal Report 8547 (Transition to Post-Quantum Cryptography Standards), still in draft as of late 2024, references the use of cryptographic inventories and explicitly mentions CBOM as one mechanism for representing them. The document outlines a phased transition timeline: - 2024: NIST FIPS 203, 204, 205 published - 2024 to 2030: Hybrid deployment phase - By 2030: Phase out RSA-2048, RSA-3072, ECDH/ECDSA P-256, P-384 for new deployments - By 2035: Phase out for all deployments The transition timeline implicitly assumes organizations have an inventory. Without an inventory, "phase out" is impossible to plan, execute, or audit. CBOM is the format in which that inventory should live. ## Generating a CBOM There are several ways to generate a CBOM today: **Tool-driven generation**: - **CryptoBOM Forge** (IBM Research, open source). Scans Java, Python, and C/C++ projects and emits CycloneDX CBOM. - **cdxgen** (CycloneDX project). General SBOM tool with growing CBOM support. - **Trivy** (Aqua Security). Generates SBOMs and is adding CBOM features. - **Sandbox AQ Cryptosense**. Commercial; CBOM is part of the output. **Manual or semi-manual**: - Write a custom Semgrep ruleset that emits a CBOM file. Useful for organizations with codebases that the off-the-shelf tools do not handle well. - Hand-craft a CBOM from a spreadsheet inventory. Tedious but works for small estates. **Vendor-supplied**: - Some software vendors are starting to ship CBOMs alongside their products. As of 2026, this is still rare in commercial software but increasingly common in open-source projects on GitHub. ## CBOM Workflow in Practice A practical CBOM workflow looks like: 1. **Initial generation**: Run your chosen scanner against your codebase, container images, and binaries. Capture the output as a baseline CBOM. 2. **Manual augmentation**: Add fields the scanner did not detect: cryptoperiods, owners, compliance mappings. 3. **Continuous integration**: Wire the scanner into CI. On every merge to main, re-generate the CBOM and check for changes. 4. **Diff review**: New cryptographic assets (or new parameter sets) appearing in the CBOM diff trigger review. This is similar to dependency review for new library imports. 5. **Compliance reporting**: Filter the CBOM for fields like FIPS validation status, quantum readiness, and NIST security level. Export as a compliance document. 6. **Vendor exchange**: Ship the CBOM to customers who request it. Receive CBOMs from vendors as part of procurement. The output is a living document, not a one-shot artifact. ## Common CBOM Patterns Organizations deploying CBOM for the first time tend to follow similar patterns: **Pattern 1: Inventory-only.** First few quarters are about getting a complete picture. The CBOM is read but not enforced. **Pattern 2: Risk-classification overlay.** Once the CBOM is stable, each entry is tagged with a risk level (low, medium, high) based on quantum readiness, FIPS validation, and confidentiality lifetime. This produces a prioritized migration list. **Pattern 3: Policy enforcement.** Higher maturity. The CI pipeline blocks merges that introduce cryptographic primitives below a defined policy floor. For example, a policy might say "no new RSA-1024, no new SHA-1, no new TLS 1.0." **Pattern 4: Customer-facing disclosure.** The CBOM is published or shared on request. A few enterprise software vendors are doing this in 2026, more will follow as customers ask. ## CBOM and the QNSQY File Format QNSQY's `.qs` files have an internal version field that captures which algorithm parameters were used. When you generate a CBOM for a system that uses QNSQY, the entries reflect the algorithms QNSQY uses by default: - ML-KEM-768 + X25519 hybrid (key wrapping) - ML-DSA-65 + Ed25519 hybrid (signing) - AES-256-GCM (bulk encryption) - HKDF-SHA-256 (key derivation) - Argon2id (password derivation) - BLAKE3 (general-purpose hashing) Each of these has an OID (object identifier) defined in NIST or IETF documents and can be cleanly represented as a CBOM entry. The OIDs for the NIST-standardized PQC algorithms were added to NIST's IR 8528 and are tracked in the NIST CSRC website. ## Limitations and Open Questions CBOM is not magic. Some real limitations: **Runtime configuration is hard to capture statically.** A library that supports ML-KEM-512, ML-KEM-768, and ML-KEM-1024 will have all three in the CBOM. Which one is actually used at runtime depends on configuration. A complete picture requires runtime instrumentation, not just static analysis. **Negotiated protocols are dynamic.** TLS cipher suite selection happens at handshake time. A CBOM can list the supported suites but cannot predict the actual negotiated suite without observation. **Hardware module abstraction varies.** An HSM is a black box from the software side. The CBOM can record "this HSM is FIPS 140-3 certificate #1234" but not enumerate the algorithms inside. **Schema evolution.** The CBOM schema will continue to evolve as PQC matures. CycloneDX 1.6 is the current version. Organizations should plan for occasional schema migrations. ## CBOM and Vendor Procurement CBOM is starting to appear as a contractual requirement in enterprise procurement. Several large U.S. federal procurements in 2025 included a clause requiring vendors to deliver a CycloneDX 1.6 CBOM at the same cadence as the SBOM. Healthcare procurement is following: HIPAA-regulated entities increasingly ask suppliers to disclose cryptographic posture as part of business associate agreements. A typical procurement clause now reads: the vendor shall deliver a CBOM in CycloneDX 1.6 format covering all cryptographic primitives used in the product, including algorithm family, parameter set, FIPS 140-3 validation status, and quantum-resistance classification. The CBOM shall be regenerated on every minor release and made available to the purchaser within seven calendar days of release. For software vendors, this means the CBOM cannot be a one-time deliverable. It must be part of the build pipeline. The cost of producing a CBOM on demand is much higher than producing one continuously, and the discrepancy compounds with every release. QNSQY publishes its own CBOM at quantumsequrity.com/cbom and updates it on every release. This is the pattern enterprise customers are starting to expect from any cryptographic vendor. ## Integrating CBOM with Vulnerability Management A CBOM is most valuable when it can be queried alongside the vulnerability databases. Several integrations are starting to mature in 2026. The OWASP Dependency-Track project (the same maintainers as CycloneDX) ingests CBOMs and joins them against the National Vulnerability Database, the OSV.dev feed, and the GitHub Advisory Database. When a CVE is filed against a specific algorithm or library version, every product in the CBOM database that depends on that version is flagged automatically. This is similar to how SBOM-driven vuln scanning works today, but extended to algorithm-level findings. CISA's KEV (Known Exploited Vulnerabilities) catalog now includes a small but growing set of cryptographic CVEs. A CBOM that maps cleanly to KEV entries lets a CISO answer the question: "are we exposed to any actively exploited cryptographic vulnerability today?" That answer is hard to produce from spreadsheets but trivial from a CBOM-backed query. ## Frequently Asked Questions **Is CBOM required by any regulation today?** Not directly, but the underlying activity is. U.S. OMB Memorandum M-23-02 requires federal agencies to maintain a PQC migration inventory. CISA's PQCI guidance and NIST SP 1800-38 reference CBOM as the format for that inventory. Several large enterprise procurements now require a CBOM as a deliverable. **Where can I get the CBOM schema?** CycloneDX 1.6 schema is at https://cyclonedx.org/schema/ and the corresponding GitHub repository. **Do I need a separate CBOM and SBOM, or one combined?** Combined. CBOM is an extension of CycloneDX SBOM. A single CycloneDX 1.6 file can include both software components and cryptographic assets. **How does CBOM handle proprietary algorithms?** CycloneDX allows custom algorithm identifiers and OIDs. A proprietary algorithm can be documented with a vendor-specific identifier, though interoperability suffers. **Will CBOM eventually be machine-actionable?** That is the goal. With a stable CBOM, tooling can automatically detect "all consumers of RSA-2048" and trigger migration tasks. We are seeing the first integrations with vulnerability management platforms in 2026. **How does CBOM differ from a software composition analysis report?** SCA reports list libraries and versions. CBOM lists cryptographic primitives, their parameters, and their lifecycle metadata. The two answer different questions. SCA tells you which libraries are present. CBOM tells you which cryptographic operations they perform. **Can I publish a CBOM publicly without revealing security-sensitive details?** Yes. The CBOM lists algorithms and parameter sets, not keys or implementation details. Publishing a CBOM is similar to publishing a security policy: it tells customers what cryptography you use without leaking secrets. Many vendors now publish CBOMs alongside their security.txt and PGP keys. ## Sources 1. CycloneDX 1.6 Specification — https://cyclonedx.org/specification/overview/ 2. CycloneDX CBOM Capability Page — https://cyclonedx.org/capabilities/cbom/ 3. NIST IR 8547 (Transition to Post-Quantum Cryptography Standards), Initial Public Draft — https://csrc.nist.gov/pubs/ir/8547/ipd 4. NIST SP 1800-38 (Migration to Post-Quantum Cryptography) — https://www.nccoe.nist.gov/crypto-agility-considerations-migrating-post-quantum-cryptographic-algorithms 5. OWASP CycloneDX Project — https://owasp.org/www-project-cyclonedx/ 6. CISA SBOM Resources — https://www.cisa.gov/sbom 7. OWASP Dependency-Track — https://dependencytrack.org/ 8. CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog ## Related Articles - [Cryptographic Inventory Tools 2026 Survey](crypto-inventory-tools.md) - [How to Inventory Cryptographic Assets](how-to-inventory-cryptographic-assets.md) - [Crypto-Agility Explained](crypto-agility-explained.md) - [NIST FIPS Guide for Post-Quantum Cryptography](nist-fips-guide.md) - [PQC Migration Budget Planning](pqc-migration-budget-planning.md) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)