Your cryptographic bill of materials, ready to share.
Generate and exchange machine-readable cryptographic evidence with Qinsight Atlas. Import supported CycloneDX CBOMs, export collected records as JSON, and use PDF reports for human review.
A portable record of cryptographic assets and relationships.
A cryptographic bill of materials (CBOM) describes the cryptography in a defined software, service or system scope. It records assets, their properties and relevant relationships in a machine-readable form.
CycloneDX provides a structured model for this evidence. A CBOM can bring together information from declarations and discovery, with context that helps the receiving team understand what was assessed. Read the CycloneDX CBOM overview.
What does a CBOM contain?
CycloneDX groups cryptographic assets into four types. Available properties depend on the asset and source.
- Algorithms: cryptographic purpose, parameters and security attributes.
- Certificates: subject, issuer, validity and links to associated cryptography.
- Protocols: versions, cipher suites and the algorithms they reference.
- Related cryptographic material: metadata describing keys, secrets, tokens and other cryptographic material.
Software libraries remain software components. A library can be linked to the cryptographic assets it implements or uses, connecting software and cryptographic evidence in the same BOM.
Put CBOM evidence into your assessment workflow.
Atlas turns collected cryptographic records into an exchangeable artifact and brings supported CBOM files into the platform for review.
Generate and export
Create a CycloneDX CBOM from collected cryptographic records. Download JSON for structured exchange with assessment, supplier and migration teams.
Import a CBOM
Bring supported CycloneDX CBOM JSON files into Atlas. Review supplied cryptographic records alongside other evidence for your assessment.
Share a readable report
Use a PDF report to support human review. Keep the CycloneDX JSON available for tools that need the structured CBOM data.
During evaluation, check a representative import or export against the version, fields and relationships your receiving workflow needs. Explore the maintained cryptographic inventory.
Read a CycloneDX CBOM example.
This compact example contains one cryptographic algorithm. It shows how an asset is identified and described before adding the wider system context and relationships.
- Format and version
bomFormatandspecVersionidentify the standard.versionidentifies this BOM revision.- Asset identity
bom-refidentifies the asset within the BOM and allows other entries to reference it.- Cryptographic detail
cryptoPropertiesrecords the asset type and its attributes. These fields support interpretation of the evidence.
Illustrative CycloneDX 1.7 example, authored for explanation. It is not an Atlas export or a complete assessment. Security-level metadata alone does not establish the readiness of a deployed system.
{
"bomFormat": "CycloneDX",
"specVersion": "1.7",
"serialNumber": "urn:uuid:11111111-1111-4111-8111-111111111111",
"version": 1,
"components": [
{
"type": "cryptographic-asset",
"bom-ref": "crypto-algo-rsa-2048",
"name": "RSA-2048",
"cryptoProperties": {
"assetType": "algorithm",
"algorithmProperties": {
"primitive": "signature",
"parameterSetIdentifier": "2048",
"classicalSecurityLevel": 112,
"nistQuantumSecurityLevel": 0
}
}
}
]
}Check the evidence as well as the format.
A well-formed file still needs context. Use these checks to prepare a CBOM for supplier reviews, cryptographic risk assessment or post-quantum migration planning.
State the boundary
Identify the system, source or release covered, its collection date and anything outside scope. Update the artifact when that scope changes.
Keep origins clear
Identify the producer and evidence sources. Distinguish supplied declarations from direct observations and note missing information.
Check compatibility
Confirm the specification version, expected fields and resolvable references. Validate the file against that schema and test the receiving workflow.
Review the handoff
Check that the recipient has enough context to interpret the records. Remove secret values and review sensitive metadata before external sharing.
CBOM vs SBOM vs cryptographic inventory
An SBOM describes software composition. A CBOM describes cryptographic assets and relationships. A maintained cryptographic inventory gives teams an ongoing record for operational decisions. The information can overlap and work together.
| View | Main question | Typical detail | Useful for |
|---|---|---|---|
| SBOM | What software components are included? | Components, versions, suppliers, licenses and dependencies | Software supply-chain and vulnerability review |
| CBOM | What cryptographic assets are described in this scope? | Algorithms, certificates, protocols, key metadata and relationships | Exchanging cryptographic evidence between teams and tools |
| Cryptographic inventory | What cryptography do we have, where is it used, and who can act? | Maintained records, source timestamps and available system and ownership context | Ongoing risk review and migration planning |
CBOM questions
Is a CBOM limited to software builds?
No. A CBOM can describe cryptography associated with software, services or systems and can draw on declarations or discovery. Its usefulness depends on the stated scope, evidence sources and collection date.
Can Atlas import a supplier CBOM?
Atlas imports supported CycloneDX CBOM JSON files containing cryptographic records. Review a representative supplier file during evaluation to confirm the required version and fields. An import does not independently verify the supplier’s claims.
Which CycloneDX versions and fields should we use?
Agree the required CycloneDX version and fields with the receiving team, then check a representative Atlas import or export. The standard defines more fields than any individual source may provide.
Does a CBOM prove post-quantum readiness?
No. A CBOM supplies evidence for assessment. Readiness also depends on how cryptography is used, which dependencies are covered, implementation choices and testing. Algorithm names or security-level fields alone do not establish system readiness.
Should a CBOM contain private keys or credentials?
A shared assessment artifact should contain the metadata needed for its purpose. Exclude private keys, secret values and credentials. Review hostnames, identifiers and other sensitive metadata before sharing it outside your organization.
Build a CBOM your next team can use.
Start with one source. Review the records, the format and the handoff with Qinsight.
