CBOM (Cryptographic Bill of Materials): Why Every Enterprise Needs One

You know what software your systems run (SBOM). You know what open-source libraries they depend on (SCA). But do you know what cryptographic algorithms protect your data? Which keys are RSA-2048 (quantum-vulnerable) vs AES-256 (quantum-safe)? Which certificates use SHA-1 (deprecated) vs SHA-256? Which protocols still allow TLS 1.0?

A Cryptographic Bill of Materials (CBOM) answers these questions. It’s a complete inventory of every cryptographic asset in your infrastructure — algorithms, keys, certificates, protocols, and libraries — with enough detail to assess risk, plan migrations, and respond to incidents.

If you’re planning for post-quantum migration, CBOM isn’t optional. You can’t migrate what you can’t see.

---

What a CBOM Contains

A CBOM catalogs cryptographic assets across four dimensions:

1. Algorithms in Use

algorithms:
  symmetric:
    - name: AES-256-GCM
      usage: ["data-at-rest", "TLS-bulk-encryption"]
      quantum_safe: true
      systems: ["payment-db", "api-gateway", "backup-storage"]
    - name: 3DES
      usage: ["legacy-payment-terminal"]
      quantum_safe: false
      deprecated: true
      risk: HIGH
      systems: ["pos-terminal-fleet"]

  asymmetric:
    - name: RSA-2048
      usage: ["TLS-certificates", "code-signing"]
      quantum_safe: false
      migration_priority: HIGH
      systems: ["web-servers", "ci-cd-pipeline"]
    - name: ECDSA-P256
      usage: ["TLS-certificates", "mTLS"]
      quantum_safe: false
      migration_priority: MEDIUM
      systems: ["service-mesh", "api-gateway"]

  hash:
    - name: SHA-256
      usage: ["certificate-signatures", "HMAC", "integrity"]
      quantum_safe: true  # Grover's reduces to 128-bit — still safe
      systems: ["all"]
    - name: SHA-1
      usage: ["legacy-document-signatures"]
      quantum_safe: false
      deprecated: true
      risk: CRITICAL
      systems: ["document-archive"]

2. Keys and Certificates

keys:
  - id: "payment-db-encryption-key"
    algorithm: AES-256
    storage: "AWS KMS (us-east-1)"
    created: "2024-03-15"
    last_rotated: "2025-03-15"
    crypto_period: "1 year"
    owner: "DBA Team"
    quantum_risk: NONE  # AES-256 is quantum-safe

  - id: "api-gateway-tls-key"
    algorithm: RSA-2048
    storage: "Kubernetes Secret"
    created: "2026-01-15"
    expires: "2026-04-15"
    auto_renew: true
    owner: "Platform Team"
    quantum_risk: HIGH  # RSA vulnerable to Shor's algorithm

certificates:
  - subject: "api.example.com"
    issuer: "Let's Encrypt R3"
    algorithm: RSA-2048
    signature: SHA-256
    expires: "2026-04-15"
    quantum_risk: HIGH

3. Protocols and Configurations

protocols:
  - system: "payment-api"
    protocol: "TLS 1.3"
    cipher_suites: ["TLS_AES_256_GCM_SHA384"]
    key_exchange: "X25519"
    quantum_risk: MEDIUM  # X25519 is quantum-vulnerable for key exchange

  - system: "legacy-sftp"
    protocol: "SSH-2"
    ciphers: ["aes256-ctr"]
    key_exchange: "diffie-hellman-group14-sha256"
    quantum_risk: HIGH  # DH is quantum-vulnerable

4. Libraries and Dependencies

crypto_libraries:
  - name: "OpenSSL"
    version: "3.2.1"
    fips_validated: true
    fips_cert: "#4282"
    systems: ["web-servers", "api-gateway"]
    pqc_support: "via oqs-provider"

  - name: "BouncyCastle"
    version: "1.78"
    fips_validated: false
    systems: ["java-services"]
    pqc_support: "experimental"

---

Why You Need a CBOM Now

Reason 1: Post-Quantum Migration Planning

You can’t migrate to quantum-safe algorithms if you don’t know where quantum-vulnerable algorithms are used. A CBOM tells you:

• What’s at risk: Every RSA and ECC key, every DH key exchange, every ECDSA signature
• What’s safe: AES-256 (symmetric), SHA-256+ (hashing) — these survive quantum
• Migration priority: Systems handling long-term sensitive data (healthcare records, financial data, government secrets) must migrate first
• Scope: How many systems need changes? Hundreds? Thousands?

Without a CBOM, post-quantum migration is guesswork.

Reason 2: Compliance Requirements

Multiple frameworks now require or recommend cryptographic inventories:

Framework	Requirement
PCI DSS 4.0	Req 12.3.3: Inventory of cipher suites and protocols
NIST CSF 2.0	ID.AM-5: Resources are prioritized based on criticality
CISA Zero Trust	Pillar 5: Data — know what protects your data
EU Cyber Resilience Act	Cryptographic asset documentation for certified products
CNSA 2.0	Inventory required before migration planning
EO 14028	Software supply chain transparency (extends to crypto)

Reason 3: Incident Response

When a vulnerability is announced (like SHA-1 collision, or a new attack on a specific algorithm), you need to answer immediately:

• “Do we use this algorithm anywhere?”
• “Which systems are affected?”
• “What data is at risk?”
• “How quickly can we migrate?”

Without a CBOM, answering these questions takes days or weeks of manual investigation. With a CBOM, it’s a database query.

Reason 4: Algorithm Deprecation

Algorithms get deprecated on timelines:

