> For the complete documentation index, see [llms.txt](https://docs.xygeni.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xygeni.io/xygeni-scanner-cli/xygeni-cli-overview/generate-cbom-with-the-xygeni-cli.md). # 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. {% hint style="info" %} On Windows, replace `xygeni` with `xygeni.ps1` in the examples below. {% endhint %} ## 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. {% hint style="info" %} 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](/xygeni-products/quantum-safe-compliance.md). {% endhint %} ## 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. {% hint style="info" %} `--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. {% endhint %} ## 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). ## 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 ```json { "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](/xygeni-products/quantum-safe-compliance.md) 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: ```yaml # 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): ```yaml # 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](/xygeni-products/quantum-safe-compliance.md) * [Generate SBOM with the Xygeni CLI](/xygeni-scanner-cli/xygeni-cli-overview/generate-sbom-with-the-xygeni-cli.md) * [Xygeni Scanner Reference](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-scanner-reference.md) * [Inventory Scanner](/xygeni-products/application-security-posture-management-aspm/inventory-scanner.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.xygeni.io/xygeni-scanner-cli/xygeni-cli-overview/generate-cbom-with-the-xygeni-cli.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.