Software Bill of Materials and Post-Quantum Readiness: Building a CBOM

A software bill of materials tells you what components are in your software. It does not tell you what cryptographic algorithms those components use, which key sizes are in operation, or which of those algorithms are on a deprecation timeline. For post-quantum readiness, that gap is the difference between having a document and having an inventory.

The cryptographic bill of materials, or CBOM, is the extension that fills this gap. It captures algorithm identity, parameter sets, operating modes, library versions, and deprecation status per asset against NIST IR 8547 category classifications. Without a CBOM, a PQC migration programme is a manual archaeology exercise: teams searching through source code and configuration files, following cryptographic calls through library layers, trying to establish what is in use before they can decide what needs to change.

The tooling, vocabulary, and regulatory framing for CBOM as a production practice now exist. CycloneDX 1.6 (released April 2024) introduced dedicated cryptographic asset support. NIST IR 8547 Initial Public Draft (November 2024) provides the deprecation taxonomy that a CBOM policy engine needs to evaluate against. The EU Cyber Resilience Act (Regulation 2024/2847) creates supply chain documentation obligations that a CBOM partially satisfies. What is missing, in most organisations, is the implementation.

Why SBOM Does Not Tell You What You Need to Know About Quantum Risk

The NTIA SBOM Minimum Elements and Their Gap

NTIA's SBOM Minimum Elements (July 2021) defines the baseline fields for a functional SBOM: Supplier Name, Component Name, Version, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp. Seven fields. None of them capture cryptographic algorithm identity, key size, operating mode, or deprecation status.

A SBOM that lists openssl 3.0.7 as a component tells you the library version. It does not tell you whether the application calls RSA-2048 for key wrapping, ECDSA P-256 for signing, or ML-KEM-768 for key encapsulation from that library. The same library version can be used with algorithms ranging from deprecated-in-2030 to post-CRQC safe. Version alone is not sufficient for quantum risk assessment.

The EU Cyber Resilience Act, Regulation 2024/2847, creates the SBOM obligation for products with digital elements in Annex I, Part II, point (1). The CRA does not yet mandate cryptographic asset fields by name. For a full analysis of how the EU Cyber Resilience Act creates quantum-relevant obligations, see EU Cyber Resilience Act and quantum-vulnerable products. Article 13(1), however, requires manufacturers to document and assess all security vulnerabilities in the product; the vulnerability documentation requirement traces to Annex I, Part II, not to lettered sub-clauses of Article 13. Algorithm deprecation under NIST IR 8547 and ETSI TS 119 312 constitutes a known, documented security risk. A CBOM is the instrument that enables this documentation.

CycloneDX 1.6 Cryptographic Asset Taxonomy

CycloneDX 1.6 introduced a cryptoAssets component type that carries the fields a CBOM needs. A CycloneDX 1.6 CBOM entry can enumerate: algorithm name (RSA, ML-KEM, ECDSA), parameter set (2048 for RSA, 768 for ML-KEM), operating mode (key encapsulation, digital signature, AEAD encryption), library name and version, key identifier, and certificate reference.

The field that makes CBOM actionable for PQC is the NIST quantum security level mapping. CycloneDX 1.6 CBOM fields align with NIST IR 8547 IPD category classifications. Automated tooling can evaluate a RSA-2048 key-encapsulation entry against IR 8547 and flag it as Category 2 (deprecated after 2030) directly from the CBOM data. This is the mechanism for continuous compliance monitoring rather than periodic manual review. For the full IR 8547 transition timeline and category definitions, see the NIST IR 8547 transition timeline.

What Goes in a CBOM Entry: The Minimum Viable Record

A CBOM entry for a cryptographic asset should contain at minimum:

• Component name and version of the cryptographic library (for example, openssl 3.2.0)
• Algorithm identifier using names from NIST IR 8547 or IANA registered names
• Parameter set or key size (2048, 4096, or 768, 1024 for key encapsulation; 256, 384, 521 for elliptic curves)
• Operating mode: key encapsulation, digital signature, hash, AEAD encryption, key derivation, or PRNG
• Certificate subject and expiry, where applicable
• NIST IR 8547 IPD category: Category 1 (acceptable), Category 2 (deprecated after 2030), Category 3 (disallowed after 2035), or Not Classified
• Source: where the cryptographic call originates, specifying library, application layer, firmware, or HSM

The operating mode field deserves particular attention. RSA used for key encapsulation is a Category 2/3 concern because Shor's algorithm breaks the key exchange. RSA used for signing long-lived artefacts (root CA certificates, code signing certificates, legal document signatures) is a separate concern with a different timeline driven by the artefact's validity period. A CBOM entry without the operating mode field cannot support correct prioritisation.

CycloneDX versions before 1.6 do not include the cryptoAssets component type. For guidance on conducting a full cryptographic inventory exercise before building your CBOM, see cryptographic inventory for enterprises. If your SBOM pipeline generates CycloneDX 1.5 output, upgrading the generator to 1.6 is the prerequisite for CBOM production. This is a tooling configuration change, not a pipeline architecture change.

Tools for Generating CBOMs

Open Source and Commercial Tooling

Several tools now support CBOM generation at various levels of completeness:

