What is the difference between SBOM and CBOM?

The SBOM inventories a product's software components (libraries, dependencies, versions). The CBOM inventories the cryptographic assets that product uses (algorithms, protocols, certificates, keys). They are complementary documents in the same CycloneDX format: the SBOM says what is inside, the CBOM says how it is protected.

Do I need a dedicated tool to generate a CBOM, or can I start by hand?

An initial manual inventory of a handful of critical systems is an acceptable starting point, but it does not scale: cryptographic assets are often buried in libraries, configuration and network traffic that no hand-written list can cover reliably. For an organization-wide inventory you need static and dynamic scanning tools that generate the CBOM in CycloneDX format repeatably.

Where should a company start building a CBOM?

With the systems handling data that has the longest confidentiality horizon or the nearest contractual deadlines, typically customer-facing applications and services processing personal or financial data. A first pass over that scope is enough to surface expired certificates and deprecated algorithms before extending the inventory to the rest of the application estate.

What is a CBOM (Cryptography Bill of Materials)?

A CBOM is the machine-readable inventory of a system's cryptographic assets: algorithms, certificates, keys.

A CBOM (Cryptography Bill of Materials) is the structured, machine-readable inventory of every cryptographic asset used by a software system: algorithms, protocols, certificates, keys, tokens and secrets, along with the properties that define them, such as the family (for example AES) and the specific variant (for example AES-128-GCM), because security level depends on the variant and the algorithm's name alone is not enough. The reference standard is OWASP CycloneDX, whose April 2024 release, version 1.6, developed with IBM Research, introduced the CBOM as an extension of the same format already used for the SBOM. Where the SBOM tells you which libraries and components make up a product, the CBOM tells you which cryptography that product uses and where: two distinct questions, often confused, and almost no organization today can answer either one with confidence across its whole application estate.

What it contains and how it is generated

A CBOM catalogs every cryptographic asset with its operational properties: the algorithm and its exact variant, key length, the protocol using it (TLS, SSH, a signature format), the certificate with its own expiration date, and the library or module that implements all of this in production. Like the SBOM, it is not compiled by hand once: it is generated with static and dynamic scanning tools that analyze code, configuration and traffic to extract the algorithms actually in use, not just the documented ones, and it is refreshed at every release alongside the rest of the bill of materials. The CycloneDX capability page and its official guide describe the full schema, from algorithms and certificates through to related crypto material such as keys and secrets.

An enterprise example

A banking group with hundreds of applications accumulated over twenty years of acquisitions and integrations typically has no reliable list of where RSA is used, where ECC is used, which certificates expire in the next six months, and which microservices still encrypt with deprecated algorithms in legacy libraries nobody ever updated. A first CBOM inventory routinely surfaces forgotten cryptography: certificates that expired long ago but are still installed, hardcoded keys in code that was never refactored, obsolete protocols that survived three generations of infrastructure. Without that inventory, planning any cryptographic migration means starting from a list of assumptions, not verified facts.

Why it matters for decision makers

The CBOM is the informational prerequisite for crypto-agility: without knowing where and how cryptography is used today, replacing an algorithm remains an intention, not an executable plan. It is also the concrete foundation for post-quantum migration, which the European roadmap sequences in phases through 2035: without an inventory of the public-key algorithms in use, you do not even know where to start migrating. For decision makers, the CBOM is therefore less a security compliance exercise and more an operational risk-reduction tool, one worth building before a regulatory deadline or an incident makes it urgent.