BOM Upload and Crypto Asset Inventory

A Cryptographic Bill of Materials (CBOM) is a structured, machine-readable inventory of all cryptographic assets used within a software application, service, or system. It documents the cryptographic algorithms, protocols, libraries, certificates, keys, and cipher suites that your applications depend on.

Think of a CBOM as a comprehensive manifest of your cryptographic landscape — similar to how a Software Bill of Materials (SBOM) catalogs software components and dependencies, a CBOM specifically catalogs the cryptographic elements that protect your data and communications.

As quantum computing advances, organizations must understand their cryptographic exposure to plan effective migration strategies. A CBOM provides the foundational visibility required to:

• Identify quantum-vulnerable cryptography — Pinpoint algorithms such as RSA, ECC, and classical Diffie-Hellman that are susceptible to quantum attacks.
• Assess cryptographic dependencies — Understand which services and applications rely on specific cryptographic components, revealing the blast radius of any vulnerability.
• Plan PQC migration — Prioritize which systems to upgrade first based on risk exposure and dependency mapping.
• Maintain compliance — Meet emerging regulatory requirements that mandate cryptographic transparency and quantum-readiness assessments.
• Enable continuous monitoring — Track your organization's cryptographic posture over time through repeated CBOM assessments.

• You must have the Upload permission for the BOM module (see Access Control).
• The BOM file must be in CycloneDX JSON or XML format.
• The file size must not exceed 50 MB.
• The BOM file must conform to CycloneDX specification version 1.6 or above.

To upload a BOM file:

1. Navigate to Quantum Trust Hub > BOM.
2. Click Upload.
3. In the file browser, select the CycloneDX JSON or XML file you want to upload.
4. Click Submit.

The platform validates the file, parses the cryptographic components and services, computes quantum readiness scores, and adds the record to the Upload Inventory.

The Crypto Properties section displays the core cryptographic attributes of the component, extracted from the cryptoProperties field of the uploaded CycloneDX CBOM.

The attributes are rendered as tags and vary by component type (algorithm, key, certificate, library, protocol).

Examples include the algorithm primitive (e.g., ML-DSA-44), cryptographic functions supported (sign, verify, signature), execution mode (software-plain-ram), and the target implementation platform (Implementation Platform: x86_64) etc.

The Properties section captures formal registry and compliance metadata for the cryptographic component, sourced directly from the cryptoProperties fields in the uploaded CycloneDX CBOM.

This information helps Security Analysts and Compliance Officers quickly determine whether the algorithm/key is a formally registered standard and whether it meets a specific compliance or certification bar (e.g., FIPS 140-2/3)

The Dependencies section reveals the relationships between cryptographic components and services within the BOM. Understanding these dependencies is critical for assessing the impact of migrating or replacing any cryptographic asset.

The External References section displays any documentation links, website URLs, or other external resources associated with a specific component. These references are declared in the BOM file under the externalReferences field for each component.

The platform analyzes the following attributes to determine quantum readiness:

• Algorithm type and name — Checked against a curated database of quantum-safe and quantum-vulnerable algorithms.
• Key size — Evaluated against minimum key-size thresholds for quantum safety.
• Protocol dependencies — Protocols are assessed based on the cipher suites and key exchange mechanisms they employ.

If the platform cannot obtain sufficient information (for example, algorithm name or key size is missing from the BOM), the component is classified as Review Required.

For each component, the platform provides a recommended action to improve quantum readiness. These recommendations are contextual and depend on the current state and type of the component. Common recommendations include:

• Replace the algorithm with a quantum-resistant equivalent.
• Upgrade the library to a version that supports PQC algorithms.
• Migrate the protocol to a version that supports hybrid or quantum-safe cipher suites.
• Review the component and manually assess quantum readiness.

The Quantum Vulnerable (%) metric displayed in the Upload Inventory represents the proportion of components within a BOM that are classified as quantum-vulnerable. This metric is always displayed, even if the percentage is 0%.

You can delete one or more BOM records from the Upload Inventory. Deleting a record removes it permanently, along with all associated crypto asset data.

To delete BOM records:

1. Navigate to Quantum Trust Hub > BOM.
2. Select one or more BOM records from the inventory using the checkboxes.
3. Click Delete.
4. Confirm the deletion when prompted.

If a BOM file upload fails (due to file corruption, format issues, exceeding the maximum nesting depth, or other validation errors), the inventory displays the record with a Failed status.

To view failure details:

• Click the failed record to view the error message and timestamp.

To retry the upload:

• Click Re-upload on the failed record to upload the corrected BOM file.

Common causes of upload failure include: