Une nomenclature cryptographique (CBOM, Cryptographic Bill of Materials) est un inventaire lisible par machine de la cryptographie utilisée par un système : algorithmes et leurs paramètres, clés, certificats, protocoles et bibliothèques qui les implémentent. Elle répond à des questions auxquelles un tableur ne peut pas répondre de manière fiable à grande échelle : où utilisons-nous encore RSA-2048 ? Quels services dépendent d'une bibliothèque sans prise en charge de ML-KEM ? Qu'est-ce qui a changé depuis le trimestre dernier ?
CBOM et SBOM
Une nomenclature logicielle (SBOM) recense les composants logiciels et leurs versions. Elle vous indique qu'un service utilise OpenSSL 3.0, mais pas quels algorithmes ce service appelle réellement, avec quelles tailles de clé, ni quels certificats il présente. Le CBOM ajoute cette couche cryptographique. Les deux sont complémentaires, et la norme CycloneDX prend en charge les deux dans un même document.
Le format CycloneDX 1.6
Depuis la version 1.6, CycloneDX définit un type de composant cryptographic-asset doté de cryptoProperties. Un actif peut être un algorithme, un certificat, un protocole ou un élément associé, comme une clé. Une entrée minimale pour une signature RSA-2048 se présente ainsi :
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"components": [
{
"type": "cryptographic-asset",
"bom-ref": "crypto/algorithm/rsa-2048",
"name": "RSA-2048",
"cryptoProperties": {
"assetType": "algorithm",
"algorithmProperties": {
"primitive": "signature",
"parameterSetIdentifier": "2048",
"cryptoFunctions": ["sign", "verify"],
"classicalSecurityLevel": 112,
"nistQuantumSecurityLevel": 0
}
}
}
]
}
Le champ nistQuantumSecurityLevel est ce qui rend un CBOM utile pour planifier la migration post-quantique : 0 signifie que l'algorithme n'offre aucune sécurité face à un attaquant quantique, comme RSA et ECDSA, tandis que ML-KEM-768 atteint le niveau 3.
Qui demande un CBOM
- L'administration fédérale américaine. Le mémorandum M-26-15 de l'OMB impose aux agences de tenir un inventaire cryptographique automatisé et mis à jour en continu, et l'Executive Order 14412 demande à la CISA de publier les éléments minimaux d'un CBOM. Les éditeurs de logiciels qui vendent aux agences fédérales devraient s'attendre à ce qu'on leur en demande un.
- Les réglementations européennes, indirectement. PCI DSS 12.3.3, DORA et NIS2 exigent un inventaire ou des politiques de cryptographie sans imposer de format. Un CBOM est la manière la plus structurée d'y répondre.
- Les plans de migration des agences. Le NIST, l'ANSSI, le BSI et le NCSC britannique placent tous la découverte et l'inventaire en premier.
Comment en produire un
Un CBOM complet combine plusieurs sources :
- La découverte réseau de ce qu'exposent les services : versions TLS, suites cryptographiques, groupes d'échange de clés et certificats. C'est ce que fait notre scanner gratuit pour les points de terminaison publics.
- L'analyse statique du code source pour repérer les appels cryptographiques, les tailles de clé et les algorithmes codés en dur.
- L'analyse de configuration des serveurs web, des proxys et de l'infrastructure en tant que code.
- L'analyse des dépendances pour savoir quelles bibliothèques cryptographiques, et en quelles versions, chaque application embarque.
Des outils open source couvrent une partie de ce travail, comme CBOMkit et le plugin de cryptographie pour Sonar, maintenus au sein de la Post-Quantum Cryptography Alliance. PQC Status développe un scanner en ligne de commande qui s'exécute localement, afin que votre code ne quitte jamais votre machine, et qui produit un CBOM au format CycloneDX.
Le maintenir à jour
Un CBOM n'est utile que s'il reste à jour. Générez-le en intégration continue à chaque version, conservez chaque itération et comparez-les : un nouvel actif vulnérable au quantique dans un service critique devrait être aussi visible qu'une nouvelle dépendance vulnérable.