CBOM ou SBOM : ce qui les distingue, et pourquoi il vous faut les deux

Publié le 11 octobre 2026 · 8 min de lecture · Par Ali Korsi Ce sont deux nomenclatures, toutes deux exprimables en CycloneDX, et de plus en plus demandées par les régulateurs et les clients. Elles répondent à des questions différentes, et l’une ne remplace pas l’autre.

Read in English

La réponse courte

Un SBOM (software bill of materials, nomenclature logicielle) liste les composants dont un produit est fait : bibliothèques, versions, identifiants de paquets, licences et dépendances. Il répond à « que livrons-nous ? » et alimente la gestion des vulnérabilités et des licences.

Un CBOM (cryptographic bill of materials) liste les actifs cryptographiques qu’un produit utilise : algorithmes, certificats, protocoles et éléments de clés, avec leurs paramètres et l’endroit où ils ont été trouvés. Il répond à « de quelle cryptographie dépendons-nous, et où ? » et alimente la migration post-quantique et la gouvernance cryptographique.

La même bibliothèque, vue deux fois

Prenons pyca/cryptography, une bibliothèque cryptographique Python très répandue. Dans le SBOM d’une application, elle occupe une ligne parmi des centaines :

{
  "type": "library",
  "name": "cryptography",
  "version": "x.y.z",
  "purl": "pkg:pypi/cryptography@x.y.z",
  "licenses": [ { "expression": "Apache-2.0 OR BSD-3-Clause" } ]
}

{
  "type": "cryptographic-asset",
  "bom-ref": "crypto/0550a8cc-2451-4f06-90be-2b1c9ba1c2a9",
  "name": "RSA",
  "description": "Import of rsa from cryptography.hazmat.primitives.asymmetric discovered in pkcs7.py:19",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "pke"
    }
  },
  "evidence": {
    "occurrences": [
      {
        "location": "src/cryptography/hazmat/primitives/serialization/pkcs7.py",
        "line": 19
      }
    ]
  },
  "properties": [
    {
      "name": "cryptagion:source:scope",
      "value": "production"
    }
  ]
}

Le SBOM indique que la bibliothèque est présente. Il ne dit pas que le module de sérialisation PKCS#7 dépend de RSA, un algorithme à clé publique vulnérable au quantique. Dans notre analyse figée de pyca/cryptography (en anglais), les 243 fichiers Python ont produit 1 804 détections dans le CBOM : 46 dans le code de la bibliothèque, 1 746 dans les tests et 12 dans les scripts de documentation. C’est le niveau de détail dont une équipe de migration a besoin, et la répartition par périmètre évite de compter des vecteurs de test comme un risque de production.

Les deux fichiers sont publics : le CBOM complet et son enregistrement de validation, limites déclarées comprises (l’analyse Python ne couvre pas le code Rust de la bibliothèque, et le CBOM ne contient pas de graphe de dépendances complet).

Ce qu’un SBOM ne peut pas vous dire

• La cryptographie de votre propre code. Un SBOM décrit vos dépendances. Un RSA.generate(1024) codé en dur dans votre application, ou une fonction de hachage maison, n’est pas un composant.
• La façon dont une bibliothèque est utilisée. Livrer OpenSSL ne dit rien des algorithmes, tailles de clés ou modes que votre code lui demande. Deux applications avec la même ligne de SBOM peuvent avoir des expositions quantiques très différentes.
• Les certificats et endpoints. Les certificats X.509, les configurations TLS et les suites réellement négociées par un serveur vivent en dehors du build. Ce sont des actifs cryptographiques, pas des composants logiciels.
• Les paramètres. RSA-2048 avec OAEP ou RSA-1024 avec PKCS#1 v1.5 : le risque et le remplaçant ne sont pas les mêmes.

Ce qu’un CBOM ne remplace pas

• La gestion des vulnérabilités. Un CBOM ne suit pas les CVE de vos dépendances. Une version vulnérable d’une bibliothèque cryptographique relève du SBOM.
• Les licences et les fournisseurs. Ce sont des sujets SBOM.
• Le graphe de dépendances complet. Un CBOM peut référencer les composants qui fournissent un actif cryptographique, mais il n’est pas conçu pour décrire toute votre chaîne d’approvisionnement.

Ce qu’exige le Cyber Resilience Act

Le Cyber Resilience Act (règlement (UE) 2024/2847) fait du SBOM une obligation légale pour les fabricants de produits comportant des éléments numériques : l’annexe I, partie II, leur impose d’identifier et de documenter les composants, notamment en établissant un SBOM dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau. Les obligations de signalement s’appliquent depuis le 11 septembre 2026 ; la plupart des autres à partir du 11 décembre 2027.

Le CRA ne mentionne pas le CBOM. Il exige en revanche, à l’annexe I, partie I, que les produits protègent la confidentialité des données par des mécanismes à l’état de l’art, comme le chiffrement, et qu’ils limitent leur surface d’attaque. Démontrer que votre cryptographie est à l’état de l’art, et le restera pendant la transition post-quantique, suppose de savoir ce qu’elle est : c’est le rôle du CBOM. Pour NIS2 et DORA, le raisonnement est le même, et la feuille de route post-quantique de l’UE attend des inventaires cryptographiques d’ici fin 2026. L’ANSSI insiste elle aussi sur l’inventaire comme préalable à la migration hybride.

Comment les faire travailler ensemble

1. Un seul format. CycloneDX 1.6 porte à la fois les composants logiciels et les composants cryptographic-asset : les mêmes outils peuvent stocker, valider et comparer les deux.
2. Partir du SBOM pour savoir où chercher. Les bibliothèques cryptographiques du SBOM indiquent les dépôts et services à analyser en priorité.
3. Utiliser le CBOM pour voir ce qui est réellement utilisé. Algorithmes, paramètres et emplacements, y compris la cryptographie qu’aucun SBOM ne liste.
4. Régénérer les deux en CI. Un SBOM et un CBOM produits à chaque version gardent l’inventaire à jour et rendent les changements vérifiables.

La place de CRYPTAGION

CRYPTAGION produit le CBOM, pas le SBOM : conservez votre outil SBOM actuel. Il découvre la cryptographie dans le code Python, JavaScript/TypeScript, Java, Go et C/C++, les certificats X.509 et les endpoints TLS, et exporte un CBOM CycloneDX 1.6 validé contre le schéma avec le fichier et la ligne, ou l’endpoint, de chaque finding. Les scores de risque et les recommandations de migration sont conservés dans des sorties séparées, pour que le CBOM reste un inventaire portable. Vous comparez des outils ? Utilisez notre checklist d’évaluation d’un outil CBOM.

Sources

• Référence JSON CycloneDX 1.6
• Règlement (UE) 2024/2847 (Cyber Resilience Act), article 71 et annexe I
• Recommandation (UE) 2024/1101 de la Commission relative à une feuille de route coordonnée pour la transition vers la cryptographie post-quantique
• CRYPTAGION : exemple de CBOM Python, pyca/cryptography (10 octobre 2026, en anglais)

← Toutes les ressources · Accueil