IM Engineer Study Notes
← Back to list
Security & Privacy
#CBOM#CycloneDX#암호 민첩성#양자내성암호#암호 인벤토리
Last updated · 2026-11-03

Cryptographic Bill of Materials (CBOM)

1. Overview

Definition: A Cryptographic Bill of Materials (CBOM) is a machine-readable inventory of the cryptographic assets that make up a system — algorithms, keys, certificates, protocols, and cryptographic libraries — recorded together with their versions, parameters, security strength, usage locations, and the dependencies among them.

A conventional Software Bill of Materials (SBOM) focuses on identifying the packages, libraries, and containers that make up an application, improving supply-chain visibility. However, an SBOM tells you "which library is used" but not "what cryptographic algorithm that library actually uses, with what key length, and where." For example, two services may use the identical OpenSSL version, yet one performs a TLS handshake with RSA-2048 while the other verifies integrity with a hardcoded MD5 — and an SBOM alone cannot distinguish this difference.

Behind the emergence of the CBOM lies the advance of quantum computers and the resulting transition pressure. Once a sufficiently large fault-tolerant quantum computer appears, Shor's algorithm can break public-key cryptography such as RSA and ECC, making the "Harvest Now, Decrypt Later" threat — stealing and storing ciphertext today to decrypt it in the future — a reality. In response, NIST finalized its post-quantum cryptography (PQC) standards in 2024 with FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), and transition roadmaps (such as NIST IR 8547) propose phasing quantum-vulnerable algorithms toward deprecation around 2030 and disallowance around 2035 (exact timelines and draft/final status should be confirmed against the primary sources).

The problem is that most organizations do not even accurately know "what cryptography they use, where, and with what parameters." Without an inventory, you cannot size the scope of what must be transitioned, cannot set transition priorities, and cannot prove that a transition is complete. The CBOM is precisely the standardized inventory that fills this "cryptographic visibility" gap, serving as the prerequisite and starting point for crypto-agility and PQC transition.

This essay discusses the composition principles and data model of the CBOM, its generation and operation lifecycle, its relationship with and differences from the SBOM, its connection to crypto-agility and PQC transition, and the adoption strategy and considerations from a professional-engineer perspective.

2. CBOM Composition Principles and Data Model

2.1 Why "Relationships and Context" Rather Than a "Component List"

Cryptographic assets differ from ordinary software packages in that a mere listing cannot evaluate risk. Even for the same AES, 128-bit CBC mode and 256-bit GCM mode have very different security properties, and even for the same RSA, 2048-bit for signing and 1024-bit for key exchange have entirely different exposure to quantum and classical threats. Therefore the unit of identification in a CBOM must not be an "algorithm name" but a cryptographic asset that bundles the algorithm, mode, key length, security strength, purpose, and implementation location.

Moreover, cryptographic risk is amplified not in individual assets but in the dependencies between them. For instance, a server private key (related crypto material) connects to the X.509 certificate (certificate) that carries it, that certificate is used in the TLS 1.2 protocol (protocol), and that protocol depends on RSA key exchange and SHA-256 signing (algorithm). When one node is judged quantum-vulnerable, you must trace back to the upper-level assets and services that depend on it to size the impact — and the CBOM expresses this dependency graph, extending the scope of analysis from "what exists" to "what depends on what and how far the impact spreads."

2.2 CBOM Overall Composition Diagram

flowchart LR
  subgraph SRC["Collection Sources"]
    CODE["Source code(static analysis)"]
    BIN["Binaries·libraries"]
    CFG["Config·certificate stores"]
    NET["Network·TLS scan"]
  end
  subgraph CBOM["CBOM(CycloneDX 1.6)"]
    ALG["algorithm(algo·mode·strength)"]
    CERT["certificate(X.509 etc.)"]
    PROT["protocol(TLS·SSH·IPsec)"]
    MAT["related-crypto-material(keys·tokens)"]
  end
  subgraph USE["Utilization"]
    RISK["Quantum risk·compliance analysis"]
    PLAN["PQC transition priority"]
    PROOF["Transition proof·audit"]
  end
  CODE --> ALG
  BIN --> ALG
  CFG --> CERT
  CFG --> MAT
  NET --> PROT
  ALG --> RISK
  CERT --> RISK
  PROT --> RISK
  MAT --> RISK
  RISK --> PLAN --> PROOF

As the diagram shows, the CBOM sits at the center of a pipeline that extracts cryptographic assets from multiple collection sources, normalizes them into a standard schema, and feeds them into risk analysis, transition planning, and audit evidence. The point that the collection source is not singular matters. Static code analysis alone cannot know which TLS suites are actually negotiated in the production environment, and network scanning alone cannot find latent, unused cryptographic paths in the code, so a trustworthy CBOM is built by merging and deduplicating multiple sources.

2.3 CycloneDX 1.6 and the CBOM Data Model

