Draft:Cryptographic bill of materials

Cryptographic bill of materials (CBOM—also cryptography bill of materials) is a structured inventory of all cryptographic assets present in a software, firmware, device, or system. It enumerates algorithms (and parameters such as key sizes and modes), cryptographic libraries or modules, digital certificates, keys and related material, and protocols in use, and maps their relationships to the components that implement or invoke them. CBOMs are used to improve security analysis, compliance, and cryptographic agility, and are increasingly referenced in guidance for post‑quantum cryptography (PQC) migration.

For the broader inventory of software components, see Software bill of materials.

Definition and scope

A CBOM inventories cryptographic primitives and materials—such as encryption and signature algorithms (with specific variants and modes), key sizes, cryptographic libraries/modules, digital certificates (e.g., X.509), keys and other related cryptographic material, and security protocols (e.g., TLS, IPsec). It also documents dependencies (for example, an application uses an algorithm provided by a library; a protocol uses several algorithms) and can capture certificate lifecycles, cryptographic module certifications (e.g., FIPS 140‑3), and policy conformance metadata. In common practice, a CBOM may be embedded within an SBOM format (such as CycloneDX) or exported as a separate, linked artifact.

Typical CBOM fields

The exact schema varies by implementation, but common fields are summarized below (see CycloneDX CBOM guide and NIST SP 1800‑38B).

Examples of CBOM fields

