The Complete Guide to Cryptographic Bills of Materials (CBOM)

What Is a Cryptographic Bill of Materials?

A Cryptographic Bill of Materials (CBOM) is a structured inventory of every cryptographic asset used in a software system. This includes algorithms, key sizes, certificates, protocols, and cryptographic libraries — every element that contributes to the security posture of your application.

Think of a CBOM as a complete map of your cryptographic landscape. Just as a Software Bill of Materials (SBOM) catalogs your software dependencies, a CBOM catalogs your cryptographic dependencies. In an era where quantum computing threatens to break widely-used encryption algorithms, knowing exactly what cryptography your systems rely on is no longer optional — it’s a compliance mandate.

The CBOM concept was formalized through the CycloneDX 1.6 specification, published by OWASP, which introduced dedicated cryptographic component types. This standardized format enables automated tooling, cross-organization sharing, and regulatory compliance verification.

Key Components of a CBOM

A comprehensive CBOM captures the following categories:

The CycloneDX 1.6 Standard

The CycloneDX 1.6 specification is the industry-standard format for CBOMs. Maintained by OWASP, CycloneDX provides a machine-readable schema that enables:

• Automated validation — tools can programmatically check cryptographic compliance
• Cross-tool interoperability — CBOMs can be shared between security platforms
• Regulatory reporting — auditors can consume standardized CBOM output
• Continuous monitoring — CI/CD pipelines can gate on CBOM policy violations

A CycloneDX CBOM is expressed in JSON or XML format. Here’s what a simplified entry looks like:

{
  "type": "crypto-asset",
  "name": "AES",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "block-cipher",
      "mode": "GCM",
      "keyLength": 256,
      "cryptoFunctions": ["encrypt", "decrypt"]
    }
  }
}

CBOM vs SBOM vs HBOM: Understanding the Differences

The “Bill of Materials” family has grown significantly. Here’s how the three primary BOM types compare:

Why SBOMs Alone Aren’t Enough

An SBOM might tell you that your application uses openssl@3.1.4, but it won’t tell you:

• Which specific algorithms your code invokes (AES-128-CBC vs AES-256-GCM)
• Whether any deprecated algorithms are in use (MD5, SHA-1, DES)
• What key sizes are being used (RSA-1024 vs RSA-4096)
• Whether your TLS configuration allows downgrade attacks
• Which cryptographic operations are hard-coded vs configurable

A CBOM fills these critical gaps by analyzing your actual source code — not just your dependency tree.

Why Cryptographic Bills of Materials Matter Now

1. The Post-Quantum Threat

Quantum computers capable of breaking RSA-2048 and ECC-256 are projected within the next 10–15 years. But “Harvest Now, Decrypt Later” (HNDL) attacks mean that adversaries are already collecting encrypted data today with the intention of decrypting it once quantum computers are available.

This means your current encryption is already at risk if:

• You’re protecting data with a sensitivity lifetime beyond 2035
• You’re using RSA, ECDSA, or Diffie-Hellman key exchange
• You’re in defense, financial services, or healthcare

2. Federal Compliance Mandates

Three overlapping regulatory frameworks now require cryptographic inventory:

• EO 14412 — mandates federal contractors meet NIST PQC standards by Dec 31, 2030
• CNSA 2.0 — NSA’s transition timeline for national security systems
• NIST SP 800-131A Rev 3 — deprecation schedule for legacy algorithms

3. Enterprise Risk Management

Beyond regulatory compliance, CBOMs enable:

• Incident response — when an algorithm is compromised, instantly identify all affected systems
• M&A due diligence — assess the cryptographic posture of acquisition targets
• Vendor assessment — require CBOMs from suppliers as part of procurement
• Audit readiness — generate auditor-ready reports in minutes, not weeks

How to Generate a CBOM with KeyLens

KeyLens is the fastest open-source CBOM generator. Built in Rust with Tree-sitter AST parsing, it scans 20+ programming languages and produces CycloneDX 1.6-compliant output in seconds.

Step 1: Install KeyLens

# macOS / Linux
brew install keylens/tap/cbom

# Or download the binary directly
curl -sSL https://keylens.dev/install.sh | sh

Step 2: Scan Your Codebase

# Scan the current directory
cbom scan .

