How to Use CBOMs in Containerized Environments: Data Formats, Tools, and Use Cases

The first blog in this series introduces a Cryptographic Bill of Materials (CBOM), its elements, and why it is important in container security. 

This blog focuses on practical aspects for container image teams and broader enterprises. It goes into generating CBOM and interpreting their outputs into cryptographic inventory and vulnerability management processes.

‍

CBOM Data Formats and Schemas

Most practical CBOM implementations today are built on top of existing SBOM formats, with CycloneDX being especially prominent. Within these ecosystems, CBOM data is typically expressed as JSON or XML documents that adhere to CycloneDX schemas and incorporate extensions for cryptographic objects. 

These documents contain structured elements that describe algorithms, keys, certificates, and cryptographic libraries, all of which reference the relevant software components identified in the SBOM. 

Additionally, CBOMs may include optional metadata fields that address risk, policy compliance, and post-quantum readiness, providing a comprehensive and machine-readable view of an organization’s cryptographic landscape. Because these formats are machine‑readable, they can be consumed by scanners, dashboards, and automation tools for continuous monitoring.

‍

Tools That Generate and Consume CBOMs

A number of new tools and platforms now support the generation and consumption of CBOMs as part of SBOM capabilities. These solutions typically analyze source code, binaries, and configuration files to detect cryptographic libraries and API usage, while also inspecting container images and runtime environments to identify keys, certificates, and protocol configurations. 

Once discovered, these tools produce CBOM artifacts in CycloneDX or similar formats and link them to existing SBOMs, creating a comprehensive inventory that integrates cryptographic assets with overall software component tracking.

Specialized tools are essential for scanning source code and binaries during the CI/CD process. For example: 

• CycloneDX Generator (cdxgen) is a versatile command-line tool that can generate CBOMs for various programming languages by discovering cryptographic libraries and identifying algorithm usage. 
• ReversingLabs Spectra Assure scans binary software packages, container images, and VM disk images and can output CBOMs in addition to other data formats. 
• IBM Research has developed dedicated CBOM tools to extract cryptographic assets from Java and other platforms and has plans to release a CBOM Generator Tool for open source Git repositories. 

‍

CBOM Example: Containerized Service

Below is a simplified, illustrative JSON snippet structure showing how a CBOM for a single containerized service might look in an environment:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "components": [
    {
      "type": "container",
      "name": "application1-api",
      "version": "3.4.2",
      "purl": "pkg:docker/our-registry/application1-api@3.4.2"
    }
  ],
  "crypto": {
    "libraries": [
      {
        "componentRef": "pkg:docker/our-registry/application1-api@3.4.2",
        "name": "OpenSSL",
        "version": "3.0.12",
        "policyStatus": "approved"
      }
    ],
    "algorithms": [
      {
        "id": "alg-1",
        "name": "AES",
        "mode": "GCM",
        "keySize": 256,
        "usage": ["tls-data-protection"],
        "policyStatus": "approved"
      },
      {
        "id": "alg-2",
        "name": "SHA-1",
        "usage": ["legacy-internal-api"],
        "policyStatus": "deprecated"
      }
    ],
    "keys": [
      {
        "id": "key-1",
        "type": "rsa",
        "size": 2048,
        "location": "kubernetes-secret",
        "usage": ["tls-server-auth"],
        "policyStatus": "approved"
      }
    ],
    "certificates": [
      {
        "id": "cert-1",
        "subject": "CN=application1-api.prod",
        "issuer": "CN=Internal-CA",
        "notAfter": "2026-03-15T00:00:00Z",
        "keyRef": "key-1",
        "policyStatus": "approved"
      }
    ],
    "endpoints": [
      {
        "service": "application1-api",
        "url": "https://application1.prod.internal",
        "protocol": "TLS",
        "supportedVersions": ["1.2", "1.3"],
        "preferredCipherSuites": [
          "TLS_AES_256_GCM_SHA384",
          "TLS_CHACHA20_POLY1305_SHA256"
        ],
        "policyStatus": "approved"
      }
    ]
  }
}

‍

Overall, this CBOM snippet documents the cryptographic posture of a containerized microservice, mapping its crypto libraries, algorithms, keys, certificates, and endpoint configurations. It also highlights policy compliance, such as deprecated algorithm usage, to support audits, risk management, and proactive cryptographic maintenance as described in the surrounding context.

‍

Operationalizing CBOM Data

Security and operations teams can leverage CBOM outputs to confirm that deprecated algorithms such as RC4, MD5, and SHA-1 are not present in their environments and to ensure that policies are enforced if these algorithms are detected. This information also enables proactive planning for certificate rotation and key upgrades before expiration dates or policy deadlines, minimizing risks associated with outdated cryptographic assets. 

Additionally, teams can analyze CBOM data to identify services that may require significant modifications during a post-quantum migration, particularly those that rely extensively on RSA or ECC cryptography. When integrated into dashboards, CBOM data provides heat maps of cryptographic risk and coverage across containers, clusters, and environments.

A mature CBOM program gives organizations a clear, centralized view of all cryptography used in their applications, containers, APIs, and infrastructure including outdated or unauthorized libraries. This inventory maps cryptographic assets to business services and data flows, making it easier to assess risks and prioritize fixes. 

By continuously tracking crypto-related vulnerabilities and policy issues, CBOMs help teams manage risks more effectively. Integrating CBOM outputs with tools like configuration management databases (CMDBs), key managers, and certificate managers, will allow organizations to switch from patching problems as they arise to proactively maintaining an enterprise-level strong and compliance-centric cryptographic posture.

CBOMs seamlessly integrate into vulnerability management and IT operations workflows by generating SBOM and CBOM artifacts during each container image build in CI/CD, storing them in artifact repositories, feeding CBOM data into security tools like vulnerability management systems and SIEM/SOAR platforms, enforcing policies for approved cryptographic standards and automatically flagging violations, and supporting remediation activities such as tracking crypto-related CVEs and CWEs, deprecations, and certificate rotations.

‍

CBOM as a Core Pillar of Container Security

To drive real progress in software supply chain security, container image teams should embrace the Container Bill of Materials (CBOM) as a core pillar of their operational strategy. By systematically documenting the components, dependencies, and build-time configurations of every image, you transform "black box" containers into transparent, auditable assets. 

This is more than just a compliance checkbox; it’s about gaining the granular visibility needed to respond to cryptographic vulnerabilities and misconfigurations in minutes rather than days. Container image teams should integrate CBOM generation into every CI/CD pipeline, ensuring that every image they ship is backed by a verifiable record of its integrity and provenance.