How to build a QBOM: a step-by-step guide

A useful first QBOM covers a small number of critical services well rather than the whole estate badly. This is the sequence that gets you there.

Before you start

Decide which definition you are building to. CERT-In's QBOM documents components related to quantum computing and quantum-safe cryptography ^[1]; most migration programmes also need a quantum-exposure view of their existing cryptography. The steps below produce both. For background, read What is a QBOM?

Step 1: Scope by business service

Choose a manageable set of critical services: internet banking, citizen portals, payment messaging, firmware update pipelines. The CISA, NSA and NIST factsheet recommends prioritising high-impact systems, industrial control systems and assets with long-term confidentiality needs ^[2]. For each service, list the applications, infrastructure, devices and third-party services it depends on. Your SBOM and HBOM supply much of this.

Step 2: Discover cryptography

Use several discovery methods, because each has blind spots:

• Source code scanning for cryptographic API calls (for example the Sonar Cryptography plugin, which outputs a CycloneDX CBOM ^[3]).
• Images and file systems for certificates, keys and library configuration (for example CBOMkit-theia ^[4]).
• Network scanning of TLS, SSH and VPN endpoints for protocols and cipher suites.
• PKI, HSM and KMS exports for key types, sizes and certificate hierarchies.
• Suppliers for appliances and SaaS you cannot scan: request their CBOM or QBOM.

Tool options are compared in QBOM tools.

Step 3: Record the CERT-In elements

For quantum-related and quantum-safe components, capture the Table 8 elements: model name, version, vendor and origin, licence information, cryptographic asset, communication protocol, hardware, software dependencies, environmental impact, vulnerabilities and attestations ^[1]. For every cryptographic asset, capture the CBOM fields CERT-In lists for algorithms, keys, protocols and certificates ^[1]. Field-by-field guidance is in CERT-In QBOM requirements.

Step 4: Represent it in CycloneDX or SPDX

CERT-In recommends SPDX or CycloneDX ^[1]. In CycloneDX 1.6, a cryptographic asset is a component of type cryptographic-asset with cryptoProperties. Its assetType is one of algorithm, certificate, protocol or related-crypto-material, and algorithm properties include primitive, parameterSetIdentifier, cryptoFunctions, classicalSecurityLevel and nistQuantumSecurityLevel ^[5]. An ML-KEM-768 key-establishment entry might carry "primitive": "kem", "parameterSetIdentifier": "768" and "cryptoFunctions": ["keygen", "encapsulate", "decapsulate"]. Link each asset to the software component that uses it through dependencies, which is how the CBOM connects to the SBOM ^[6].

Step 5: Add exposure and business context

Scanners cannot supply this. For each system, record:

Scoring is covered in Quantum risk assessment.

Step 6: Validate, sign and version

Validate the document against the schema and against your required-field policy, and report gaps rather than hiding them. Sign it, since attestations are a CERT-In QBOM element ^[1]. Store it with access control, as CERT-In asks for encryption, access control and integrity protection for CBOM/QBOM data ^[1], and keep every version so progress can be shown over time.

Step 7: Hand over to operations

A QBOM that is not updated goes stale quickly. Assign owners, define update triggers and track migration status; see QBOM management.

How IntelliXBOM helps

IntelliXBOM generates and ingests CycloneDX and SPDX BOMs, validates them against required-field policies such as CERT-In's QBOM and CBOM elements, and reports missing fields. It keeps each version with diffs and correlates cryptographic assets with software components, hardware, vulnerabilities and business services.