Generate CBOM with the Xygeni CLI

A Cryptographic Bill of Materials (CBOM) is a structured inventory of every cryptographic asset — algorithm, protocol, certificate, and key material — found in your project. Xygeni produces CycloneDX 1.6 CBOM JSON using the inventory --cbom command.

The inventory is not limited to source code. A great deal of the cryptography a system actually uses is never named in code: it is declared in configuration — the cipher suites an SSH daemon negotiates, the signing algorithm a service verifies its tokens with, the password-hash cost factor — or declared by infrastructure, such as the security policy on a load-balancer listener or the certificate a managed service presents. Xygeni reads all three.

On Windows, replace xygeni with xygeni.ps1 in the examples below.

What the CBOM covers

Xygeni emits four types of cryptographic asset:

Asset type	Examples
Algorithm	AES-256-GCM, SHA-256, RSA-3072, Ed25519, MD5 (weak), DES (weak)
Protocol	TLS 1.3, TLS 1.2, and the cipher suites an endpoint enables
Certificate	Certificate files on disk (PEM/DER), and certificates a system declares without shipping them — a managed certificate identified by its domain, a Kubernetes TLS secret, a certificate path on the deployed host
Related material	PBKDF2 key derivation, key wrapping, IV/salt references, keys a managed service holds (identified by their key spec)

Each asset is found through one of these channels:

Where it is found	What Xygeni reads
Source code	Cryptographic calls in Java, Kotlin, JavaScript/TypeScript, Python, Go, C#, PHP and Swift.
Application configuration	Catalogued cryptographic settings in the configuration files of common frameworks and servers — for example the key-exchange, cipher and MAC lists of an SSH daemon, a JWT signing algorithm, a TLS protocol floor or cipher list, a key-store reference, or a password-hash work factor. Files are matched by name as well as by extension, so a file such as sshd_config is read wherever it sits in the project.
Infrastructure as code	Cryptography a template declares: a minimum TLS version, a named load-balancer security policy (and the cipher suites that policy stands for), a managed certificate, a KMS or key-vault key spec.
Certificate and key files	X.509 certificates on disk, and the presence of private-key material.
Dependencies	The provider library that implements a detected asset (BouncyCastle, OpenSSL…), attributed from the dependency manifests.

A declared cipher suite is decomposed into the algorithms it names, so TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 contributes the key-exchange, signature, cipher and hash assets rather than a single opaque string.

Cryptography declared in configuration or infrastructure is recorded as presence and location only. Certificate bytes and private keys are never read into the CBOM, and a value the scanner cannot resolve to a literal — an environment placeholder, a template variable resolved at apply time — is skipped rather than guessed.

The coverage map (--crypto-coverage) states, per channel, what was scanned and what the known limits are. See Quantum-Safe Compliance & CBOM.

Running a CBOM scan

--cbom turns cryptographic discovery on. The discovered assets travel inside the inventory report — uploaded to Xygeni, written with -o, or printed to the console — so they reach the platform, the guardrails and the compliance standards without any extra file:

xygeni inventory --cbom

Add --cbom-file when you also want the CycloneDX 1.6 document on disk, for archiving or for a tool of your own:

xygeni inventory --cbom --cbom-file cbom-output.json

To scan a specific directory:

xygeni inventory --dir /path/to/project --cbom --cbom-file cbom-output.json

--cbom-file always writes CycloneDX 1.6. No --sbom-format is required, and it does not affect the SBOM's format.

--cbom on its own is not wasted work: the crypto assets still reach the Inventory panels through the upload, still feed a --fail-on guardrail (on crypto when quantumRisk = "shor-broken"), and still feed the compliance phase of a scan run. Use --cbom-file when you need the document itself.

Generating SBOM and CBOM together

The CBOM options are independent from --sbom / --sbom-format: a single inventory invocation can emit both an SBOM and a CBOM, each to its own file, in one pass over the project. This is the recommended way to produce both artifacts in CI — the scanner walks the codebase once and the two reports are guaranteed to describe the same revision.

xygeni inventory --dir /path/to/project \
                 --sbom sbom.json --sbom-format cyclonedx \
                 --cbom --cbom-file cbom.json

This produces:

• sbom.json — the dependency SBOM in the format selected by --sbom-format (cyclonedx or spdx).

• cbom.json — the Cryptographic BOM, always CycloneDX 1.6.

Notes:

• --sbom and --sbom-format must always be used together. --cbom may be used with or without them.

• --cbom-file requires --cbom.

• The two outputs are written to separate files; do not point --sbom and --cbom-file at the same path.

• When --sbom-format is cyclonedx, the SBOM and CBOM share the CycloneDX schema family but are distinct documents (one describes components/dependencies, the other describes cryptographic assets).

Across an organization or a monorepo

org-scan (every repository of an organization) and multi-scan (every project directory of a monorepo) accept the same two options, and run the cryptographic discovery once per scanned project:

xygeni org-scan --org my-org --run inventory --cbom --cbom-file cbom.json

