From SBOM to CBOM: Why Container Security Needs Cryptographic Visibility

Cryptography plays an important role in container security. Cryptographic visibility and control starts with understanding how cryptography is implemented and used by the components within container images. This need is addressed through the Cryptographic Bill of Materials (CBOM).

In this blog, we will introduce the CBOM, what it contains, how it works with the software bill of materials (SBOM), and why container image teams should care about both.

‍

What is an SBOM?

An SBOM is a machine‑readable inventory of all components, libraries, and dependencies that make up a piece of software such as a container image. It is often referred to as a “nutrition label” for your applications. If you are building and deploying container images, you likely already use SBOMs to list things like base images, operating system packages, application frameworks, and open‑source libraries with their versions inside your layers.

For container images, SBOMs are used to:

• Improve vulnerability management by mapping known CVEs to specific components in an image.
• Support supply chain security by making transitive dependencies and third‑party code visible.
• Help with compliance and license management for open‑source software.

Common SBOM formats include SPDX and CycloneDX, both of which are widely supported by commercial container image providers, container scanners, and CI/CD tooling.

‍

The Cryptography Gap in SBOMs

Although SBOMs expose vulnerable software components, they do not provide information on the cryptographic components included and configured within the images or their utilization in safeguarding the images and cryptographic functions they offer. 

For instance, an SBOM may indicate that a container includes OpenSSL, but it does not specify whether it employs non-compliant cryptography, deprecated ciphers, short RSA keys, or weak hashes such as MD5.

This gap becomes critical when considering:

• Cryptographic vulnerabilities such as weak algorithms (e.g., RC4, MD5) and deprecated protocols.
• Cryptographic misconfigurations (e.g., insecure modes, short key lengths, missing certificate validation). 
• Cryptographic compliance such as using FIPS 140-3 validated cryptography for the U.S. government and regulations like PCI DSS v4.0.1.
• Crypto agility and prioritization for long‑term quantum‑safety planning as quantum computing advances, where organizations must understand where classical public‑key algorithms (RSA, ECC) are used and replace them with NIST standardized quantum resistant cryptography.

In essence, a Software Bill of Materials (SBOMs) provides information about the software components present in an environment, but it does not address the question of what cryptography is used by the software and whether it is secure. This is where the CBOM comes into play.

‍

What is a CBOM?

A CBOM is a structured, machine‑readable inventory of all cryptographic assets in a system. It includes algorithms, keys, certificates, crypto libraries, and protocols as related to software components. It extends the SBOM concept by focusing specifically on cryptographic primitives, materials, and configurations.

While the concept of a "Bill of Materials" for software gained mainstream traction around 2021 following the US Executive Order 14028 and the NIST Secure Software Development Framework (SSDF), the CBOM emerged more recently as a specialized extension. 

In 2023, the OWASP CycloneDX project formally introduced the CBOM as a standard. With the release of NIST’s Post-Quantum Cryptography (PQC) standards in 2024, CBOM has become the "source of truth" for organizations planning their migration to quantum-safe cryptography.

‍

Why CBOMs are Important for Security

High‑profile supply chain attacks such as the SolarWinds Orion compromise underlined the importance of understanding not just which components are present but how they are secured. In these examples, the attackers didn't just steal data; they compromised the build process. A CBOM provides an extra layer of supply chain integrity. If your CBOM suddenly shows a new, unexpected cryptographic provider or a change in signing keys between build versions, it can detect a potential compromise.

While SBOMs help identify compromised or tampered components, CBOMs add value by revealing where compromised components have access to sensitive keys or cryptographic material, showing which services rely on potentially affected certificate chains or cryptographic libraries, and providing a basis for continuous verification of cryptographic integrity across development, build, and deployment pipelines. 

This combination supports a more robust response to supply chain incidents by narrowing the blast radius and focusing remediation on cryptographically sensitive areas.

‍

What does a CBOM include?

Depending on the implementation and format, often CycloneDX‑based, a CBOM may include:

