CBOMkit Explained: IBM's Open-Source Tool for Cryptographic Discovery and CBOM Generation

NIST finalized ML-KEM, ML-DSA, and SLH-DSA in August 2024, and frameworks including NSA's CNSA 2.0 and CISA's post-quantum guidance now assume organizations are building cryptographic inventories as a precondition for migration.^{[NIST FIPS 203]} The operational problem this creates is straightforward: you cannot migrate cryptographic assets you have not located. Most enterprise environments have classical cryptography embedded across source code, container images, CI/CD pipelines, and TLS configurations — with no systematic record of where it lives or what version is in use. CBOMkit, originally developed by IBM Research Europe–Zurich and now stewarded by the Post-Quantum Cryptography Alliance (PQCA) under the Linux Foundation, is a purpose-built open-source toolchain designed to close that gap.^{[IBM Research]}

What Is a CBOM — and Why Your SBOM Isn't Enough

A Software Bill of Materials (SBOM) records software components and their dependencies. It does not, by design, enumerate the cryptographic primitives those components use, which keys or certificates they depend on, or whether the algorithms in use are quantum-vulnerable. A Cryptographic Bill of Materials (CBOM) is a structured extension that captures exactly that layer. CBOMkit extends the CycloneDX SBOM specification with cryptography-specific asset types — algorithms, keys, certificates, and protocols — and models the relationships between them using dependencyType fields (uses / implements).^{[IBM/CBOM GitHub]} Because CBOMkit outputs are fully CycloneDX-compatible, teams with existing SBOM tooling can consume CBOM artifacts without format conversion.

The distinction matters for compliance posture. CISA's post-quantum guidance and NSA's CNSA 2.0 roadmap both frame cryptographic inventory as a prerequisite capability, not an optional practice.^{[NSA CNSA 2.0]} No regulatory body has mandated CBOMkit specifically. The tool is a means to producing the inventory artifact that frameworks increasingly expect; it is not itself a compliance deliverable.

CBOMkit Architecture: Six Components, One Workflow

CBOMkit is not a single binary. It is a coordinated set of six named modules, each targeting a specific point in a typical DevSecOps pipeline.^{[IBM Research — Quantum-Safe CBOMkit]}

• CBOMkit-hyperion: A SonarQube plugin that performs static analysis of source code to identify cryptographic usage at the code level.
• CBOMkit-theia: Analyses Docker and OCI container images, scanning installed packages and libraries for cryptographic assets without requiring source access.
• CBOMkit-action: A GitHub Action that integrates CBOM generation directly into CI/CD pipelines, enabling per-commit or per-release cryptographic scanning.
• CBOMkit-coeus: A CBOM viewer that provides a human-readable interface for inspecting generated CBOM outputs.
• CBOMkit-themis: A compliance and policy engine that evaluates a generated CBOM against defined cryptographic policies, flagging assets that do not meet specified posture requirements.
• CBOMkit-mnemosyne: A centralized CBOM storage repository, enabling organizations to aggregate and track CBOM outputs across teams, repositories, and releases over time.

In a typical enterprise workflow, hyperion or theia generates the initial CBOM; themis evaluates it against policy; mnemosyne stores and versions the output for longitudinal tracking; and coeus provides the interface for analyst review. The action module enables this chain to run automatically on every code change without manual invocation.

What CBOMkit Scans — and What It Currently Misses

CBOMkit's documented scan targets include Java (JCA), Python (pyca/cryptography) source code, Git repositories, Docker and OCI container images, TLS certificates, secrets, and configurations.^{[CBOMkit GitHub — PQCA]} For organizations with Java or Python-dominant codebases running containerized workloads, coverage is meaningful and actionable from the first scan.

Security architects evaluating CBOMkit should be direct about the current boundaries. As of available documentation, multi-language support beyond Java and Python is a stated roadmap item, not a shipped capability. There are no published integration guides for Jenkins or GitLab CI. No public performance benchmarking data exists for large-scale enterprise scans. Teams operating Go, Rust, or C/C++ codebases as primary languages will find current coverage insufficient for a complete cryptographic inventory and should plan to complement CBOMkit with additional tooling or manual review for those stacks. IBM and the PQCA have indicated ongoing work to extend language and library coverage, but no public timeline for specific additions has been published.

Fitting CBOMkit Into Your Existing Toolchain

For teams already running Syft or Trivy for SBOM generation, CBOMkit is complementary rather than competitive. Syft and Trivy identify software components and known vulnerabilities; they do not enumerate cryptographic algorithm usage at the library call level. CBOMkit operates at the layer below component inventory — identifying which cryptographic primitives those components actually invoke. The two outputs can coexist in a CycloneDX-based inventory pipeline.

SonarQube users have the lowest adoption barrier. CBOMkit-hyperion installs as a standard SonarQube plugin, meaning teams with enterprise SonarQube deployments can add cryptographic scanning to existing code quality gates without standing up new infrastructure. For teams without SonarQube, CBOMkit-theia against container images is the lowest-friction entry point and requires no IDE integration, no CI/CD reconfiguration, and no organizational approval process beyond selecting a target image. Understanding crypto agility as an enterprise capability helps architects frame where CBOM outputs feed into longer-term migration architecture decisions.