The CBOM is not a proprietary format but is based on the cryptographic-asset representation added in OWASP CycloneDX 1.6. It was designed with leadership from IBM Research, introduced in the 2024 CycloneDX 1.6 release together with Attestations, and the CycloneDX specification was standardized as ECMA-424, gaining the status of an international standard. The key point is that it reuses the "same format and same tool ecosystem" as the existing SBOM, so an organization can layer cryptographic assets onto the SBOM generation, verification, and distribution pipeline it already operates.

CycloneDX classifies cryptographic assets via the cryptoProperties.assetType of a component, and the representative types are as follows.

assetType Meaning Recording example Risk-analysis focus
algorithm Cryptographic algorithm·primitive RSA-2048, AES-256-GCM, SHA-1 Quantum-vulnerability, security strength (112/128-bit), deprecation status
certificate Public-key certificate X.509 server certificate Signature algorithm, validity period, chain trust
protocol Security protocol TLS 1.2/1.3, SSH, IPsec Possibility of negotiating vulnerable versions·suites
related-crypto-material Keys, tokens, and other material Private keys, secret keys, tokens Storage location, lifetime, access control

Each asset is combined with the algorithm variant (primitive), parameter set, NIST level, certification status, and implementation library, along with evidence pointing to "which file and which line of code it is used in." Thanks to this evidence linkage, the CBOM becomes not a mere declaration but a verifiable inventory grounded in actual code and configuration, allowing the edit points to be pinpointed directly during transition work.

3. CBOM Generation and Operation Lifecycle

3.1 Discovery, Normalization, and Merging

