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, Cryptographic Bill of Materials, exprimé en CycloneDX 1.6, 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, cdxgen ou Syft, 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.6 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.
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 ».
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.
L'honnêteté épistémique : 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é.
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.
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 son export CycloneDX 1.6, avec une canonicalisation RFC 8785, et par défaut avec une signature post-quantique, ML-DSA-65. 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 valide la provenance et l'intégrité hors ligne, en air-gap, sans faire confiance à l'interface.
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.
