CBOM vs SBOM: how a cryptographic inventory extends the software bill of materials
An SBOM lists the software components in a product; a CBOM lists the cryptography those components use. Here is where each stops and how to join them, from the CBOM side.
- An SBOM answers 'what software is in here?'; a CBOM answers 'what cryptography is in use here, and how strong is it?'.
- CERT-In defines separate minimum elements: 21 SBOM fields and CBOM fields grouped under algorithms, keys, protocols and certificates.
- A vulnerable crypto library shows up in the SBOM; a weak cipher suite or an expiring certificate shows up only in the CBOM.
- CycloneDX 1.6 can carry both in one document, linking cryptographic assets to the components that implement them.
Two inventories, two questions
A software bill of materials lists the components that make up a piece of software, libraries, packages and their versions, suppliers and dependencies. NTIA's 2021 minimum elements set the baseline for what an SBOM must contain [2]. A Cryptographic Bill of Materials lists the cryptographic assets that software uses: the algorithms, keys, protocols and certificates, and the properties that determine their strength and lifetime [1].
The two overlap only at one point: cryptographic libraries. An SBOM records that an application ships OpenSSL 3.x; a CBOM records what that application does with it. For the SBOM-side view of the same comparison, see SBOM vs CBOM.
Side-by-side
| SBOM | CBOM | |
|---|---|---|
| Unit of inventory | Software component | Cryptographic asset: algorithm, key, protocol, certificate |
| CERT-In minimum elements | 21 fields, including Component Name, Version, Supplier, License, Dependencies, Vulnerabilities, Patch Status, EOL Date, Checksums or Hashes [1] | Per asset type, e.g. Primitive, Mode, Classical security level and OID for algorithms; Version and Cipher Suites for protocols; Subject, Issuer and validity dates for certificates [1] |
| Main risk signals | Known vulnerabilities, licences, end-of-life components | Deprecated protocols, short keys, weak hashes, expiring certificates, quantum-vulnerable algorithms |
| Changes when | Code is built or dependencies change | Code changes and also when configuration, certificates or keys change, often with no new build |
| Main sources | Package manifests, build systems, binary analysis | Code analysis, network scans, key stores, PKI, configuration |
| Primary users | Vulnerability management, licence compliance, procurement | Cryptography and PKI teams, security architecture, PQC migration |
What each one misses
An SBOM cannot tell you that a web server still accepts TLS 1.0, which RFC 8996 says "MUST NOT be used" [5]. The same OpenSSL version can be configured securely on one host and insecurely on another; the SBOM entry is identical. Nor does an SBOM hold certificates or key metadata.
A CBOM, in turn, is not the right place to track licences or the full dependency tree. It relies on the SBOM to answer "which products contain the library with this vulnerability?".
Linking the two in CycloneDX
CycloneDX 1.6 introduced CBOM support alongside its existing SBOM model [4]. Cryptographic assets are components of type cryptographic-asset, next to library and application components in the same BOM. The dependency graph's provides relationship lets a library component declare the cryptographic assets it implements, while dependsOn shows which components use them; the schema notes that implementing an algorithm does not by itself mean it is in use [3]. The result is one document where you can move from a vulnerable library to the algorithms it provides, and from a weak algorithm to every component that relies on it.
A worked example
- A vulnerability is disclosed in a cryptographic library. The SBOM shows which applications ship the affected version.
- The CBOM, linked through
provides, shows which algorithms and protocols those applications obtain from that library, and which certificates and keys are in play. - The team can then decide whether the vulnerable code path is reachable and record a VEX statement, as CERT-In recommends for cryptographic components (rec. 8.4.1.6) [1].
Should you build one or both?
Both. CERT-In's guidelines define them as separate artefacts with separate minimum elements [1], and they are maintained on different cadences. Start the CBOM where the SBOM is already strong, the applications you build, then extend it to infrastructure, key stores and suppliers, which SBOMs rarely cover well.
How IntelliXBOM helps
IntelliXBOM generates and ingests both SBOMs and CBOMs in CycloneDX, keeping version history for each. It correlates software components and cryptographic assets with vulnerabilities, known-exploited lists, end-of-life data and business services, and records VEX decisions against them.
Frequently asked questions
What is the difference between an SBOM and a CBOM?
An SBOM inventories software components such as libraries and packages. A CBOM inventories cryptographic assets such as algorithms, keys, protocols and certificates, and records how strong they are and when they expire.
Can one file be both an SBOM and a CBOM?
Yes. CycloneDX 1.6 and later allow cryptographic-asset components in the same BOM as software components, and the dependency graph can link a library to the cryptographic assets it provides.
Does an SBOM show weak cryptography?
Only indirectly, by listing a cryptographic library version with known vulnerabilities. It does not show protocol versions, cipher suites, key sizes or certificate expiry, which is what a CBOM records.
Sources
- Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0 (9 July 2025)CERT-In, Government of Indiawww.cert-in.org.in/PDF/TechnicalGuidelines-on-SBOM,QBOM&CBOM,AIBOM_and_HBOM_ver2.0.pdf
- The Minimum Elements for a Software Bill of Materials (July 2021)NTIA, US Department of Commercewww.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
- CycloneDX v1.6 JSON Reference (bom-1.6 schema)OWASP CycloneDXcyclonedx.org/docs/1.6/json/
- CycloneDX v1.6 Released, Advances Software Supply Chain Security with Cryptographic Bill of Materials and Attestations (9 April 2024)OWASP CycloneDXcyclonedx.org/news/cyclonedx-v1.6-released/
- RFC 8996, Deprecating TLS 1.0 and TLS 1.1 (March 2021)IETFwww.rfc-editor.org/rfc/rfc8996
Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.