Each project writes its own document. The filename you give is a template: it is prefixed with the project name, so a run over web and api leaves web_cbom.json and api_cbom.json side by side in the directory you named. --sbom and the -o reports follow the same rule, so nothing is overwritten from one project to the next.

Without --cbom-file, the cryptographic assets still travel inside each project's inventory report and reach the platform through the upload — one cryptographic inventory per project, and no local files to collect.

Cryptographic discovery parses the whole source tree, at a cost comparable to a SAST scan, and a fleet scan pays that cost once per project. Scanning a large organization with --cbom therefore takes substantially longer than the same scan without it. Where you only need the cryptographic inventory, narrow the run with --run inventory and with the repository filters (-ri, -re on org-scan; --path, -dp on multi-scan).

Understanding the output

The output is a CycloneDX 1.6 JSON file. Each cryptographic asset appears as a cryptographic-asset component with:

• cryptoProperties.assetType — algorithm, certificate, related-crypto-material, or protocol

• cryptoProperties.algorithmProperties — primitive, mode, parameterSetIdentifier (key size)

• cryptoProperties.protocolProperties — type and version, plus cipherSuites for an endpoint whose suites are known. Where a listener names a predefined provider policy instead of listing suites, Xygeni resolves the policy to the suites it enables and to the protocol version it accepts as a floor; each suite also names the algorithms it is built from, which appear as algorithm assets of their own.

• cryptoProperties.certificateProperties — subjectName, and the issuer, validity window and fingerprint when the certificate itself could be read. A certificate that is only declared carries the identity the declaration gives it and nothing more.

• evidence.occurrences — the exact file and line of every usage. For a declaration, the occurrence also names the resource and field it was declared on.

Assets are deduplicated: if AES-256-GCM is used in ten files, the CBOM carries one component with ten occurrences. This mirrors the IBM cbomkit convention.

Example output snippet

{
  "type": "cryptographic-asset",
  "name": "AES",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "ae",
      "mode": "GCM",
      "parameterSetIdentifier": "256"
    }
  },
  "evidence": {
    "occurrences": [
      { "location": "src/main/java/Crypto.java", "line": 42 },
      { "location": "src/main/python/crypto.py", "line": 17 }
    ]
  }
}

Quantum-risk classification

Every algorithm in the CBOM is classified by its quantum risk, so the inventory can be assessed for post-quantum readiness:

Classification	Meaning	Examples
shor-broken	Public-key cryptography broken by Shor's algorithm — must migrate	RSA, ECDSA, EdDSA, ECDH, DH, DSA
grover-weakened	Symmetric / hash weakened by Grover's — harden with larger sizes	AES-128, SHA-256
pqc-safe	Post-quantum algorithm	ML-KEM, ML-DSA, SLH-DSA

The classification is carried on each algorithm asset (exposed as the crypto.quantumRisk property on Xygeni-emitted CBOMs), together with a harvest-now-decrypt-later flag for confidentiality and key-establishment uses. This is the signal the post-quantum compliance standards evaluate.

Weak and broken algorithms

The CBOM is an inventory, not a policy gate. Weak algorithms (MD5, DES, RSA-1024, SHA-1) are included alongside strong ones. Use Xygeni's SAST scanner or policy rules to flag weak crypto as findings — the CBOM data feeds those rules automatically.

Those rules distinguish why a key is too short, because the remediation differs. A key that is adequate today but halved by Grover's algorithm (AES-128) is reported as not post-quantum ready. A key that is already brute-forceable by a classical attacker (a 56-bit DES key) is reported as both — and, unlike a public key that Shor's algorithm breaks, it is fixed by moving to a longer key rather than to a different algorithm family.

Using the CBOM for post-quantum compliance

The CBOM is the cryptographic inventory that the post-quantum compliance standards assess. Feed it to the compliance command for an auditable verdict against a transition mandate:

xygeni compliance -s nist_pqc_transition --cbom-file cbom.json

Or run discovery and compliance in a single pass — the inventory phase discovers the cryptography and the compliance phase reuses it, so the inventory is not computed twice. No file is needed for this, because the assets are handed straight to the compliance phase:

xygeni scan --cbom -s nist_pqc_transition

See Quantum-Safe Compliance & CBOM for the normative requirements behind this and the available post-quantum standards.

CI/CD integration

Add CBOM generation to any CI/CD pipeline by calling the scanner as a build step:

# GitHub Actions example — CBOM only
- name: Generate CBOM
  run: xygeni inventory --cbom --cbom-file ${{ github.workspace }}/cbom.json

To produce both an SBOM and a CBOM in the same job (one scan, two artifacts):

# GitHub Actions example — SBOM + CBOM in one step
- name: Generate SBOM and CBOM
  run: |
    xygeni inventory \
      --sbom ${{ github.workspace }}/sbom.json --sbom-format cyclonedx \
      --cbom --cbom-file ${{ github.workspace }}/cbom.json

Related pages

• Quantum-Safe Compliance & CBOM

• Generate SBOM with the Xygeni CLI

• Xygeni Scanner Reference

• Inventory Scanner