What Is a CBOM? Cryptographic Bill of Materials Guide

Summary

“A Cryptographic Bill of Materials (CBOM) is a structured, machine‑readable inventory of all the cryptographic assets inside an application or system – algorithms, key pairs, certificates, crypto libraries, protocols and the components that use them. ”

What is a Cryptographic Bill of Materials (CBOM)?

A Cryptographic Bill of Materials (CBOM) – sometimes called a cryptography bill of materials – is a standardized way to describe all cryptographic assets and their relationships across your software estate.

At a minimum, a CBOM typically links to SBOM components and captures:

• Usage context (which services, code paths, endpoints or containers rely on which crypto assets)
• Crypto libraries and modules (for example, OpenSSL, BoringSSL, Bouncy Castle)
• Algorithms and modes in use (AES‑GCM, ChaCha20‑Poly1305, RSA‑PSS, ECDSA, SHA‑256, etc.)
• Protocols and versions (TLS 1.2 vs 1.3, SSH, IPsec, QUIC)
• Keys and secrets metadata (key length, key type, location/HSM reference, rotation policy – not raw keys)
• Certificates and trust anchors (issuers, SANs, expiration, key usage)

While some sectors (like medical devices) still use “cybersecurity bill of materials” to describe a broader security inventory, the emerging standard usage of CBOM in the AppSec and software supply chain community is firmly cryptographic.

Why CBOM matters for AppSec and Devs

For developers and AppSec teams, CBOMs turn “invisible crypto” into something you can reason about, test and automate around.

Cryptographic vulnerability management

• Quickly find weak or deprecated algorithms (e.g., RSA‑1024, SHA‑1, CBC‑only cipher suites).
• Spot misconfigurations like TLS 1.0/1.1 still enabled, missing certificate pinning, or non‑FIPS‑approved algorithms in regulated environments.
• Combine CBOM with reachability and runtime usage to prioritize what’s actually exploitable.

Post‑quantum and crypto agility

• Before you can migrate to post‑quantum cryptography (PQC), you need an accurate map of where classical cryptography is used. CBOM is that map.
• A CBOM lets you scope PQC pilots (e.g., “all services using RSA‑2048 certificates issued by CA X”) and track the rollout over time.

Compliance and audit readiness

• Many regulatory and industry frameworks already require strong crypto, key management, and certificate hygiene.
• A CBOM gives auditors a structured artifact that shows which crypto you use, where, and how it’s governed – paired with your SBOM and software supply chain security controls.

Incident response and threat hunting

• When a new protocol‑level bug or library vulnerability drops, you can query the CBOM: “Which services depend on vulnerable TLS cipher suites or this version of OpenSSL?”
• That shortens the time from “new crypto issue announced” to “we know exactly where we’re exposed”.

Developer guardrails

• CBOM data can feed policies in CI/CD that block builds when new code introduces disallowed algorithms or informal “shadow crypto” libraries.
• Combined with Software Composition Analysis (SCA), it helps enforce secure crypto defaults alongside dependency hygiene.

What Does a CBOM Include?

A CBOM builds on your SBOM (the list of components) and enriches it with crypto‑specific metadata. Practically, a CBOM usually includes:

• Component inventory (from SBOM)
  • componentRef or package URL (purl)
  • Version, hash, provenance
  • Link back to your SBOM entry
    (See the Checkmarx glossary entry “What is an SBOM?” and the SBOM knowledge hub article for context.)
• Cryptographic assets
  • Crypto libraries/modules (OpenSSL, BoringSSL, Bouncy Castle, OS crypto APIs)
  • Algorithms and modes (AES‑256‑GCM, RSA‑3072, ECDH‑P256, SHA‑384, HKDF, etc.)
  • Protocols and versions (TLS 1.2/1.3, SSH, IPsec profiles, VPN suites)
  • Credentials & key material metadata (key IDs, type, length, storage reference, rotation rules)
  • Certificates and CA chains (issuers, serials, expiry dates, keyUsage, extendedKeyUsage)
• Usage and exploitability context
  • Code‑level references (file/function where crypto is invoked)
  • Service/endpoints that rely on each crypto asset
  • Runtime usage (observed in production vs only in fallback paths)
  • Reachability / call graphs to crypto functions, aligned with what your SCA and ASPM tooling already calculates.
• Risk and control metadata
  • Known vulnerabilities in crypto libraries or protocols (CVEs/CWEs, CVSS/EPSS where available)
  • Policy violations (e.g., non‑approved algorithms, key lengths below policy)
  • Mappings to compensating controls (e.g., WAF rules, mTLS enforcement, HSM usage)
  • Recommended fixes (upgrade paths, configuration changes, alternative algorithms)

Plus, the CBOM provides a risk-centric inventory of security-relevant elements, including hardware, firmware, configurations, cryptographic algorithms, security controls and known vulnerabilities. It aims to give organizations a clearer picture of their cybersecurity posture by mapping out potential attack vectors, outdated security measures and misconfigurations that could be exploited by threat actors.

