CBOM Manual: Cryptographic Inventories for DORA Work
How to generate CycloneDX 1.6 Cryptographic Bills of Materials with crypto-cbom and use them as inventory input for Digital Operational Resilience Act (DORA) work. A CBOM does not by itself establish compliance.
Executive Abstract
The EU Digital Operational Resilience Act (DORA) requires financial entities to maintain an ICT risk management framework, and its regulatory technical standards include requirements on encryption and cryptographic key management. Knowing which algorithms your systems use is a practical first step.
This guide shows how to produce that inventory as a CycloneDX 1.6 Cryptographic Bill of Materials (CBOM) with @sebastienrousseau/crypto-cbom, and how to flag weak algorithms in CI. It is not legal advice. Generating a CBOM does not make a system DORA compliant, and the tool has not been assessed by any supervisor or auditor. An earlier version of this guide attributed specific obligations and penalties to DORA Articles 13 and 14 and described features (SARIF output, evidence bundles, key-rotation proofs) that do not exist; those statements have been withdrawn.
Table of Contents
1. Where a Cryptographic Inventory Fits
DORA's ICT risk management requirements, and the regulatory technical standards made under it, expect financial entities to manage encryption and cryptographic keys deliberately. Check the regulation and the standards themselves, or your legal and compliance teams, for the exact obligations that apply to you.
Whatever the precise obligations, you cannot manage algorithms you have not inventoried. A CBOM gives a machine-readable list of the algorithms found in your code that you can review, track over time and feed into your own risk processes.
2. What a CBOM Contains
A CycloneDX 1.6 CBOM lists cryptographic assets as components with crypto-properties, such as the primitive, parameter set and the functions used. crypto-cbom builds these entries from the algorithm names it finds when scanning source files. The /v2/compliance/cbom endpoint of crypto-server returns a CBOM of the algorithms that service implements.
3. Generating and Auditing a CBOM in CI
Install @sebastienrousseau/crypto-cbom from npm (0.0.8 or later). Its CLI has two commands: scan writes a CycloneDX (or, with --format spdx, SPDX) CBOM, and audit validates a CBOM and prints an audit.
crypto-cbom scan src/ --format cyclonedx --output cbom.cdx.json
crypto-cbom audit cbom.cdx.json Because audit exits with status 1 when the inventory fails its checks, you can run it as a CI step to stop a pull request that introduces broken algorithms. It prints JSON; it does not produce SARIF or line-level annotations.
4. Algorithm Classification Used by the Audit
The audit classifies each asset by name. This is a heuristic based on the algorithm name, not a regulatory classification:
| Algorithm names matched | Audit classification | Suggested replacement |
|---|---|---|
| MD5, SHA-1, DES/3DES, RC4, ECB | Broken or deprecated | SHA-256/SHA-512; AES-256-GCM or ChaCha20-Poly1305 |
| RSA, ECC, ECDSA, Ed25519 | Vulnerable to a future quantum computer | Hybrid or post-quantum KEMs (ML-KEM) and signatures (ML-DSA) |
| AES-128, CBC mode | Transitional | AES-256-GCM or ChaCha20-Poly1305 |
| Other names (for example ML-KEM, ML-DSA) | Not flagged | None |
5. Third-Party Providers
DORA also covers the management of ICT third-party risk. When you depend on external software or service providers, consider asking them for a CBOM with each major release and for their post-quantum migration plans, so their cryptography can be included in your own inventory.
6. What the Tool Produces
crypto-cbom scan: a CycloneDX 1.6 or SPDX 3.0 CBOM document.crypto-cbom audit: a JSON audit result with findings per asset and a summary score.
There is no evidence bundle, key-rotation proof or auditor package. Treat the output as engineering input to be reviewed by people accountable for your compliance.
7. A Practical Starting Checklist
- Discover: run
crypto-cbom scanacross your repositories and collect the CBOMs. - Review: check the findings by hand; name-based scanning misses indirect uses and can flag false positives.
- Remediate: remove broken algorithms (DES/3DES, RC4, MD5, SHA-1) from active use.
- Plan: record where quantum-vulnerable public-key algorithms are used and plan their migration with your risk and compliance teams.
Rousseau, S. (2026). CBOM Manual: Cryptographic Inventories for DORA Work. Crypto Service Governance Series. Reference: CSS-COMP-2026-005. Canonical URI: https://docs.crypto-service.co/whitepapers/dora-cbom-manual/