CBOM vs SBOM: what’s different, and why you need both

Published 11 October 2026 · 7 min read · By Ali Korsi Both are bills of materials, both can be written in CycloneDX, and both are increasingly asked for by regulators and customers. They answer different questions, and one cannot stand in for the other.

Lire en français

The short answer

A software bill of materials (SBOM) lists the components a product is built from: libraries, versions, package identifiers, licences and how they depend on each other. It answers “what are we shipping?” and is the input to vulnerability and licence management.

A cryptographic bill of materials (CBOM) lists the cryptographic assets a product uses: algorithms, certificates, protocols and key material, with their parameters and where they were found. It answers “which cryptography do we rely on, and where?” and is the input to post-quantum migration and cryptographic governance.

The same library, seen twice

Take pyca/cryptography, a widely used Python cryptography library. In an application’s SBOM it is one line among hundreds:

{
  "type": "library",
  "name": "cryptography",
  "version": "x.y.z",
  "purl": "pkg:pypi/cryptography@x.y.z",
  "licenses": [ { "expression": "Apache-2.0 OR BSD-3-Clause" } ]
}

{
  "type": "cryptographic-asset",
  "bom-ref": "crypto/0550a8cc-2451-4f06-90be-2b1c9ba1c2a9",
  "name": "RSA",
  "description": "Import of rsa from cryptography.hazmat.primitives.asymmetric discovered in pkcs7.py:19",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "pke"
    }
  },
  "evidence": {
    "occurrences": [
      {
        "location": "src/cryptography/hazmat/primitives/serialization/pkcs7.py",
        "line": 19
      }
    ]
  },
  "properties": [
    {
      "name": "cryptagion:source:scope",
      "value": "production"
    }
  ]
}

The SBOM says the library is present. It does not say that the PKCS#7 serialisation module depends on RSA, a quantum-vulnerable public-key algorithm. In our pinned scan of pyca/cryptography, the 243 Python files produced 1,804 detections in the CBOM: 46 in library source, 1,746 in tests and 12 in documentation scripts. That is the level of detail a migration team needs, and the scope split is what stops test vectors from being counted as production risk.

Both files are open: the full CBOM and its validation record, including the stated limits (the Python scan does not cover the library’s Rust code, and the CBOM does not contain a complete dependency graph).

What an SBOM cannot tell you

• Cryptography in your own code. An SBOM describes what you depend on. A hard-coded RSA.generate(1024) in your application, or a home-made hash function, is not a component.
• How a library is used. Shipping OpenSSL tells you nothing about which algorithms, key sizes or modes your code asks it for. Two applications with the same SBOM line can have very different quantum exposure.
• Certificates and live endpoints. X.509 certificates, TLS configurations and the cipher suites a server actually negotiates live outside the build. They are cryptographic assets, not software components.
• Parameters. Whether a use is RSA-2048 with OAEP or RSA-1024 with PKCS#1 v1.5 changes both the risk and the replacement.

What a CBOM does not replace

• Vulnerability management. A CBOM does not track CVEs in your dependencies. A vulnerable version of a cryptographic library is an SBOM finding.
• Licences and suppliers. These are SBOM concerns.
• The full dependency graph. A CBOM may reference the components that provide a cryptographic asset, but it is not designed to describe your whole supply chain.

What the Cyber Resilience Act asks for

The EU Cyber Resilience Act (Regulation 2024/2847) makes the SBOM a legal requirement for manufacturers of products with digital elements: Annex I, Part II requires them to identify and document components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. Reporting obligations apply from 11 September 2026; most other obligations from 11 December 2027.

The CRA does not name a CBOM. It does require, in Annex I, Part I, that products protect the confidentiality of data with state-of-the-art mechanisms such as encryption, and that they are designed to limit attack surfaces. Showing that your cryptography is state of the art, and will stay so through the post-quantum transition, requires knowing what it is. That is the CBOM’s job. Under DORA and NIS2 the case is the same: both expect cryptography to be governed, and the EU post-quantum roadmap asks for cryptographic inventories by the end of 2026.

How they work together

1. Use one format. CycloneDX 1.6 carries both software components and cryptographic-asset components, so the same tooling can store, validate and diff both.
2. Start from the SBOM to find where to look. Cryptographic libraries in the SBOM tell you which repositories and services are worth scanning first.
3. Use the CBOM to see what is actually used. Algorithms, parameters and locations, including the cryptography that no SBOM lists.
4. Regenerate both in CI. An SBOM and a CBOM produced on every release keep the inventory current and make changes reviewable.

Where CRYPTAGION fits

CRYPTAGION produces the CBOM, not the SBOM: keep the SBOM tool you already use. It discovers cryptography in Python, JavaScript/TypeScript, Java, Go and C/C++ source, X.509 certificates and live TLS endpoints, and exports a schema-validated CycloneDX 1.6 CBOM with the file and line, or endpoint, of every finding. Risk scores and migration recommendations are kept in separate outputs, so the CBOM stays a portable inventory. Evaluating tools? Use our CBOM tool evaluation checklist.

Sources

• CycloneDX 1.6 JSON reference
• Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 71 and Annex I
• Commission Recommendation (EU) 2024/1101 on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography
• CRYPTAGION: Python CBOM example, pyca/cryptography (10 October 2026)

← All resources · Home