The first step of CBOM generation is to automatically discover cryptographic usage. At the source-code level, static analyzers extract cryptographic API calls, algorithm constants, and key lengths (IBM's Sonar/CBOMkit-style tools are representative); at the binary level, they identify linked cryptographic libraries and symbols; and at the operational level, TLS/SSH scanners collect the protocols, suites, and certificates actually negotiated. Because different sources redundantly report the same asset, they are normalized and deduplicated using the algorithm, parameters, and location as keys, and merged into a single consistent graph.

The practical difficulty here is how to handle "paths that appear statically but are not executed" and "paths that surface only dynamically." An MD5 call in the code may be dead code, while conversely an algorithm selected at runtime through external configuration is not caught by static analysis. Therefore mature organizations combine the static results with "evidence of use (call frequency, traffic samples)" to weight the effectiveness of an asset.

3.2 Analysis, Prioritization, Transition, and Evidence

The collected CBOM is combined with risk rules and converted into per-asset risk scores. Representative rules are: (1) is it quantum-vulnerable public-key (RSA·ECC·DH)? (2) is it a classically vulnerable legacy (MD5·SHA-1·DES·RC4·TLS 1.0)? and (3) is its security strength at the 112-bit level so that its deprecation schedule is earlier? This risk score is multiplied by data sensitivity, exposure surface, and lifetime (is it data that requires long-term protection) to produce the transition priority. The more an asset requires long-term confidentiality, the greater the "Harvest Now, Decrypt Later" threat, so its PQC transition is advanced.

sequenceDiagram
  participant Dev as Dev·Ops
  participant Scan as Discovery tools
  participant CB as CBOM repository
  participant Risk as Risk·policy engine
  participant PM as Transition mgmt
  Dev->>Scan: Request code·binary·TLS scan
  Scan->>CB: Submit crypto assets·evidence (CycloneDX)
  CB->>CB: Normalize·dedup·build dependency graph
  CB->>Risk: Pass assets·dependencies
  Risk->>Risk: Assess quantum risk·legacy·strength
  Risk->>PM: Produce priority·impact scope
  PM->>Dev: Direct transition backlog·edit points
  Dev->>CB: Rescan after transition (reflect ML-KEM·ML-DSA)
  CB->>Risk: Re-verify whether transition is complete

Once the transition is done, the same pipeline rescans to prove with the CBOM that quantum-vulnerable assets have been removed and replaced with PQC algorithms. Combined with CycloneDX Attestations, you can leave a signed record of "who satisfied which control, when, and on what basis," allowing transition progress to be reported to regulators and customers in a machine-readable form.

4. Comparison with SBOM·QBOM, and the Relationship with Crypto-Agility

The CBOM is not a competitor to the SBOM but a complementary, specialized counterpart. Where the SBOM addresses "what it is made of (components)," the CBOM addresses "what cryptography those components use and how (cryptographic behavior and assets)." Because the two share the same CycloneDX format, they can be carried together in a single BOM document.

Aspect SBOM CBOM Note (QBOM view)
Primary interest Packages·libraries·dependencies Crypto algorithms·keys·certificates·protocols QBOM interprets·extends CBOM from a quantum-risk view
Core question What went in What cryptography is used where What is quantum-vulnerable and by when it must change
Main use Tracking vulnerable libraries·licenses Crypto visibility·PQC transition·compliance Setting transition schedule·priority
Standard CycloneDX, SPDX CycloneDX 1.6 (ECMA-424) Still converging; note term confusion

The underlying reason this comparison produces differences is that the "basis for judging identity" differs. A package can be judged identical fairly clearly by version and hash, but a cryptographic asset, even under the same name, carries different risk if its mode, strength, purpose, or implementation differ, so the CBOM requires richer attributes and evidence as mandatory. In practice the term QBOM (Quantum-safe/Cryptography BOM) is also used, which is best understood as a specialized naming of the CBOM from the quantum-safe transition viewpoint (avoid assertions, since standards and terminology are still converging).

The relationship with crypto-agility also matters. Crypto-agility is "the ability to design systems so that an algorithm can be replaced by policy and configuration rather than being hardcoded throughout the code." Without a CBOM you do not know where to change, so the premise of agility collapses; and without agility it is hard to actually replace the assets identified by the CBOM. In other words, the CBOM is "visibility" and crypto-agility is "replaceability," and only when the two combine does PQC transition become a repeatable and measurable process.

5. (In-depth) Regulatory·Policy Trends and Practical Adoption Strategy

The rise of the CBOM is intertwined not only with technology trends but with policy pressure. In the United States, a trend is forming that requires federal agencies and contractors to meet quantum-resistant transition deadlines (for example, high-value, high-impact systems around 2030), and discussions such as FAR amendments are expected to spread NIST PQC compliance across the supply chain (specific timelines and scope should be confirmed against the primary sources). NIST IR 8547 presents a transition roadmap that pushes quantum-vulnerable algorithms such as RSA·ECC toward deprecation in 2030 and disallowance in 2035, and because the application timing may differ between 112-bit and 128-bit strength, security strength must be tagged in the CBOM.

The core of practical adoption is a phased approach. Phase 1 is discovery, inventorying enterprise-wide cryptographic use with a CBOM to turn "we don't know" into "we know." As in the case of a financial institution that scanned the TLS configuration of thousands of services and found hundreds of TLS 1.0/1.1 and numerous RSA-1024, discovery alone surfaces immediately actionable legacy. Phase 2 is prioritization, placing long-term confidential data, externally exposed surfaces, and regulated systems at the top. Phase 3 is hybrid transition, applying hybrid key exchange that uses traditional algorithms together with PQC in areas where standalone PQC transition is difficult right now, securing both compatibility and safety. Phase 4 is continuous verification, embedding CBOM generation into CI/CD to create a "policy gate" that fails the build when new code introduces a prohibited algorithm.

Throughout this process, the CBOM functions as a common language connecting the development, security, regulatory, and audit organizations. The greatest practical value is that developers can communicate about edit points, the security team about risk priorities, the regulatory team about compliance evidence, and the audit team about the cryptographic composition at a specific point in time — all through the same CBOM, each from their own perspective.

6. Considerations and Implications (Professional-Engineer Perspective)

  • Transition strategy: Adopting a CBOM should be approached not as "replacing everything with PQC" but as building a governance system that "first sees, then prioritizes, then changes repeatably." Only by embedding the discovery→analysis→transition→evidence lifecycle into CI/CD does it settle into continuous management rather than a one-off survey.
  • Trade-offs: Static analysis is comprehensive but has false positives (dead code) and misses dynamic paths; network scanning is effective but misses internal calls and offline assets. Do not rely on a single source — merge multiple sources while weighting the effectiveness of assets on an evidence basis to reduce noise.
  • Linkage with crypto-agility: To actually replace the assets a CBOM identifies, an agility design that separates cryptography into abstraction layers and configuration must precede or proceed in parallel. Visibility (CBOM) and replaceability (agility) are an inseparable pair.
  • Immaturity of standards·terminology: Because terms and schemas such as CBOM·QBOM·cryptoProperties are still converging, take an open standard such as ECMA-424 (CycloneDX) as the baseline to avoid lock-in to a specific vendor format, and also secure interoperability with SPDX and others.
  • Risk of security itself: A CBOM is also an attack map that holds "where which weak cryptography and keys exist." Without applying access control, signing, and integrity protection to the CBOM artifact itself, you hand the attacker an optimal target list.
  • Outlook and related technologies: Going forward, the CBOM is likely to converge with SBOM·AI SBOM·VEX into an integrated supply-chain transparency system, and combined with post-quantum cryptography (PQC)·crypto-agility·zero-trust key/certificate management, it will develop into the backbone of an organization's cryptographic governance.

References

In one line: A CBOM makes cryptographic assets — algorithms, keys, certificates, protocols — and their dependencies visible in the CycloneDX (ECMA-424) format, turning crypto-agility and the post-quantum transition into a repeatable, measurable, and provable process, and serving as the starting point of cryptographic governance.