Cryptographic Inventory
SBOM and Cryptography: Why Your Software Bill of Materials Is Incomplete Without Crypto
SBOM inventories software components. CBOM inventories cryptographic assets. Learn why both are needed for complete supply chain visibility and PQC migration readiness.
SBOM and Cryptography: Why Your Software Bill of Materials Is Incomplete Without Crypto Your organization has invested in SBOM. You know which open source libraries are in your applications. You know which versions. You know about Log4Shell before the CVE drops. That is good security practice — but it is incomplete. Your SBOM tells you that OpenSSL 3.0 is in your application. It does not tell you that OpenSSL 3.0 is configured with RSA 2048 for TLS, with SHA 256 signatures, on a certificate that expires in 45 days — protecting customer PII that must remain confidential for 10+ years under regulatory requirements. That is what a Cryptographic Bill of Materials (CBOM) adds. This article explains why SBOM and CBOM are complementary, what each covers, and how to build both for complete software supply chain visibility. For related context, see cryptographic inventory and CBOM work. What SBOM Covers (and What It Doesn't) A Software Bill of Materials answers: What software components are in this application? What versions are they? What are their dependencies? Are any of them known vulnerable? For related context, see CBOM fundamentals. SBOM is built for vulnerability management. It tells you when you need to patch a library. It does not tell you: Which cryptographic algorithms those libraries are configured to use What key sizes are in play Which TLS certificates protect which endpoints Whether any of those algorithms are quantum vulnerable Which cryptographic assets are managed by third parties For related context, see crypto agility planning. This is not a flaw in SBOM. It is a scope boundary. SBOM inventories software components. CBOM inventories cryptographic components. You need both. What CBOM Adds A CBOM, standardized in CycloneDX 1.6, adds cryptographic specific data to the software inventory: Algorithms: Which algorithms (RSA, ECC, AES, ML KEM) are in use, where, and in what mode Certificates: Subject, issuer, key size, signature algorithm, validity period, SAN entries Protocols: TLS version, cipher suites, key exchange mechanism Keys: Where keys are generated, stored, and managed Libraries: Which crypto libraries are linked and what they expose Vendors: Which third parties manage cryptographic assets on your behalf A CBOM can answer questions an SBOM cannot: "If we need to replace RSA 2048 everywhere in our environment, which systems, services, certificates, and vendors are affected?" The Regulatory Direction Regulatory frameworks are converging on requiring both SBOM and CBOM: EU Cyber Resilience Act: SBOM required for digital products by December 2027. CBOM expected to follow as cryptographic visibility becomes a distinct regulatory requirement. OMB M 23 02: US federal agencies must submit annual cryptographic inventories. The recommended format aligns with CBOM. PCI DSS 4.0: Requirement 4 (encrypt cardholder data in transit) and Requirement 3 (protect stored data) both require knowing which cryptographic controls are in place — which requires an inventory. CNSA 2.0: Mandates specific algorithms for national security systems. Compliance requires knowing where non compliant algorithms exist. Organizations that build CBOM alongside SBOM today will be ahead of the regulatory curve — and will have a much easier PQC migration. How to Build Both Step 1: SBOM first. Use tools like Syft, CycloneDX Generator, or your CI/CD pipeline to generate an SBOM for each application. Step 2: Add CBOM from external discovery. Run an external cryptogr