Field	Examples / values	Notes (illustrative)
Algorithm	AES‑128‑GCM; RSA‑2048; ECDSA‑P‑256; SHA‑256	Include variant/mode; identify quantum‑vulnerable algorithms (e.g., RSA/ECC)
Parameters	Key length (e.g., 256‑bit), mode (GCM/CTR), padding (PSS/PKCS#1 v1.5)	Captures configuration‑level risk or policy violations
Library / module	OpenSSL 3.0.x; BoringSSL; wolfCrypt; platform HSM/KMS module	May include module certification (e.g., FIPS 140‑3)
Protocol / cipher suite	TLS 1.3 (TLS_AES_256_GCM_SHA384); SSH (curve25519‑sha256)	Maps protocol to underlying algorithms (KEX, AEAD, PRF, sig)
Certificates	X.509 leaf/intermediate/root; issuer/subject; validity dates; SANs	Supports PKI hygiene (expiration, chain, key‑use constraints)
Keys and related material	Key type (RSA/ECC/symmetric); size; storage (HSM/TPM/file); rotation policy	Sensitive details are typically referenced, not exposed in clear
Dependency relation	uses/implements relationships (app → library → algorithm)	Expresses how cryptography is provided and consumed
Location / scope	Component, service, host, firmware bundle, or container image	Enables search/impact analysis and remediation planning
Policy / status metadata	Approved / deprecated / disallowed; exception or waiver references	Supports compliance reporting and crypto‑agility workflows

Relation to SBOM

A CBOM is complementary to, but distinct from, a software bill of materials (SBOM). Whereas an SBOM lists software components and their versions, a CBOM focuses specifically on the cryptography present and how it is configured and used. For example, an SBOM might enumerate inclusion of a library such as OpenSSL, while the CBOM would identify which algorithms and parameters that library enables (e.g., RSA‑2048, ECDH P‑256, AES‑GCM) and list relevant keys and certificates. The pairing enables both supply‑chain transparency and cryptographic transparency.

History

The term and practice emerged in the early–mid 2020s alongside software‑supply‑chain transparency and PQC planning. The OWASP CycloneDX standard introduced native CBOM support (v1.6 and later), modeling algorithms, keys, certificates, and protocols as first‑class “cryptographic assets” and providing dependency semantics (uses/implements) between software and cryptography. Open tooling from industry and researchers (e.g., IBM’s CBOMkit and related generators/viewers) appeared to automate discovery and representation of cryptographic use in the CycloneDX CBOM schema.

Regulatory and policy context

In the United States, policy has emphasized cryptographic inventories as a prerequisite to PQC migration. The White House’s National Security Memorandum 10 (2022) directed a government‑wide transition to quantum‑resistant cryptography; the Office of Management and Budget’s M‑23‑02 (November 2022) operationalized this by requiring agencies to submit a prioritized inventory of cryptographic systems (with algorithm and key details) by 4 May 2023 and annually thereafter, and tasked CISA/NSA/NIST to develop automated discovery and inventory strategies. A 2024 Office of the National Cyber Director report reiterated that a “comprehensive cryptographic inventory” is the baseline for PQC planning and must be maintained iteratively with both automated and manual discovery. NIST’s NCCoE practice guide (SP 1800‑38B, preliminary draft) provides concrete methods for cryptographic discovery and documentation across enterprises, aligning with CBOM‑style representations. CISA later published a strategy to migrate federal agencies to automated cryptography discovery and inventory tools to support continuous reporting. Separately, NSA, CISA, and NIST issued joint guidance encouraging all organisations to prepare cryptographic inventories and roadmaps for PQC, beyond government environments.

Role in quantum readiness and cryptographic agility

Because large‑scale quantum computing threatens widely used public‑key algorithms (e.g., RSA, ECC), organisations are planning multi‑year transitions to post-quantum cryptography. CBOMs enable that planning by identifying where quantum‑vulnerable algorithms appear, prioritising high‑impact systems, and tracking replacements over time. A machine‑readable CBOM also supports cryptographic agility and incident response: if an algorithm, library, or certificate lifecycle becomes non‑compliant or vulnerable, the CBOM indicates which products and systems are affected and where mitigations must be applied first.

Standards and tooling

• CycloneDX (OWASP): Native CBOM modelling (v1.6+) for algorithms, certificates, keys/related material, and protocols, with dependency semantics and examples. The project publishes a CBOM guide and use‑case profiles (e.g., certificate and algorithm inventories).
• NIST NCCoE SP 1800‑38 series: Practice guides for PQC migration include enterprise cryptographic discovery methods that produce CBOM‑like inventories and integrate multiple discovery tools.
• Government automation initiatives: Following M‑23‑02, CISA issued a strategy to migrate to automated cryptography discovery and inventory tools to support agency reporting and continuous inventory management.
• Open‑source and vendor tools: IBM’s CBOMkit and related components generate, analyse, and visualise CBOMs; the IBM CBOM specification work was upstreamed into CycloneDX 1.6.

Data model and interchange (example)

CycloneDX provides machine‑readable encodings (JSON/XML) for CBOM content. The example below (subset) shows an application depending on a crypto library that provides the AES‑256‑GCM algorithm, and the application also depends on a leaf X.509 certificate. See the CycloneDX CBOM guide, JSON reference, and the “Implementation details” use‑case for the semantics of `dependsOn` and `provides`.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:12345678-90ab-cdef-1234-567890abcdef",
  "version": 1,
  "metadata": {
    "timestamp": "2025-01-01T12:00:00Z",
    "component": { "bom-ref": "app:inventory", "type": "application",
                   "name": "Inventory Service", "version": "2.3.1" }
  },
  "components": [
    { "bom-ref": "lib:openssl@3.0.13", "type": "library",
      "name": "OpenSSL", "version": "3.0.13" },

    { "name": "AES-256-GCM",
      "type": "cryptographic-asset",
      "bom-ref": "crypto/algorithm/aes-256-gcm@2.16.840.1.101.3.4.1.46",
      "cryptoProperties": {
        "assetType": "algorithm",
        "algorithmProperties": {
          "primitive": "ae", "mode": "gcm", "parameterSetIdentifier": "256",
          "cryptoFunctions": ["encrypt","decrypt"]
        },
        "oid": "2.16.840.1.101.3.4.1.46"
      }
    },

    { "name": "www.example.com",
      "type": "cryptographic-asset",
      "bom-ref": "crypto/cert/www.example.com@sha256:abcdef...",
      "cryptoProperties": {
        "assetType": "certificate",
        "certificateProperties": {
          "subjectName": "CN=www.example.com",
          "issuerName": "C=US, O=Example Trust, CN=ET CA 1",
          "notValidBefore": "2024-09-01T00:00:00Z",
          "notValidAfter":  "2026-09-01T00:00:00Z"
        }
      }
    }
  ],
  "dependencies": [
    { "ref": "app:inventory",
      "dependsOn": ["lib:openssl@3.0.13", "crypto/cert/www.example.com@sha256:abcdef..."] },
    { "ref": "lib:openssl@3.0.13",
      "provides": ["crypto/algorithm/aes-256-gcm@2.16.840.1.101.3.4.1.46"] }
  ]
}

Relationship to cybersecurity supply chain initiatives

CBOMs complement SBOM‑focused supply‑chain transparency introduced by U.S. Executive Order 14028 and NTIA/NIST SBOM work. SBOMs document software components; CBOMs add detail on embedded cryptography to support risk management, policy compliance (e.g., disallowing deprecated algorithms), and PQC transition planning.

See also

• Software bill of materials
• Cryptographic agility
• Post-quantum cryptography
• Public-key cryptography
• Public key infrastructure