# Scan a specific directory with CBOM output
cbom scan ./src --format cbom --output crypto-inventory.json

Step 3: Review the Results

KeyLens produces a comprehensive report showing every cryptographic asset detected:

# View summary
cbom scan . --format table

# Filter by algorithm family
cbom scan . --filter 'algo.family=="RSA"'

# Check against CNSA 2.0 requirements
cbom scan . --check cnsa-2.0

Step 4: Integrate into CI/CD

Add cryptographic scanning to your pull request workflow:

# .github/workflows/cbom.yml
name: CBOM Check
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: keylens/cbom-action@v1
        with:
          policy: cnsa-2.0
          fail-on-violation: true

Step 5: Enforce Policies with Rego

Write custom policies to block deprecated cryptography:

# block-sha1.rego
package cbom.policy

deny[msg] {
    input.components[i].cryptoProperties.assetType == "algorithm"
    input.components[i].name == "SHA-1"
    msg := sprintf("SHA-1 detected in %v — blocked by policy", [input.components[i].evidence.location])
}

CBOM Best Practices

1. Scan Continuously, Not Once

A CBOM is only useful if it’s current. Integrate scanning into your CI/CD pipeline so every code change is automatically inventoried.

2. Start with Discovery, Then Enforce

Don’t block everything on day one. Start by generating a baseline CBOM, review it with your security team, then gradually add policy enforcement.

3. Cover All Languages

Cryptographic usage spans your entire stack — backend, frontend, mobile, infrastructure-as-code. Use a tool like KeyLens that supports 20+ languages to avoid blind spots.

4. Track Crypto Drift

Use cbom diff to compare CBOMs between releases. This catches:

• New algorithms introduced by dependencies
• Key size downgrades
• Deprecated protocol usage in new code

# Compare current scan against baseline
cbom diff baseline.json --scan .

5. Share CBOMs with Stakeholders

CBOMs are designed to be shared. Provide them to:

• Auditors (for compliance verification)
• Customers (as part of security transparency)
• Partners (for vendor risk assessment)

Frequently Asked Questions

What is the difference between a CBOM and an SBOM?

An SBOM (Software Bill of Materials) inventories software components — packages, libraries, and dependencies. A CBOM (Cryptographic Bill of Materials) inventories cryptographic assets — algorithms, keys, certificates, and protocols. An SBOM tells you what software you use; a CBOM tells you what cryptography that software employs. Both are necessary for complete security coverage, and both are increasingly required by regulators.

Is a CBOM required by law?

Yes, for many organizations. Executive Order 14412 (June 2026) mandates that federal contractors maintain cryptographic inventories as part of NIST PQC compliance. CNSA 2.0 requires national security systems to transition to quantum-resistant algorithms by specific deadlines. The EU’s Cyber Resilience Act (CRA) and Digital Operational Resilience Act (DORA) also include cryptographic inventory requirements.

What format should a CBOM use?

The industry standard is CycloneDX 1.6, maintained by OWASP. This specification includes dedicated schema types for cryptographic assets and is supported by major security platforms. KeyLens outputs CycloneDX 1.6-compliant CBOMs by default.

How long does it take to generate a CBOM?

With KeyLens, a typical codebase of 10,000 lines of code scans in approximately 300 milliseconds. Enterprise codebases with millions of lines typically complete in under 5 minutes. Traditional manual audits take 3–6 weeks and cost $200,000+ in consultant fees.

Can I generate a CBOM for any programming language?

KeyLens uses Tree-sitter AST parsing to support 20+ programming languages, including Python, Java, JavaScript, TypeScript, Go, Rust, C, C++, C#, Ruby, PHP, Kotlin, Swift, and more. This makes it the most language-complete CBOM generator available.

What happens if I find deprecated cryptography?

KeyLens identifies deprecated algorithms (MD5, SHA-1, DES, 3DES, RC4) and flags them in the CBOM output. You can use Rego policies to automatically block pull requests that introduce deprecated crypto, or generate compliance reports showing remediation priorities.

Next Steps

• Get started with KeyLens → — Install and run your first scan in under 2 minutes
• CNSA 2.0 Compliance Checklist → — Check your algorithms against NSA requirements
• EO 14412 Guide → — Understand what federal contractors must do now
• PQC Migration Guide → — Plan your post-quantum transition