A useful CBOM can describe algorithms, certificates, keys metadata, protocols and related components while preserving enough identity and evidence to reconcile the export with its originating inventory.
What a CBOM can contain
- Cryptographic algorithms, modes, key sizes and named parameters.
- Certificates and public-key metadata without private key material.
- Protocols, cipher suites and cryptographic properties.
- Libraries, modules and software dependencies that implement cryptography.
- Relationships between components, services, assets and evidence.
- Lifecycle, ownership, confidence and assessment metadata where supported.
CBOM and SBOM
| SBOM | CBOM |
|---|---|
| Describes software components and dependency relationships | Describes cryptographic assets and cryptographic relationships |
| Supports software supply-chain analysis | Supports cryptographic policy, migration and crypto-agility analysis |
| Can reveal packages that may contain cryptography | Adds the algorithms, certificates, keys metadata and protocol context |
| Often provides an input to discovery | Can be linked to the originating software and evidence |
CycloneDX CBOM
CycloneDX extends its bill-of-materials model with cryptographic asset representation. Using a recognized format improves portability between discovery, inventory, governance and migration tools.
Standards-based output does not compensate for weak discovery. The exported CBOM is only as complete as its evidence and coverage, so reports should retain the scanner and rule versions and distinguish unknown or not-scanned sources.
Why normalized discovery matters
Public TLS, source analysis, dependencies and cloud APIs produce different raw observations. A normalized model prevents each scanner from creating an incompatible inventory and gives a CBOM stable identities and relationships.
For PQC migration, that normalization allows teams to find several observations of the same certificate or key, trace them to dependent systems and avoid inflating counts through scanner-specific duplicates.
Frequently asked questions
Is a CBOM a complete cryptographic inventory?
Not automatically. A CBOM represents the assets supplied to it. Its coverage depends on the discovery sources, systems and time period used to create it.
Should a CBOM contain private keys?
No. Private key material and credentials should never be included. Public identifiers and metadata are sufficient for inventory and assessment.
How does CBOM help PQC migration?
It provides a portable way to identify affected algorithms and dependencies, link them to systems and exchange evidence with migration workflows.