CBOM Example (illustrative JSON only):

{
  "componentRef": "pkg:maven/com.example/[email protected]",
  "cryptoAssets": [
    {
      "id": "frontend-tls",
      "type": "protocol",
      "protocol": "TLS",
      "version": "1.2",
      "libraries": ["OpenSSL 1.1.1w"],
      "algorithms": ["RSA-2048", "AES-128-GCM", "SHA256"],
      "certificates": [
        {
          "id": "cert-frontend-2025",
          "issuer": "Let's Encrypt",
          "notBefore": "2024-06-01T00:00:00Z",
          "notAfter": "2025-06-01T00:00:00Z",
          "keyType": "RSA",
          "keySize": 2048
        }
      ],
      "keys": [
        {
          "id": "k8s-secret/payment-tls-key",
          "store": "kubernetes",
          "rotationPolicy": "365d"
        }
      ]
    },
    {
      "id": "token-signing",
      "type": "signature",
      "algorithms": ["ES256"],
      "library": "Nimbus JOSE + JWT",
      "usage": ["OIDC_ID_TOKEN", "OIDC_ACCESS_TOKEN"]
    }
  ],
  "vulnerabilities": [
    {
      "id": "CVE-2024-XXXX",
      "affects": ["OpenSSL 1.1.1w"],
      "severity": "HIGH",
      "reachable": true
    }
  ],
  "policies": [
    {
      "rule": "min_rsa_key_size",
      "status": "violation",
      "details": "RSA-2048 in use; organization baseline is RSA-3072 or higher."
    }
  ]
}

This is not a formal schema, but it illustrates how CBOMs tie component identities (from SBOM) to crypto libraries, algorithms, keys and certificates, plus risk metadata.

CBOM vs. SBOM vs. “Cybersecurity Bill of Materials”

For AppSec teams, the most practical pattern is: SBOM for components, CBOM for crypto, plus broader software supply chain security (SSCS) for the full risk picture.

Checkmarx Feature Highlight

Generate SBOMs Automatically

The US Federal Government mandates that any organizations working with US Federal government must be able to provide an SBOMs. Save time and headache ensuring you have an up-to-date inventory of 3rd party packages being used within your software projects with Checkmarx SCA

SBOM

CBOM in ASPM: best practices for developers & AppSec

To make CBOMs actually useful (and not just another artifact), treat them as part of your Application Security Posture Management (ASPM) and SDLC:

1. Start from a solid SBOM
   • Use tooling (like Checkmarx SCA and SBOM capabilities) to generate accurate SBOMs for each service in standard formats (CycloneDX or SPDX).
   • SBOM becomes the backbone your CBOM references.
2. Automate CBOM generation in CI/CD
   • Scan source code, containers, and infrastructure definitions for crypto libraries and configurations.
   • Generate or update CBOMs on every build so they stay aligned with your supply chain security posture.
3. Connect CBOM data to reachability and runtime
   • Combine CBOM fields with code‑level reachability and runtime telemetry to prioritize the cryptographic issues that are actually exploitable in production.
4. Policy‑driven enforcement
   • Use CBOM data to express guardrails such as:
     • “No new services may ship with RSA keys under 3072 bits.”
     • “Block builds if TLS 1.0/1.1 is enabled.”
     • “Alert when certificates will expire in less than 30 days.”
   • Enforce those policies with your CI/CD and ASPM workflows.
5. Expose CBOMs to the right stakeholders
   • Developers need actionable details (file, line, service, recommended fix).
   • Security architects and crypto owners need aggregation (which business systems rely on which algorithms).
   • Auditors and regulators need evidence (exportable CBOM/SBOM bundles for specific apps or releases).

How Checkmarx helps

Checkmarx doesn’t just generate lists of components – it gives you the AppSec context you need as a foundation for CBOM initiatives:

• Checkmarx SCA generates SBOMs in industry‑standard formats and correlates them with vulnerability, reachability, license and malicious‑package data.
• Checkmarx Software Supply Chain Security adds broader visibility into repository health, build pipelines and open‑source risk so you can understand where cryptographic libraries are coming from and how they’re used.
• These capabilities give AppSec and crypto teams the raw data – components, dependencies, vulnerabilities and usage – that can be enriched into a cryptographic bill of materials for each application.

As CBOM standards and tooling continue to mature, having accurate SBOMs and strong SCA in place is the fastest way to be CBOM‑ready.

Checkmarx provides the building blocks you need to stand up a CBOM practice:

• Generate accurate SBOMs and continuously scan for open‑source vulnerabilities, malicious packages and license risk with Checkmarx SCA.
• Strengthen software supply chain security with solutions that monitor repositories, pipelines, and runtime usage.

From there, you can extend your SBOM and SCA data model to include cryptographic inventory and policy metadata, producing CBOMs tailored to your organization’s crypto standards.

Last updated: December 8, 2025