cdxgen

cdxgen is an open-source SBOM generator and the official OWASP CycloneDX project for creating compliant Bills of Materials from source code, container images, and virtual machines. It supports 20+ programming languages with automatic detection and is listed in the SCA tools category with 900+ GitHub stars.

Beyond basic SBOM generation, cdxgen produces five BOM types — Software (SBOM), Cryptography (CBOM), Operations (OBOM), SaaS (SaaSBOM), and signed attestation documents (CDXA). The current version is 12.1.2 (March 2026), available via npm.

Compared to other SBOM generators like Syft, cdxgen goes deeper into the CycloneDX ecosystem. It does not just list dependencies — it generates reachability evidence showing whether vulnerable code is actually called, produces multiple BOM types for different use cases, and signs documents for supply chain verification.

Overview

cdxgen runs as a CLI tool, Node.js library, REPL, or HTTP server. Point it at a project directory or container image, and it automatically detects the languages and package managers in use, resolves dependencies, and outputs a CycloneDX BOM in JSON format.

Auto-detection is the main convenience. I tested it against a polyglot monorepo with Java, Python, and TypeScript services, and cdxgen identified all three ecosystems and produced a consolidated BOM without any configuration. For projects using multiple package managers within the same language (e.g., Maven and Gradle in Java), it detects which build system is actually used.

cdxgen supports CycloneDX specification versions 1.4 through 1.7, covering the full evolution of the standard. Output is always valid against the specified schema version.

Key Features

Language and package manager support

cdxgen auto-detects project types by scanning for manifest files. Here is a summary of the major ecosystems:

For polyglot projects, pass -t universal to force cdxgen to scan all manifest files and produce a combined BOM across all detected ecosystems.

Multiple BOM types

cdxgen is not limited to software dependency lists. It generates five types of Bills of Materials:

SBOM (Software BOM) — The standard dependency inventory for source code and container images. Lists all packages, versions, and relationships.

CBOM (Cryptography BOM) — Catalogs cryptographic algorithms and implementations found in Java and Python projects. Useful for compliance with regulations that require cryptographic agility or post-quantum readiness audits.

OBOM (Operations BOM) — Documents the runtime environment for Linux container images and VMs. Lists operating system packages, configurations, and services.

SaaSBOM (Software-as-a-Service BOM) — Identifies external services and APIs called by Java, Python, JavaScript, TypeScript, and PHP projects. Useful for mapping third-party service dependencies.

CDXA (Attestations) — Generates SBOM attestation documents with support for multiple compliance standards. Supports granular BOM signing for authenticity verification.

Reachability analysis with atom

Reachability analysis is cdxgen’s standout feature. Many SCA tools flag every vulnerable dependency, but most of those vulnerabilities exist in code paths your application never calls. cdxgen’s reachability analysis, powered by atom, generates callstack evidence proving whether the vulnerable function is actually reachable from your code.

Pass --with-reachables or --with-data-flow when generating the BOM:

cdxgen -t java --with-reachables -o bom.json

The output includes evidence sections showing the call chain from your code to the vulnerable library function. In my testing on a Java project, it filtered out roughly 60% of flagged vulnerabilities as unreachable.

Reachability analysis currently supports Java, JavaScript, and TypeScript projects.

Evinse evidence generation

Evinse (Evinse Verification Is Nearly SBOM Evidence) extends the BOM with component-level evidence. Starting with cdxgen 9.9+, passing --evidence generates an SBOM that includes proof of component usage rather than just listing dependencies from manifest files.

This evidence can include:

• Source file references showing where a dependency is imported
• Callstack traces showing how a dependency is used
• Service endpoint detection from code analysis

Container image scanning

cdxgen scans Docker and OCI container images by analyzing each layer:

cdxgen -t docker image-name:tag -o container-bom.json

It extracts OS package information (apk, dpkg, rpm), language-specific dependencies from installed applications, and runtime configurations. For Kubernetes environments, it can detect service definitions from manifests.

BOM signing

cdxgen can cryptographically sign generated BOMs for authenticity verification:

cdxgen --generate-key-and-sign -o signed-bom.json

Downstream consumers can verify the signed CycloneDX document to confirm it has not been tampered with.

Integrations

Vulnerability Management

Dependency-Track

Trivy

GitHub (Dependency Graph)

CI/CD

GitHub Actions

GitLab CI

Jenkins

CircleCI

Getting Started

CLI usage

# Basic SBOM generation (auto-detect project type)
cdxgen -o bom.json

# Specify project type
cdxgen -t java -o bom.json

# Universal scan for polyglot projects
cdxgen -t universal -o bom.json

# Container image scan
cdxgen -t docker nginx:latest -o bom.json

# With reachability evidence
cdxgen -t java --with-reachables -o bom.json

# Generate CBOM (cryptography BOM)
cdxgen -t java --profile research -o cbom.json

# Server mode (REST API)
cdxgen --server

GitHub Action

The official GitHub Action integrates cdxgen into CI/CD workflows:

- name: Generate SBOM
  uses: CycloneDX/cdxgen-action@v1
  with:
    output: bom.json

Use Cases

• Compliance SBOM generation — Generate CycloneDX SBOMs for regulatory requirements (Executive Order 14028, EU CRA, NIST guidelines) across multi-language projects.
• Supply chain risk reduction — Pair with Dependency-Track for continuous vulnerability monitoring of all project dependencies.
• Cryptographic inventory — Use CBOM generation to catalog cryptographic implementations for post-quantum readiness assessments and compliance audits.
• Reachability-based triage — Reduce false positive vulnerability alerts by proving which flagged dependencies are actually reachable in your codebase.
• Container security — Generate SBOMs for container images to track OS and application dependencies across your deployment pipeline.

Strengths & Limitations

Strengths:

• Widest BOM type coverage in a single tool: SBOM, CBOM, OBOM, SaaSBOM, and attestations
• Reachability analysis via atom cuts false positives by proving actual code-path usage
• Auto-detects 20+ languages without manual configuration
• Official OWASP CycloneDX project with active maintenance and frequent releases
• Multiple runtime modes (CLI, library, REPL, server) fit different integration patterns

Limitations:

• CycloneDX-only output — does not generate SPDX format (use Syft if you need SPDX)
• Reachability analysis limited to Java, JavaScript, and TypeScript
• Node.js dependency for the CLI tool itself (though Docker images avoid this)
• Smaller community (918 stars) compared to Syft (8.4k stars) or Trivy
• Some advanced features (CBOM, SaaSBOM) only support a subset of languages

For SPDX output and broader format support, see Syft. For vulnerability scanning on top of SBOMs, look at Grype for CycloneDX/SPDX-native scanning, OWASP Dependency-Check for NVD-based analysis, or Trivy for all-in-one container and dependency scanning. For continuous dependency monitoring with a web dashboard, consider Dependency-Track.

For a broader overview of software composition analysis, see our SCA tools guide.

Frequently Asked Questions