• SHA-1 for certificates: deprecated 2016, still found in legacy systems
• TLS 1.0/1.1: deprecated 2020, still running on old databases
• RSA-1024: broken 2010, still in some embedded devices
• 3DES: deprecated 2023, still in payment terminals

A CBOM tracks where deprecated algorithms persist, enabling targeted remediation.

---

How to Build a CBOM

Approach 1: Network Scanning (Outside-In)

Scan your infrastructure from the network perspective:

# Scan all TLS endpoints for certificate and cipher details
nmap --script ssl-enum-ciphers,ssl-cert -p 443,8443,636,993,5671 10.0.0.0/16

# Extract certificate algorithms
echo | openssl s_client -connect host:443 2>/dev/null | \
  openssl x509 -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"

# Scan SSH for algorithms
ssh-audit server.example.com
# Reports: key exchange, ciphers, MACs, host key algorithms

Covers: TLS certificates, cipher suites, SSH configurations, any network-visible crypto. Misses: Data-at-rest encryption, application-level crypto, embedded crypto in code.

Approach 2: Agent-Based Discovery (Inside-Out)

Deploy agents on systems to inspect local cryptographic configuration:

# Find all certificate files
find / -name "*.pem" -o -name "*.crt" -o -name "*.key" -o -name "*.pfx" 2>/dev/null

# Check OpenSSL version and FIPS status
openssl version -a

# Inspect Java keystores
keytool -list -keystore /path/to/keystore.jks

# Check disk encryption
cryptsetup luksDump /dev/sda2 | grep -E "cipher|hash"
dmsetup table --showkeys

Covers: Local certificates, key files, disk encryption, library versions. Misses: Network-level configurations, cloud-managed keys.

Approach 3: Cloud API Queries

Query cloud providers for managed cryptographic assets:

# AWS
aws kms list-keys --query 'Keys[*].KeyId'
aws kms describe-key --key-id <id> --query 'KeyMetadata.{Algorithm:KeySpec,Usage:KeyUsage}'
aws acm list-certificates --query 'CertificateSummaryList[*].{Domain:DomainName,Algo:KeyAlgorithm}'

# Azure
az keyvault key list --vault-name myvault --query '[].{Name:name,Type:keyType}'
az keyvault certificate list --vault-name myvault

# GCP
gcloud kms keys list --location=global --keyring=my-ring --format="table(name,purpose,algorithm)"

Approach 4: Code Analysis (SAST for Crypto)

Scan source code for cryptographic API usage:

# Find crypto library imports
grep -r "from cryptography" --include="*.py" .
grep -r "javax.crypto" --include="*.java" .
grep -r "crypto\." --include="*.go" .
grep -r "require('crypto')" --include="*.js" .

# Find hardcoded algorithms
grep -rn "AES\|RSA\|SHA\|DES\|MD5\|RC4" --include="*.py" --include="*.java" .

Approach 5: CycloneDX CBOM Standard

Use the CycloneDX standard format for machine-readable CBOM:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "cryptographic-asset",
      "name": "payment-api-tls-certificate",
      "cryptoProperties": {
        "assetType": "certificate",
        "algorithmProperties": {
          "algorithm": "RSA",
          "keySize": 2048,
          "mode": null
        },
        "certificateProperties": {
          "subjectName": "CN=payment-api.example.com",
          "issuerName": "CN=Let's Encrypt R3",
          "notValidBefore": "2026-01-15T00:00:00Z",
          "notValidAfter": "2026-04-15T00:00:00Z",
          "signatureAlgorithm": "SHA256withRSA"
        },
        "quantumComputingVulnerability": "HIGH"
      }
    }
  ]
}

---

From CBOM to Action: The PQC Migration Workflow

1. Build CBOM (inventory everything)
      ↓
2. Classify quantum risk (HIGH/MEDIUM/LOW/NONE per asset)
      ↓
3. Prioritize by data sensitivity × quantum risk
      ↓
4. Plan migration (which systems first, which algorithms to adopt)
      ↓
5. Test PQC algorithms (hybrid mode in non-production)
      ↓
6. Deploy (replace quantum-vulnerable algorithms)
      ↓
7. Verify (updated CBOM shows reduced quantum risk)
      ↓
8. Repeat (continuous monitoring for new quantum-vulnerable assets)

---

FAQ

Q: How is CBOM different from a certificate inventory? A: A certificate inventory tracks certificates (expiry, issuer, deployment location). A CBOM tracks ALL cryptographic assets: certificates + encryption keys + algorithms + protocols + libraries. Certificates are one component of a CBOM.

Q: How often should a CBOM be updated? A: Continuously (automated scanning) or at minimum quarterly. Infrastructure changes daily — new services deployed, new certificates issued, new libraries added. A CBOM that’s 6 months old is already inaccurate.

Q: Do I need a CBOM if I’m not planning PQC migration yet? A: Yes. CBOM is valuable for: compliance (PCI DSS 4.0 cipher inventory), incident response (quickly identify affected systems when vulnerabilities are announced), and operational visibility (know what crypto you’re running). PQC migration is just one use case.

Q: Can I build a CBOM with open-source tools? A: Partially. Network scanning (nmap, testssl.sh), code analysis (grep, semgrep), and cloud API queries are all free. The challenge is aggregating results into a unified inventory and keeping it current. For enterprise-scale CBOM with continuous discovery, you likely need a dedicated platform.

Q: What’s the CycloneDX CBOM standard? A: CycloneDX (OWASP) added cryptographic asset support in version 1.6. It provides a standardized JSON/XML format for representing cryptographic assets, making CBOMs machine-readable and interoperable between tools. It’s the emerging standard — similar to how CycloneDX SBOM standardized software component inventories.