Using Themis for Quantum-Safe Compliance Checks

CBOMkit-themis evaluates a generated CBOM against cryptographic policy rules, producing a report of assets that fail to meet defined requirements.^{[IBM Research — Quantum-Safe CBOMkit]} The built-in policies are designed to surface quantum-vulnerable algorithm usage — RSA, classical Diffie-Hellman, and elliptic curve primitives that NIST IR 8547 places on a deprecation path to 2030 and 2035.^{[NIST IR 8547]}

Architects should be aware that themis's policy customization capabilities are not extensively documented in public sources as of available data. Teams with organization-specific requirements — for example, enforcing CNSA 2.0 algorithm mandates for national security systems, or layering in sector-specific controls — will need to evaluate how far the built-in policy set extends before committing to themis as their primary compliance evaluation layer. The tool signals compliance posture gaps; it does not produce an audit report recognized by any named regulatory framework.

Getting Started: A Realistic Adoption Path for Enterprise Teams

CBOMkit is hosted under the cbomkit GitHub organization following its donation to the PQCA.^{[PQCA — CBOMkit Project]} A phased adoption approach suited to enterprise environments proceeds as follows:

Phase 1: Single Container Image Pilot

Pull CBOMkit-theia from the cbomkit GitHub organization and run it against one production container image from your current registry. This step requires one engineer and no organizational approval beyond selecting a target. The output — a CycloneDX-formatted CBOM identifying cryptographic libraries, algorithm references, and certificates in the image — gives your team a concrete artifact to anchor a broader cryptographic inventory conversation. This is the lowest-cost way to validate that the tool produces useful output in your specific environment before committing engineering time to deeper integration.

Phase 2: Source Code Scanning via Hyperion or CI Integration

For Java or Python codebases, add CBOMkit-hyperion to an existing SonarQube deployment or integrate CBOMkit-action into a GitHub Actions workflow. At this stage, the goal is coverage breadth: scanning the repositories that handle the most sensitive cryptographic operations first, such as authentication services, key management systems, and data-at-rest encryption layers. A structured CBOM data model helps teams prioritize which scan outputs require immediate remediation versus longer-term migration planning.

Phase 3: Centralized Inventory via Mnemosyne

Once multiple teams are generating CBOM outputs, CBOMkit-mnemosyne provides centralized storage and versioning. This is the point at which an organization moves from ad hoc cryptographic visibility to a maintained, auditable cryptographic inventory — the posture that CISA and NSA guidance frames as a baseline migration readiness capability. At this stage, themis policy checks can run automatically against each new CBOM submission, surfacing regressions where newly introduced dependencies bring in deprecated algorithms.

Before scaling to Phase 3, architects should document which scan targets are outside current CBOMkit coverage — Go services, C libraries, and non-GitHub CI pipelines — and identify interim discovery methods for those gaps. An incomplete inventory that is clearly scoped is more defensible than one with unknown boundaries.

Key Takeaways

• CBOMkit is an open-source toolchain developed by IBM Research Europe–Zurich and now stewarded by the Post-Quantum Cryptography Alliance under the Linux Foundation. It is not a commercial product.
• The tool extends the CycloneDX SBOM specification with cryptography-specific asset types and produces outputs compatible with existing CycloneDX tooling.
• Six named modules cover source code scanning (hyperion), container analysis (theia), CI/CD integration (action), CBOM viewing (coeus), compliance checking (themis), and centralized storage (mnemosyne).
• Documented language support covers Java (JCA) and Python (pyca/cryptography). Multi-language coverage beyond these is a stated roadmap item, not a current capability.
• No regulatory body mandates CBOMkit. The cryptographic inventory outputs it produces align with CISA post-quantum guidance and NSA CNSA 2.0 posture expectations.
• CBOMkit-theia against a single container image is the lowest-friction entry point: one engineer, no infrastructure changes, actionable output in under an hour.
• Teams should document coverage gaps — unsupported languages, non-GitHub pipelines — before treating CBOMkit output as a complete organizational cryptographic inventory.

The concrete next step is to review the CBOMkit module documentation on the PQCA-hosted cbomkit GitHub repository, identify one production container image in your registry, and run CBOMkit-theia to generate your first CBOM output. That single artifact will define the scope of your initial cryptographic inventory conversation more precisely than any planning document can.

Related Reading

On this site:

• Cryptographic Bill of Materials: practitioner architecture guide
• Crypto agility as an enterprise migration capability
• CBOM data model and discovery methods for PQC migration

Primary sources:

• PQCA CBOMkit project governance and scope documentation
• IBM Research technical overview of CBOMkit architecture and modules
• NIST IR 8547: algorithm deprecation timeline for RSA and ECC

This article draws on primary documentation from IBM Research publications, the PQCA CBOMkit project page, the cbomkit and IBM/CBOM GitHub repositories, NIST CSRC, and NSA CNSA 2.0 guidance. All claims verified against official sources as of April 2026.