• Algorithms and protocols: Symmetric and asymmetric algorithms (e.g., AES, RSA, ECDSA), hash functions (e.g., SHA‑256, SHA‑3), protocols (e.g., TLS 1.2/1.3, SSH).
• Modes and parameters: Cipher modes (e.g., GCM, CBC), padding schemes (e.g., OAEP, PSS), key lengths, elliptic curve choices.
• Keys and certificates: Key types, key sizes, storage locations (e.g., HSM, file, keystore), certificate chains, expiration dates.
• Crypto libraries and modules: Which libraries (e.g., OpenSSL, BoringSSL, Bouncy Castle) are used by which components.
• Usage context: Which endpoints, services, or containers use which crypto configurations.
• Risk metadata: Known CVEs/CWEs, compliance and regulatory policy violations such as non‑approved algorithms, and recommended remediations.

These elements are represented in a structured schema that can link back to SBOM component identifiers for consistent asset tracking.

‍

Why CBOMs Matter for Container Security

By enumerating algorithms and configurations, CBOMs help organizations programmatically identify, block, and phase out vulnerable and deprecated cryptography to modern and secure cryptography. For example, it can help container image teams to:

• Detect the use of outdated and vulnerable algorithms such as RC4 and MD5, which have well‑documented cryptographic weaknesses and should no longer be used in secure protocols.
• Find usages of weak hash functions (e.g., SHA‑1) in signatures and certificates, which can be exploitable in collision or preimage attacks.
• Highlighting insecure protocol versions and cipher suites that are prone to downgrade attacks, where an attacker forces a protocol connection to use weaker cryptography (e.g., TLS 1.0).
• Prioritize remediation during incidents like protocol deprecations or crypto‑library CVEs.
• Prepare for post‑quantum migrations by locating classical public key cryptography like DH, RSA, DSA, and ECC usage across microservices.

Because CBOMs associate crypto settings with specific services and code paths, container image teams can prioritize changes and verify that secure defaults are consistently enforced.

‍

How SBOMs and CBOMs Work Together

The SBOM and CBOM are complementary. SBOM maps software components and their versions while CBOM maps the cryptography used by those components, including how and where it is invoked.

Used together, they provide full visibility of software risk which include component vulnerabilities and cryptographic weaknesses. They help meet the regulatory and compliance requirements such as FIPS 140-3 cryptography and key management specified in organizations’ cryptography policy.

‍

CBOM and SBOM Interoperability

From a standards and data format perspective, current CBOM efforts are most mature within the CycloneDX ecosystem, with industry guidance emerging from various organizations. To ensure interoperability, CBOMs represented in JSON or XML are designed to work alongside SBOMs rather than replace them, and they align in the following ways: 

• CBOM entries link to SBOM components via consistent identifiers (e.g., package URLs) so that each cryptographic asset is associated with the software that uses it. 
• Standards such as CycloneDX v1.4+ provide schemas for representing cryptographic objects as extensions to an SBOM document
• Existing SBOM formats like SPDX can be complemented with separate CBOM artifacts, especially in complex environments. 

SPDX v3.0.1 does not currently have a dedicated cryptography-specific object model and it is missing a rich, standardized schema specific to cryptographic assets such as algorithms, keys, certificates, or cipher suites. Notably, there is a plan to provide support for more granular cryptographic metadata in the next release. 

Organizations that want CBOM-like coverage with SPDX today typically either model cryptographic information using generic SPDX fields and security extensions, or pair SPDX SBOMs with a CycloneDX-based CBOM or other specialized schema, rather than relying on native CBOM support in SPDX itself.

‍

‍

Where CBOMs Fit in Security and Operations

The benefits of CBOMs to the organization’s security posture are immediate and tangible. CBOMs integrate into the secure software development lifecycle and IT management processes in several places. Typical use cases include:

• Secure design and threat modeling: In architecture reviews, CBOM data supports validating algorithms, key lengths, and protocols to ensure compliance with organizational crypto policies and regulations.

• DevSecOps and CI/CD: CBOM generation can be automated in build pipelines alongside SBOM creation and security testing as part of your container image.
• Change management: When rotating keys, managing certificate renewals and rotation, updating crypto libraries, or deprecating algorithms, CBOMs provide an inventory of what will be affected.

CBOM artifacts support audits for standards that mandate strong cryptography and proper key management practices. CBOM characteristics that make this possible include machine‑readability, integration with existing SBOM tooling, and support for policy metadata that aligns with enterprise crypto standards for support crypto agility.

‍

In the next blog, we will look at CBOM data formats, use cases, and example tools and data outputs.