• CycloneDX cdxgen (OWASP Foundation): open-source SBOM generator with CBOM support for JavaScript, Python, Java, Go, and Rust. Version 10.x adds cryptographic algorithm detection via static analysis. The primary tool for teams starting a CBOM programme without a commercial budget.
• Anchore Syft: open-source container image SBOM generator supporting CycloneDX 1.6 output including cryptographic asset fields when the container includes OpenSSL or BoringSSL. Fits naturally into container image build pipelines.
• GitHub Advanced Security and Dependency Graph: identifies cryptographic library dependencies and can block pull requests that introduce deprecated cryptographic library versions via the Dependency Review Action. Does not perform algorithm-level analysis; the signal is library version, not algorithm usage.
• Snyk Code and Container: static analysis with crypto-detection rules that identify uses of deprecated cryptographic functions. Output is not natively in CBOM format but can be mapped to CycloneDX 1.6 via post-processing.

No single tool currently provides complete CBOM coverage across all cryptographic surfaces. A mature CBOM programme combines static analysis (cdxgen, Syft) for source code and container image coverage with dynamic analysis for runtime cryptographic calls, and manual inventory for HSM configurations, hardware tokens, and OT firmware. The static analysis tools give you the baseline. The gaps require targeted investigation.

EU CRA Obligations and the CBOM

EU CRA Article 13(1) requires manufacturers to exercise due diligence when integrating components and to draw up technical documentation including a complete list of software dependencies. The SBOM obligation itself is established in Annex I, Part II, point (1). Article 13(1) also requires manufacturers to document and assess all security vulnerabilities; that vulnerability documentation requirement traces to Annex I, Part II, not to lettered sub-clauses within Article 13(1).

ETSI TS 119 312 V1.4.3 (2023) provides European algorithm deprecation timelines for electronic signatures and infrastructure. Under ETSI TS 119 312, RSA-2048 is classified as acceptable for use until 2025 and RSA-3072 as acceptable until 2030. For any organisation deploying qualified electronic signatures, a CBOM that surfaces RSA-2048 usage in a signing context constitutes a compliance finding against ETSI TS 119 312 today, not a future concern.

The CRA does not yet name CBOM as a required document. The practical position is that a CBOM is the most straightforward mechanism for demonstrating compliance with Article 13(1)(f) for cryptographic assets. Organisations that can produce a CBOM with IR 8547 and ETSI TS 119 312 status annotations for each cryptographic asset are in a materially stronger compliance position than organisations that can only produce a library dependency list. For the broader supply chain security context under CRA and related frameworks, see supply chain quantum security.

Integrating CBOM into CI/CD Pipelines

The practical integration point for CBOM generation is the container image build stage and the SBOM attestation stage at SLSA Level 2 or above. Most container image signing workflows using Cosign and Rekor already produce SBOM attestations. Extending the attested document to include CBOM fields requires a configuration change in the SBOM generation step, not a change to the pipeline architecture.

OWASP CycloneDX provides a CBOM policy-as-code format evaluated using the cyclonedx-cli tool. A policy rule specifying that no algorithm with NIST IR 8547 Category 3 status is permitted can block a build if a disallowed algorithm is detected in the generated CBOM. This is the enforcement mechanism for organisations that want a cryptographic gate in their CI/CD pipeline.

Teams adopting CBOM as a pipeline gate should begin in detection-only mode and remain there for at least one quarter. Algorithm usage in transitive dependencies surfaces unexpected findings. The first production scan of a mature microservices codebase routinely returns dozens of cryptographic asset entries that were not anticipated. Block mode is appropriate once the baseline is understood and the expected findings have been triaged.

From CBOM to Migration Priority

A CBOM is a risk inventory. By itself, it does not produce a migration sequence. Prioritisation should follow this order:

• Asymmetric key exchange algorithms (RSA, ECDH, ECDSA) used for long-term key protection. Shor's algorithm applies directly. These are the primary migration targets.
• Asymmetric digital signatures on long-lived artefacts: code signing certificates, document signatures, PKI root CA certificates. Priority is driven by the artefact's validity period and the HNDL risk for integrity rather than confidentiality.
• Symmetric algorithms used in suboptimal configurations. AES-128-GCM should be upgraded to AES-256-GCM as a precautionary measure. AES-256-GCM is post-CRQC safe for confidentiality. This upgrade does not require waiting for ML-KEM support in the application layer.

The CBOM feeds the cryptographic asset register. The asset register, ordered by IR 8547 category and by exposure (internet-facing versus internal, key lifetime, data sensitivity), produces the migration sequence. Teams that have completed this prioritisation exercise are positioned to engage with vendor roadmaps for Vault, AWS KMS, and Kubernetes KMS with specific requirements and timelines rather than waiting passively for platform updates. For a full guide to building and maintaining a cryptographic asset register, see the cryptographic asset register build guide.

Begin Your CBOM Programme

Quantum Security Defence assists organisations in deploying CBOM generation tooling, mapping outputs to NIST IR 8547 categories, and integrating CBOM policy gates into CI/CD pipelines. If your SBOM programme has not yet extended to cryptographic asset inventory, contact us to discuss a CBOM readiness assessment scoped to your technology stack and regulatory obligations.