CBOM (Cryptography Bill of Materials)

Temps de lecture : 8-9 minutes

La cryptographie est l’ossature invisible de la confiance numérique. Elle protège nos API, nos données clients, nos firmwares industriels, et la communication entre micro‑services. Pourtant, dans nombre d’organisations, la réalité opérationnelle reste floue : quels algorithmes sont employés ? avec quelles tailles de clés ? via quelles bibliothèques ? Et surtout : ces choix sont‑ils conformes et à jour face aux exigences internes (politiques crypto), aux référentiels (ANSSI, NIST) et aux risques de la supply chain open source ?

Le CBOM (Cryptography Bill of Materials) répond précisément à ces questions. Il s’agit d’un inventaire structuré de tous les éléments cryptographiques d’un produit (logiciel, firmware, système embarqué, module matériel) : algorithmes, modes, bibliothèques, paramètres, protocoles, gestion des clés. Avec un CBOM, vous gagnez une visibilité exploitable pour auditer, améliorer et prouver la sécurité de vos choix cryptographiques.

Un CBOM est un document ou fichier structuré (souvent au format JSON/XML, compatible avec des standards comme CycloneDX et son Crypto Profile) qui recense :

• Algorithmes : symétriques (AES‑GCM/CTR), asymétriques (RSA‑2048/3072, ECC‑P‑256/384), hash (SHA‑256/512), KDF (HKDF), MAC (HMAC‑SHA‑256).
• Modes opératoires : GCM, CBC, CTR, XTS, etc., incluant les paramètres critiques (IV/nonce, tag, padding).
• Taille des clés : ex. AES‑256, RSA‑3072, ECC‑P‑256.
• Librairies & versions : OpenSSL 3.x, BoringSSL, LibreSSL, mbedTLS, wolfSSL, libsodium…
• Protocoles : TLS (versions, suites), SSH (versions, ciphers), IPsec/IKE, DTLS, JOSE/JWT.
• Gestion des clés : génération (CSPRNG), stockage (HSM, TPM, Secure Element), rotation, révocation, attestation.
• Conformité et validations : FIPS 140‑3, Common Criteria, lignes directrices ANSSI/NIST, statut « approuvé/déprécié ».
• Contexte d’usage : à quel composant, micro‑service, binaire, firmware, endpoint ou fonctionnalité l’élément s’applique.

Objectif : rendre explicite ce qui est souvent implicite dans le code, les dépendances et la configuration.

• Réduire le risque « crypto »

• Maîtriser la supply chain logicielle

• Conformité et audits accélérés

• Anticiper l’après‑quantique (PQC)

Le SBOM (Software Bill of Materials) dresse la liste des composants logiciels (librairies, versions, licences, vulnérabilités). Le CBOM zoome uniquement sur la cryptographie et ajoute les paramètres réellement utilisés.

Pourquoi les relier ?
Parce qu’un CVE dans une lib crypto (vu via SBOM) ne dit pas à lui seul si votre configuration est vulnérable. Le CBOM apporte la granularité (algorithme/mode/paramètres) qui change le niveau de risque et les priorités de remédiation.

Étape 1 – Découverte automatique

• Analyse du code source : recherche d’APIs crypto (OpenSSL, libsodium, mbedTLS…), des paramètres (modes, tailles, suites).
• Scanning des binaires : utile quand le code n’est pas accessible (tiers, legacy).
• Corrélation avec les métadonnées système (certificats, HSM, politiques TLS).

Astuce DevSecOps : intégrez l’analyse dans la CI/CD (pull‑request + build), et regénérez le CBOM à chaque release.
Étape 2 – Inventaire manuel ciblé

• HSM/TPM/SE (usage, références, partitions, wrappers).
• Services managés (KMS cloud, mTLS, secrets managers).
• Cas particuliers : crypto réglementée (secteur Défense), protocoles maison à décommissionner.

Étape 3 – Génération & normalisation

• Format : CycloneDX avec Crypto Profile pour faciliter l’échange inter‑outils (SIEM, GRC, ticketing).
• Référentiels : associer chaque entrée à un statut (approuvé/déprécié/interdit) selon vos politiques (ANSSI/NIST internes).

Étape 4 – Exploitation continue

• Tableau de bord : taux d’algos dépréciés, couverture HSM, exposition TLS < 1.2, etc.
• Workflows : ouverture automatique de tickets (migration suite TLS, rotation clé), revue trimestrielle.
• Lien SBOM : rattacher les usages crypto à des packages/versions précis pour un plan de remédiation clair.

1) Quelle est la “taille idéale” d’un CBOM ?
Pas de taille magique : un bon CBOM est actionnable. Il doit couvrir tous les points d’usage (algorithmes, modes, clés, certificats, bibliothèques, protocoles) sans se perdre dans des détails qui n’influencent pas la sécurité (ex. répétitions inutiles). Priorisez les éléments décisionnels (versions, paramètres, stockage des secrets).

2) Peut‑on déduire le CBOM à partir du SBOM uniquement ?
Non. Le SBOM indique quoi est présent (librairies/versions). Le CBOM indique comment c’est utilisé (algorithmes/modes/tailles/paramètres). Les deux sont complémentaires.

3) Le CBOM s’applique‑t‑il aux micro‑services et au cloud ?
Oui. On rattache chaque élément crypto au service (ou au binaire), à l’environnement (prod/stage) et aux endpoints (ex. TLS 1.3 sur api.example.com, clés serveurs en HSM/KMS).

4) Quelles erreurs fréquentes le CBOM permet de révéler ?

• Suites TLS permissives (retour d’algos faibles).
• Nonces IV réutilisés (AES‑GCM).
• RNG non cryptographique.
• Hash obsolètes (SHA‑1) dans des signatures.
• Clés hors HSM/TPM alors qu’exigées.
• JWT signés en algos non recommandés ou sans rotation.

5) Comment démarrer rapidement ?

• Scanner un premier périmètre (service critique, firmware prioritaire).
• Sortir un CBOM MVP (80/20) → corriger les écarts évidents (algos dépréciés, suites TLS).
• Étendre progressivement et industrialiser dans la CI/CD.

6) Le CBOM est‑il requis par des normes ?
Il est de plus en plus demandé par les clients, par des cahiers des charges et lors de diligences. Même quand non explicitement requis, il accélère les preuves de conformité (ANSSI/NIST/FIPS) et réduit le temps d’audit.