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 vs SBOM, inventory and cryptographic audit
| Artifact | Primary purpose | Important boundary |
|---|---|---|
| SBOM | Describes software components and dependency relationships | A package can contain cryptography without identifying its runtime use |
| CBOM | Describes cryptographic assets and cryptographic relationships | Completeness depends on the discovery sources represented |
| Cryptographic inventory | Maintains normalized assets, evidence, owners and lifecycle over time | It can be broader and more operational than one exchange document |
| Cryptographic audit | Evaluates a defined system and time period against stated criteria | It is a point-in-time assessment, not automatically a living inventory |
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.
Exporting a public exposure CBOM with Cipher Discovery
A completed Cipher Discovery public TLS report can be downloaded as CycloneDX JSON. The export maps directly observed TLS protocol and X.509 certificate assets to native CycloneDX cryptographic-asset records while preserving source asset, evidence, confidence and migration references.
The exported CBOM retains the report boundary and coverage metadata. It describes cryptography observed at the submitted public endpoint; it is not represented as a complete inventory of the organization, internal infrastructure, repositories, cloud resources or endpoints.
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.
Can Cipher Discovery export a CycloneDX CBOM?
Yes. A private public TLS scan report can be downloaded as CycloneDX JSON. The export contains the public cryptographic assets observed in that scan and preserves explicit coverage limitations; it is not a complete organizational inventory.