Tout le monde va bientôt vous demander un CBOM. Peu vous diront qu'un CBOM naïf est pire que rien : il donne l'illusion de savoir. La bascule post-quantique tient en une phrase. On ne migre pas ce qu'on ne voit pas. L'inventaire cryptographique est devenu l'artefact que réclament le NIST, l'ANSSI et vos auditeurs. Mais lister trois algorithmes et deux versions de TLS ne suffit pas. La vraie question n'est pas « quels algorithmes ai-je », c'est « qu'est-ce que je sais, avec quelle certitude, et est-ce encore vrai maintenant ».
Un CBOM, c'est bien plus que des algorithmes
Un CBOM, Cryptography Bill of Materials, exprimé en CycloneDX 1.7, n'est pas une liste d'algorithmes. C'est l'inventaire de tous vos actifs cryptographiques : les primitives comme RSA, ECDSA, AES ou SHA, mais aussi les protocoles (versions et suites TLS, SSH), les certificats X.509, les clés et leur état, et la cryptographie présente dans votre code, les bibliothèques et fonctions que vos applications appellent. Le piège est double : le réduire aux algorithmes, et le figer dans un fichier. Votre cryptographie vit à trois endroits, dans le code, au runtime et sur le fil, et elle change en permanence.
Absorber le CBOM de tout un système d'information
Observer le fil ne suffit pas. La cryptographie de vos applications naît dans le code et s'exécute au runtime. PKIFactor agrège ces couches par une gateway d'ingestion. Vos chaînes d'intégration continue produisent déjà un CBOM, avec des outils comme CBOMkit ou cdxgen, et le poussent vers un point d'entrée unique. PKIFactor le normalise sur ses algorithmes canoniques, de sorte qu'un RSA détecté par cdxgen devienne le même actif que celui observé sur le fil, sans doublon ni contradiction. Il étiquette la provenance de chaque actif, code ou runtime, puis fusionne le tout avec l'inventaire observé et l'inventaire géré, dans un seul document CycloneDX 1.7 signé.
Le point sensible, c'est l'identité. Un client ne déclare jamais quelle application il représente : son identité est prouvée, et c'est elle qui sert de clé de corrélation à la fusion. Trois mécanismes cohabitent. Le premier, le plus fort, est le mTLS : le client présente un certificat émis par PKIFactor lui-même, vérifié par un point d'entrée dédié. PKIFactor étant votre autorité, il délivre les identités que ses propres clients utilisent. Le deuxième est l'OIDC de workload : un pipeline GitHub Actions ou GitLab CI s'authentifie avec son jeton natif, vérifié par sa JWKS, sans aucun secret à stocker. L'identité est le dépôt lui-même, et une liste blanche par dépôt ou par organisation contrôle qui peut pousser. Le troisième, un jeton porteur scopé et haché au repos, sert de repli. Dans tous les cas, l'application qui alimente l'inventaire est celle que l'identité prouve, jamais celle qu'un paramètre prétend. À l'arrivée, rien n'est accepté sur parole : le document est validé contre le schéma CycloneDX, ses références internes sont vérifiées, et sa signature aussi quand elle est exigée. Un CBOM invalide est refusé avec un motif explicite. Chaque échec d'authentification est audité, avec l'adresse source et la raison du refus, pour qu'une gateway ouverte aux pipelines ne devienne pas une porte dérobée silencieuse.
Chaque actif cryptographique du système d'information, qu'il vienne du code, du runtime ou du fil, atterrit ainsi dans un CBOM unique, daté, signé, avec sa provenance. C'est ce qui transforme « voir le TLS exposé » en « connaître toute la cryptographie d'un système d'information ».
Ce que contient vraiment l'export d'un parc
Un inventaire qui ne couvre que les certificats n'est pas un CBOM. L'export du parc de PKIFactor rassemble trois couches en plus des certificats eux-mêmes.
La première est le TLS réellement servi. Pour chaque certificat géré, l'export reprend la dernière observation de chaque point d'accès : version négociée, suite décomposée, groupe d'échange de clés. On ne présume pas la configuration, on la relit sur le fil.
La deuxième est l'inventaire des clés. Clés de signature, clés privées des certificats détenues par la plateforme, clé de l'autorité d'enregistrement SCEP, clés de chiffrement des données et clé maîtresse, clés TLS des services : chacune apparaît avec son algorithme, sa taille, son état, ses dates et son mode de protection. Sur notre parc de démonstration, cela représente 39 clés privées et secrètes, en plus des clés publiques des certificats. Le point non négociable : l'inventaire est construit uniquement à partir des métadonnées. Aucune clé n'est déchiffrée pour être inventoriée, et aucun matériel secret ne sort dans le document.
La troisième est SSH. La cryptographie d'un système d'information ne passe pas que par TLS. Sur option, le scan réseau lit l'offre d'algorithmes d'un serveur SSH et sa clé d'hôte, sans jamais s'authentifier. Les algorithmes d'échange de clés, de chiffrement et d'intégrité sont rattachés au même catalogue canonique que TLS, et les choix faibles sont signalés. Sur un serveur OpenSSH 9.2 de notre laboratoire, le même scan fait ressortir à la fois un échange de clés hybride post-quantique proposé, sntrup761, et un HMAC-SHA1 encore accepté. Les deux sont vrais en même temps, et c'est exactement ce qu'un CBOM doit montrer.
Un inventaire vivant, pas une photo
Un CBOM figé est périmé le jour où il est produit. PKIFactor prend des instantanés successifs et calcule la dérive. Un algorithme faible qui apparaît, une autorité qui bascule, un service qui régresse en TLS 1.0 : tout cela se détecte quand cela arrive, pas au prochain audit. Le CBOM cesse d'être un livrable de conformité pour devenir un signal opérationnel.
Trois degrés de certitude : observé, déclaré, projeté
C'est ce qui sépare un CBOM utile d'un CBOM bruyant. Chaque constat porte un statut de preuve. Un constat observé est vu sur le fil, en temps réel : le handshake TLS servi, la version négociée, le groupe d'échange réel. Sa sévérité est pleine, parce que c'est un fait. Un constat déclaré est lu dans le certificat ou l'enregistrement, une autorité quantiquement vulnérable, une clé RSA-1024 : sa sévérité est pleine aussi, le fait est certain. Un constat projeté est une menace conditionnelle, en attente d'observation, comme le fameux « récolter maintenant, déchiffrer plus tard ». Le point décisif : seul le projeté est plafonné. Crier au loup quantique sur tout un parc, c'est du bruit qui noie le vrai signal. PKIFactor plafonne le théorique, laisse le déclaré à pleine sévérité, et fait monter un projeté dès qu'il devient observé.
La posture d'un scan réseau, une des sources du CBOM (données de démonstration) : les versions TLS dépréciées sont observées, le risque post-quantique est projeté et plafonné, et l'export CBOM signé part de cette vue.
Le détail que presque tout le monde rate
L'exposition à la récolte quantique est une propriété du service, le groupe d'échange de clés négocié et observé sur le fil, pas de la clé de signature du certificat. Un certificat ECDSA n'est pas plus exposé qu'un RSA à cette menace : c'est la confidentialité du transport qui l'est, et elle se mesure au handshake, pas en analysant le sujet du certificat. De là une décomposition rigoureuse par schéma. Un RSA-SHA256 n'est pas une primitive : c'est une signature, sensible à Shor, plus un hachage, SHA-256, que Shor ne casse pas. Confondre les deux fausse tout le classement. Un CBOM sérieux sépare la signature, le hachage et l'échange de clés, et attribue à chacun son propre niveau de résistance quantique.
C'est ce que fait l'export de PKIFactor pour chaque service observé : la suite TLS négociée est décomposée en ses algorithmes, échange de clés, authentification, chiffrement et intégrité, chacun avec sa famille, son OID et son niveau de sécurité quantique NIST. Le document est validé contre le schéma officiel CycloneDX 1.7.
Extrait réel d'un CBOM exporté par PKIFactor (données de démonstration) : une suite TLS décomposée, et la signature ML-DSA-65 qui couvre tout le document.
Un CBOM qu'on ne peut pas vérifier ne vaut rien
Un inventaire de sécurité non signé n'est qu'un document. PKIFactor signe chaque export au format JSF, la signature enveloppée native de CycloneDX 1.7, sur une canonicalisation RFC 8785, et par défaut avec une signature post-quantique, ML-DSA-65. Aucun export ne sort non signé. Le CBOM qui parle du risque quantique est lui-même signé de façon résistante au quantique. Les verdicts, l'attestation, sont servis séparément de l'inventaire, les faits. Un vérificateur autonome, un seul fichier Python à lire, valide hors ligne l'intégrité du document, et sa provenance dès que la clé du signataire est épinglée, en air-gap, sans faire confiance à l'interface.
Vérification hors ligne : la signature et la liaison entre attestation et inventaire tiennent, et un seul caractère modifié invalide le document.
Lisible par l'écosystème, honnête sur ses limites
Un CBOM que seul son producteur sait lire est une impasse. Nous avons testé nos exports contre les outils du marché, et le résultat est contrasté, donc nous le donnons tel quel.
L'outil de référence cyclonedx-cli valide nos documents. La visionneuse de CBOMkit lit notre export et en tire 46 actifs cryptographiques, avec leurs primitives et leurs fonctions. La part affichée comme « inconnue » y est structurelle : l'outil ne juge que les algorithmes, pas les certificats, les clés ou les protocoles.
Un export PKIFactor lu par la visionneuse CBOMkit 2.3.0 (données de démonstration). Le bandeau de non-conformité est attendu : le parc de démonstration contient encore du RSA et du TLS 1.0, précisément ce que le CBOM doit rendre visible.
Le vrai frein est la signature. Les bibliothèques Java de CycloneDX ne savent pas encore analyser une signature ML-DSA enveloppée dans le document. Plutôt que de dégrader la signature par défaut, PKIFactor propose un second export pour les outils : le CBOM sans signature enveloppée, accompagné d'une signature détachée ML-DSA-65 sur son empreinte, vérifiable par le même vérificateur hors ligne. L'intégrité reste prouvable, et le document reste lisible.
Enfin, une limite que nous préférons annoncer : Dependency-Track 4.x n'ingère pas encore les actifs cryptographiques CycloneDX, quel que soit le producteur. De même, la qualité de la partie code d'un CBOM dépend des outils qui l'ont produit. PKIFactor la valide, la normalise et la signe, il ne la réinvente pas. Une limite annoncée vaut mieux qu'une compatibilité supposée.
Du CBOM au cycle de vie
Rien de tout cela n'est un produit à part. C'est la projection de la plateforme qui découvre, classe et gère déjà ces actifs, PKIFactor, notre CLM. Le même moteur qui absorbe un annuaire de certificats entier, classe chaque certificat par usage réel et automatise l'émission ACME sur votre PKI existante produit l'attestation signée que vous tendez à l'auditeur. Le tout reste cent pour cent sur site, sans aucun appel sortant. Un inventaire de votre cryptographie n'a rien à faire dans le cloud d'un autre.
Un CBOM n'est pas une liste qu'on ne peut pas croire, produite une fois pour l'audit. C'est un constat vivant, à jour, que l'on peut prouver.
