What is a Crytographic Bill of Materials (CBOM)? - and Why Your Organization Needs One

Modern enterprise infrastructure runs on a bedrock of cryptography. Every secure transaction, every API call, and every identity verification relies on a complex web of algorithms, libraries, and protocols. Yet, for most organizations, this layer remains opaque—a "black box" of trusted dependencies that are rarely audited until a vulnerability strikes or a compliance mandate forces a fire drill.

As the industry hurtles toward the Post-Quantum Cryptography (PQC) era, this lack of visibility has shifted from a technical debt issue to a material business risk. To manage this transition effectively, security leaders are turning to a new standard of transparency: the Cryptographic Bill of Materials (CBOM).

This article explores what a CBOM is, the technical standards (CycloneDX) that define it, and how it serves as the static foundation for a broader, dynamic cryptographic strategy.

CBOM Defined: The "Ingredients Label" for Your Encryption

A Cryptographic Bill of Materials (CBOM) is a structured, machine-readable inventory of the cryptographic assets embedded within a piece of software. Much like a standard Software Bill of Materials (SBOM) lists the open-source libraries and components in an application, a CBOM specifically catalogs the cryptographic capabilities inherent in that release.

It answers the fundamental question: "What cryptography is this software capable of performing?"

Crucially, a CBOM is a static artifact. It captures the state of an application at the moment of build or release. It lists the algorithms (e.g., AES-256, RSA-2048), the specific libraries implementing them (e.g., OpenSSL 3.0, Bouncy Castle), and the key types supported.

However, it is vital to distinguish the CBOM from the Operational Cryptographic Inventory.

• The CBOM tells you what is in the box (e.g., "This app contains the OpenSSL library capable of TLS 1.3").

• The Inventory tells you what is happening in production (e.g., "This app is actually configured to use TLS 1.2 with a weak cipher suite"). The CBOM is your baseline for software assurance; the inventory is your reality check for risk management.

The Anatomy of a CBOM: What’s Inside?

A high-quality CBOM goes far beyond a simple text list. It is a dense, hierarchical dataset designed to be parsed by policy engines and risk management platforms. According to the OWASP Authoritative Guide to CBOM, a valid CBOM utilizes the CycloneDX object model to capture four distinct categories of data:

• Cryptographic Assets & Algorithms: This captures the mathematical functions (encryption, hashing, signatures) with granular detail. Crucially for the post-quantum era, this includes the NIST Quantum Security Level and classical Security Level properties, allowing automated scanners to instantly grade an application's PQC readiness.

• Dependencies & Implementation Relationships: Unlike a standard SBOM, a CBOM distinguishes between implementation and usage. It maps which libraries provide specific cryptographic functions (e.g., OpenSSL implements TLS 1.3) versus which applications dependOn them, enabling precise impact analysis when a specific library vulnerability is discovered.

• Related Cryptographic Material & Key States: This category inventories keys, secrets, tokens, and certificates. Beyond just key lengths, it aligns with NIST SP 800-57 to track Key Management States (e.g., pre-activation, active, compromised, destroyed), allowing teams to flag risky artifacts like "active" keys that should have been decommissioned.

• Properties & Certification Metadata: Essential context for compliance, including Object Identifiers (OIDs) for precise algorithm identification, Execution Environments (e.g., Software-Plain-RAM vs. HSM), and Certification Levels (e.g., FIPS 140-3) to validate that the crypto implementation meets regulatory assurance standards.

The Standard: CycloneDX

The industry has coalesced around CycloneDX as the de facto standard for CBOMs. While originally an SBOM standard, CycloneDX has aggressively expanded its schema to support the nuance of modern cryptography.

CycloneDX 1.6 (Released April 2024) was the watershed moment for CBOMs. It introduced the crypto Properties extension, allowing developers to formally define cryptographic assets as distinct components. For the first time, teams could use standardized fields like assetType (to distinguish a certificate from an algorithm), primitive (categorizing functions like signatures vs. encryption), and execution Environment (tracking if crypto is executed in software, an HSM, or a TEE).

CycloneDX 1.7 (Released October 2025) refined this further, specifically targeting PQC readiness. It introduced a standardized enumeration of Elliptic Curves, replacing previous free-text fields. This allows automated scanners to instantly flag "unsafe" curves that are vulnerable to quantum attacks. It also added the Algorithm Family object, which solves the naming ambiguity problem (e.g., normalizing "RSA-PKCS1-1.5" and "RSA" under a single verifiable family) and added support for Patent Assertions, a critical feature for legal due diligence in the supply chain.

Creating the CBOM: A "Shift Left" Approach

You cannot build a CBOM manually. The complexity of modern dependency trees makes manual tracking impossible. Instead, CBOM generation is automated and integrated into the CI/CD pipeline.

The primary method is source code analysis. During the build process, scanners parse the code for calls to known cryptographic APIs and libraries. They map these calls to the CycloneDX schema, generating a .json or .xml artifact that travels with the release. This process is often augmented by binary analysis, which inspects compiled artifacts to catch statically linked libraries that source code scanning might miss. This dual approach ensures that even third-party "black box" components are fingerprinted.

The Strategic Value of the CBOM

Why are CISOs and compliance officers prioritizing CBOMs now?

1. Automated Policy Enforcement: You can block a build before it ever reaches production if the CBOM reveals the presence of a banned algorithm (like SHA-1 or MD5). This moves security from "detect and fix" to "prevent."

2. Supply Chain Due Diligence: Before purchasing software, organizations are beginning to request a CBOM alongside the SBOM. This allows you to assess the "cryptographic hygiene" of a vendor—if they are selling you a "secure" platform that relies on deprecated encryption libraries, the CBOM will reveal it. Ensuring this level of visibility is a core component of the 4 Pillars of Cryptographic Hygiene required to secure your organization in the post-quantum era.

3. Accelerated Vulnerability Triage: When the next "Heartbleed" or library-specific vulnerability occurs, you don't need to scan your entire network. You simply query your repository of CBOMs to see exactly which software releases contain the affected library version.

4. PQC Migration Planning: You cannot migrate what you cannot measure. A CBOM provides the granular data needed to identify every instance of classical, quantum-vulnerable cryptography (like RSA or ECC) in your environment, allowing you to prioritize upgrades to quantum-safe alternatives (like CRYSTALS-Kyber or Dilithium).

Closing the Loop: From Static CBOM to Dynamic Reality

While the CBOM is indispensable for software assurance, it has limits. A CBOM might tell you that an application contains a library capable of weak encryption, but it won't tell you if that weak encryption is enabled and listening on the public internet.

This is where Qinsight bridges the gap.

Qinsight doesn't just provide a static cryptographic inventory. Along with our cryptographic discovery capabilities, Qinsight Atlas enriches cryptographic inventory with org-level context such as ownership, system criticality, location and more, to help you operationalize your cryptographic data.

By combining the "intent" of the CBOM with the "reality" of the inventory, Qinsight provides the only complete picture of your cryptographic posture and the necessary information needed for remediation. Whether you are preparing for a PQC migration, satisfying a strict compliance audit, or simply trying to get a handle on your keys and certificates, Qinsight turns invisible risk into manageable data.