Cryptographic Bill of Materials (CBOM) Specification

1. Introduction

1.1 Purpose and Scope

The Cryptographic Bill of Materials (CBOM) specification defines a standardized, machine-readable format for enumerating every cryptographic component deployed in a system — algorithms, protocols, keys, certificates, and their configurations. CBOM is to cryptographic dependencies what SBOM is to software dependencies.

CBOM provides the foundational visibility required for post-quantum migration planning, regulatory compliance auditing, and continuous cryptographic posture monitoring. As NIST's 2035 deadline for deprecating classical asymmetric cryptography approaches, organizations need a complete, accurate inventory of their cryptographic dependencies before they can plan migration.

In scope: Software crypto libraries, TLS/SSH/IPsec configurations, certificates and PKI, HSMs and hardware crypto, key management systems, algorithm negotiation, cloud KMS, and entropy sources.

Out of scope: Cryptanalysis, key material values (CBOM enumerates what crypto exists, never contains actual secrets), threat modeling, and algorithm selection guidance.

1.2 Relationship to Existing Standards

CycloneDX 1.6: The OWASP CycloneDX format includes a crypto extension in v1.6 via the cryptoProperties object. While useful, this models cryptographic information as an extension to software components — tied to SBOM lifecycle and software update cadences. CBOM provides a standalone format where cryptographic components are first-class entities.

SPDX: The Software Package Data Exchange (ISO/IEC 5962) provides software supply chain transparency but has no dedicated cryptographic extension. CBOM complements SPDX through cross-referencing.

NIST SP 800-227: Recommendations for Post-Quantum Cryptography Migration — CBOM provides the inventory format that makes SP 800-227's recommendations actionable.

CNSA 2.0: The NSA's Commercial National Security Algorithm Suite 2.0 defines algorithm transition timelines. CBOM tracks compliance against these timelines.

1.3 Rationale for a Standalone Format

CBOM exists as a standalone format rather than an SBOM extension for eight key reasons:

1. Different lifecycle cadence. Cryptographic components change independently of software updates. An OpenSSL upgrade changes the software BOM but may not change the crypto posture. A NIST deprecation announcement changes the crypto posture but doesn't change the software.
2. Different stakeholders. SBOMs serve software supply chain managers and developers. CBOM serves cryptographic architects, compliance officers, and post-quantum migration planners.
3. Infrastructure-layer coverage. Much cryptography lives outside software: HSMs, TPMs, network device configurations, certificate authorities, DNS (DNSSEC), email (S/MIME). A crypto BOM limited to SBOM scope misses critical exposure.
4. Protocol negotiation complexity. TLS cipher suite configuration involves ordered preference lists with runtime negotiation and fallback behavior. SBOM formats model static properties of static components.
5. Migration planning. Post-quantum migration requires knowing not just what crypto exists but: what replaces it, what effort is required, what dependencies must migrate first, and what the timeline pressure is.
6. Hybrid algorithm suites. The PQC migration period requires hybrid classical+PQC combinations that need first-class modeling.
7. Temporal analysis. Comparing crypto posture across time is a core CBOM use case not supported by SBOM formats.
8. Cross-referencing, not replacing. CBOM references SBOMs via explicit cross-reference fields. They're complementary layers.

2. Data Model

2.1 Document Metadata

Every CBOM document MUST include these top-level metadata fields:

2.2 Cryptographic Component Object

The Cryptographic Component is the primary entity in CBOM. Each component represents a single cryptographic algorithm, protocol binding, certificate, or key as deployed in the target system. Components carry identity, algorithm identification, implementation details, usage context, lifecycle status, quantum risk assessment, and compliance mapping.

Key field groups include:

• algorithm — name, standard, OID, family (SYMMETRIC_CIPHER, DIGITAL_SIGNATURE, KEY_ENCAPSULATION, HASH, etc.), variant
• parameters — keySize, blockSize, digestSize, curveName, parameterSet, mode, padding
• implementation — library, libraryVersion, language, FIPS validation details
• lifecycle — status (ACTIVE through DECOMMISSIONED), NIST status, deprecation dates, replacement references
• quantumRisk — vulnerable (boolean), migrationEffort, migrationPriority
• protocolBinding — protocol (TLS/SSH/IPSEC), version, cipher suite, negotiation mode
• keyManagement — creation/expiration dates, rotation schedule, storage type (HSM/TPM/CLOUD_KMS)
• certificateDetails — subject, issuer, validity dates, SANs, signature algorithm
• hybridConstruction — type (COMPOSITE/CONCATENATED/NESTED), component references
• complianceMapping — framework, requirement ID, compliance status
• provenance — discovery method, tool, confidence level

2.3 Cryptographic Dependency Graph

The dependencies field creates a directed graph of cryptographic relationships. For example, a TLS 1.3 session depends on an ECDHE key exchange component, an AES-256-GCM bulk cipher component, a SHA-384 hash component, and an X.509 certificate chain — each modeled as separate components with explicit dependency references.

3. Document Format

CBOM documents use JSON encoding with UTF-8. All field names use camelCase. The Content-Type is application/cbom+json and the file extension is .cbom.json.

{
  "specVersion": "1.0.0",
  "documentId": "550e8400-e29b-41d4-a716-446655440000",
  "timestamp": "2026-03-15T10:30:00Z",
  "producer": { "name": "cbom-scan", "toolVersion": "0.1.0" },
  "targetSystem": { "identifier": "sys-001", "name": "web-prod" },
  "components": [ ... ],
  "dependencies": [ ... ]
}

Vendor extensions use the x- prefix on field names. Extensions MUST NOT override standard fields. Tools MUST preserve unrecognized extension fields during processing.

4. Lifecycle Management

CBOM defines a formal lifecycle state machine for cryptographic components:

UNKNOWN → ACTIVE → DEPRECATED → MIGRATION_PLANNED
    → MIGRATION_IN_PROGRESS → REPLACED → DECOMMISSIONED

Each transition has defined trigger conditions mapped to NIST algorithm status changes and organizational policy decisions. The lifecycle model integrates with CNSA 2.0 timeline milestones: RSA disallowed after 2030, ECDH/ECDSA disallowed after 2035.

Temporal CBOM analysis enables comparing snapshots over time — detecting added/removed components, lifecycle status changes, and cryptographic drift.

5. Discovery and Population Methods

CBOM supports eight discovery methods, each with different coverage and confidence levels:

6. Use Cases

Primary use cases for CBOM include:

• Post-Quantum Migration Planning — Identify quantum-vulnerable components, prioritize by risk and effort, track migration progress
• Regulatory Compliance Auditing — FedRAMP SC-13, PCI-DSS 4.0 Requirement 4, CMMC Level 2
• Supply Chain Risk Assessment — Evaluate vendor cryptographic posture via CBOM
• Incident Response — Instantly query for all components affected by a newly published vulnerability
• M&A Due Diligence — Assess acquisition target's cryptographic debt and migration requirements
• Continuous Monitoring — Detect cryptographic drift between periodic scans
• Vendor Risk Management — Require vendors to provide CBOMs as part of procurement

7. Conformance

CBOM defines three conformance levels: