CBOM stands for Cryptographic Bill of Materials. It is a structured, machine-readable inventory of every cryptographic asset inside an application or system: the algorithms, key sizes, certificates, cryptographic libraries, and protocols in use, along with how they relate to the components that implement them. Where a Программалык камсыздоонун материалдарынын тизмеси (SBOM) answers “what code is in this application,” a CBOM answers a narrower and, for many organizations, harder question: “where is cryptography running, and exactly what kind.”
CBOM meaning, in plain terms #
Most security teams can produce a reasonably complete list of the open-source libraries their software depends on. Far fewer can answer where RSA-2048 is still in use, which services rely on SHA-1, or what would break if TLS 1.0 were disabled tomorrow. That gap is what a CBOM closes. It is not a new kind of cryptography and not a scanning tool by itself: it is the output, a documented map of cryptographic usage across a codebase, a build, or an entire estate.
A CBOM typically records:
- Algorithms and their parameters: encryption and signature algorithms, key sizes, cipher modes (for example, flagging RSA-1024 or CBC-only cipher suites as outdated)
- күбөлүк: X.509 certificates, their issuers, and expiration
- Keys and cryptographic material: public, private, and secret keys, initialization vectors, and related material
- Cryptographic libraries and modules: which library implements a given algorithm, and its version
- Протоколдор: TLS, IPsec, and other security protocols in use, including deprecated versions still active
- мамилелер: which component invokes which library, and which protocol relies on which algorithm underneath it
CBOM vs SBOM: what’s the difference #
An SBOM lists software components and their dependencies. A CBOM is narrower and deeper: it takes the cryptography inside those components and describes it in cryptographic terms an SBOM was never designed to capture. A dependency list can tell you an application uses a particular TLS library; it won’t tell you which cipher suites that library is configured to allow, or whether a certificate behind it is about to expire. Practically, the two are complementary. Organizations with a mature SBOM practice have a head start on CBOM, because the same discovery process that maps components can be extended to map the cryptography those components implement.
Эмне үчүн азыр маанилүү #
Three separate pressures are pushing cryptographic inventory from a nice-to-have to a documented requirement:
Посткванттык криптография (PQC) migration. Before an organization can migrate away from classical cryptography, it needs an accurate map of where that cryptography is used. A CBOM is that map. It lets a security team scope a PQC pilot precisely (for example, every service using a certificate issued by a specific CA on RSA-2048) and track migration progress over time, rather than guessing at exposure.
Crypto agility. Deprecated algorithms and weak configurations don’t announce themselves. A CBOM surfaces SHA-1 usage, short key lengths, or TLS 1.0/1.1 still enabled, so a team can prioritize what’s genuinely exploitable instead of auditing manually system by system.
Regulatory momentum. The concept has moved from an AppSec best practice toward an explicit government requirement. On June 22, 2026, the White House signed Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” which directed CISA and NIST to publish minimum elements for a CBOM within 270 days, the first time a cryptographic bill of materials has been named as a defined artifact in federal policy. NIST’s own PQC migration guidance separately recommends pairing an SBOM with a CBOM as organizations prepare for quantum-safe algorithms.
How a CBOM is generated #
The concept originated as an extension of the CycloneDX SBOM standard, maintained under OWASP, which added a dedicated crypto-asset component type in CycloneDX v1.6. That component records the cryptographic primitive, variant, and mode in use, along with the API calls and code locations where the cryptographic operation occurs, letting a CBOM be generated the same way an SBOM is: from static analysis of source code, dependency manifests, and, increasingly, binary analysis for cases where source isn’t available.
In practice, generating a usable CBOM depends on the same kind of software composition analysis already used for SBOM generation, extended to recognize cryptographic library calls, certificate handling code, and protocol configuration, then correlated against known weaknesses (deprecated algorithms, short keys, expired or soon-to-expire certificates) so the inventory becomes something a team can act on rather than a static list.
What a CBOM does not cover #
A CBOM describes what’s built into an application’s code and dependencies. It does not, by itself, capture operational configuration such as key rotation schedules, hardware security module usage, or runtime cipher suite enforcement on a live server. A complete cryptographic posture combines a CBOM with that operational context; the CBOM is the starting inventory, not the entire picture.
Xygeni's ASPM platform generates a CBOM alongside an SBOM and AI-BOM as part of its unified asset inventory, so cryptographic risk sits in the same view as the rest of your application security posture.
FAQ #
No, though the acronym has been used both ways historically. Some sectors, including medical devices, have used “cybersecurity bill of materials” to describe a broader security inventory. In the AppSec and software supply chain community, CBOM now refers specifically to cryptographic assets.
An SBOM alone won’t tell you which algorithms, key sizes, or certificates are in use, only which components and libraries are present. A CBOM adds that layer. Many teams build a CBOM as an extension of an existing SBOM program rather than as a separate effort from scratch.
Requirements are emerging rather than settled. Executive Order 14412 (June 2026) is the first policy to name a CBOM directly, directing CISA and NIST to define minimum elements, with guidance expected in early 2027. No ISO/IEC standard for CBOM exists yet. The practical format in use today is the CycloneDX CBOM extension..
Any organization planning a post-quantum cryptography migration, operating in a regulated sector where cryptographic hygiene is audited, or subject to emerging federal cryptographic-inventory requirements should treat CBOM generation as a near-term priority rather than a future one.
