Checklist · Acheteurs

Évaluer un outil de découverte cryptographique ou de CBOM : 24 questions à poser à chaque éditeur

Publié le 11 octobre 2026 · 10 min de lecture · Par Ali Korsi Tous les outils de découverte cryptographique trouvent du RSA quelque part. Ces questions distinguent ceux dont l’inventaire tiendra face à un auditeur, un architecte et un budget de migration de ceux qui produisent seulement un graphique.

Read in English

La feuille de route post-quantique de l’UE attend des organisations qu’elles commencent par un inventaire cryptographique d’ici fin 2026, et DORA, NIS2 et le Cyber Resilience Act exigent déjà une cryptographie gouvernée. Le marché a répondu par une vague d’outils qui promettent de trouver votre cryptographie et d’exporter un CBOM. Leurs fiches produit se ressemblent. Leurs résultats, non.

Cette checklist est neutre vis-à-vis des éditeurs et conçue pour être imprimée et emportée en rendez-vous. Chaque question est accompagnée de ce qu’est une bonne réponse, pour distinguer une capacité démontrée d’une diapositive de feuille de route. Elle s’applique à nous comme aux autres.

Avant tout : demandez un CBOM d’un dépôt public

Avant de donner à un éditeur l’accès à votre code, demandez à chacun la même chose : un CBOM d’un dépôt public, figé sur un commit, avec le périmètre analysé, le résultat de validation et les limites déclarées. Mieux encore, demandez une exécution en direct sur un dépôt public de votre choix. Cela ne coûte presque rien à l’éditeur si l’outil fonctionne, et vous permet de vérifier les findings sur un code que tout le monde peut lire.

À quoi cela ressemble : notre exemple de CBOM pyca/cryptography (en anglais) publie le CBOM CycloneDX 1.6, l’enregistrement de validation (résultat du schéma, nombre de fichiers, répartition par périmètre et liste écrite des limites) et le runbook pour un commit figé. Rejouer l’analyse elle-même nécessite un accès à notre scanner ; les résultats peuvent être vérifiés par tous sur le code public.

1. Couverture et détection

Quels langages, types de fichiers et surfaces analysez-vous, et lesquels non ?
La cryptographie se trouve dans le code source, les certificats, les endpoints, les magasins de clés, les binaires et les images de conteneurs. Un outil qui couvre bien une surface en laissant croire qu’il couvre les autres laisse des angles morts que vous découvrirez en pleine migration.

Bonne réponse : Une matrice de couverture écrite par langage, format de certificat et surface, chaque ligne marquée disponible, prévue ou non supportée. « Nous couvrons tout » n’est pas une réponse.
Comment fonctionne la détection, et que manque-t-elle ?
L’analyse AST, les règles par motifs et l’inspection de handshake ont chacune leurs angles morts : algorithmes choisis à l’exécution, cryptographie dans les dépendances, code compilé.

Bonne réponse : La méthode de détection par langage ou surface, les angles morts connus, et le détecteur indiqué sur chaque finding pour pouvoir le juger.
Distinguez-vous le code de production des tests, exemples et code tiers embarqué ?
Dans une bibliothèque cryptographique, les vecteurs de test peuvent dépasser d’un ordre de grandeur les appels de production. Sans étiquette de périmètre, l’inventaire mesure votre suite de tests.

Bonne réponse : Chaque finding étiqueté par périmètre (production, test, exemple, tiers), des décomptes séparés et des filtres pour exclure le hors-production du score et du contrôle CI.

2. Qualité des preuves

Chaque finding peut-il être rattaché à l’endroit où il a été trouvé ?
Un auditeur ou un ingénieur demandera « où ? ». Un total agrégé ne se vérifie pas et ne se corrige pas.

Bonne réponse : Fichier et ligne (ou certificat, ou endpoint) sur chaque finding, plus la révision du dépôt analysée.
Qu’enregistrez-vous au-delà du nom de l’algorithme ?
« RSA » ne suffit pas pour planifier une migration. Taille de clé, courbe, mode, padding et usage décident du remplaçant et de l’urgence.

Bonne réponse : Primitive, taille de clé ou courbe, mode et padding lorsqu’ils sont détectables, et un « inconnu » explicite sinon, plutôt qu’une supposition.
Une analyse est-elle répétable ?
Si deux exécutions sur le même code divergent, aucun des deux résultats n’est une preuve.

Bonne réponse : La version du scanner et la révision cible enregistrées à chaque exécution, et la même révision analysée deux fois donnant les mêmes findings normalisés.

3. Conformité au standard CBOM

L’export est-il un CBOM CycloneDX 1.6 validé contre le schéma officiel ?
Un JSON propriétaire « inspiré de » CycloneDX enferme votre inventaire chez l’éditeur et risque de ne pas se charger dans vos outils GRC ou SBOM.

Bonne réponse : Des composants CycloneDX 1.6 cryptographic-asset, validés contre le schéma CycloneDX publié, avec un résultat de validation que vous pouvez rejouer vous-même.
Les faits d’inventaire sont-ils séparés de l’interprétation de l’éditeur ?
Scores de risque et recommandations sont des avis ; algorithme, emplacement et paramètres sont des faits. Les mélanger rend le CBOM moins portable et plus difficile à auditer.

Bonne réponse : Les faits dans les champs CBOM standard ; scores, justifications et recommandations dans des sorties séparées et attribuables.
Qu’est-ce qui ne figure pas dans le CBOM ?
Tout CBOM a des limites : une référence dans le code n’est pas une clé déployée, et peu d’outils capturent un graphe de dépendances complet.

Bonne réponse : Une liste écrite des limites livrée avec le CBOM, et non découverte par votre auditeur.

4. Déploiement et traitement des données

Où l’analyse s’exécute-t-elle, et le code source quitte-t-il votre environnement ?
Vous confiez à l’outil une carte de vos mesures de sécurité les plus sensibles. Le lieu où cette carte est construite compte autant que son contenu.

Bonne réponse : Sur site ou dans vos propres runners CI, un flux de données documenté, et aucun code source dans les artefacts exportés.
Peut-il fonctionner entièrement hors ligne, et quelles fonctions ont besoin du réseau ?
Les promesses « air-gapped » cachent souvent une vérification de licence, un tableau de bord cloud ou une fonction d’IA qui appelle l’extérieur.

Bonne réponse : La liste de toutes les fonctions qui font un appel externe, chacune avec un mode hors ligne, et une réponse claire sur l’existence d’un test indépendant du fonctionnement hors ligne.
Que devient votre inventaire si vous cessez d’utiliser l’outil ?
Un inventaire lisible uniquement dans la plateforme de l’éditeur est une dépendance, pas un actif.

Bonne réponse : Des sorties en formats ouverts utilisables sans l’éditeur, une clause de réversibilité, et un document de posture de sécurité que vos achats peuvent archiver.

5. Intégration CI/CD

Peut-il s’exécuter dans le pipeline et faire échouer un build selon votre politique ?
Un inventaire sans contrôle est un seau percé : de la nouvelle cryptographie vulnérable arrive pendant que vous retirez l’ancienne.

Bonne réponse : Une CLI avec des codes de sortie exploitables, un seuil de sévérité et un nombre toléré configurables, pour démarrer en mode rapport puis durcir progressivement.
Les résultats arrivent-ils là où les développeurs travaillent déjà ?
Un tableau de bord séparé que personne n’ouvre ne change pas le code.

Bonne réponse : Une sortie SARIF pour le code scanning, avec fichier, ligne, sévérité et remplaçant recommandé sur chaque alerte.
Pouvez-vous suivre la dérive cryptographique d’une version à l’autre ?
Après le premier inventaire, la question est toujours « qu’est-ce qui a changé ? ».

Bonne réponse : Des instantanés d’inventaire par version et un diff listant la cryptographie ajoutée et retirée, exportable vers votre pipeline ou votre outil GRC.

6. Score de risque et priorisation

Le risque est-il évalué par actif, avec sa justification ?
Une note globale ne dit pas par où commencer, et un score opaque ne se défend pas.

Bonne réponse : Un score par actif avec une justification écrite qui nomme les facteurs : faiblesse de l’algorithme, exposition, durée de vie des données, périmètre.
Le score tient-il compte de la durée de confidentialité de vos données ?
Le risque « harvest now, decrypt later » dépend de la durée de vie des données, que l’outil ne peut pas deviner à partir du code.

Bonne réponse : Une politique de sensibilité configurable (par chemin, dépôt ou système) qui modifie le score, documentée et versionnée avec votre code.
Passe-t-il du risque à un plan de migration ?
Une liste de findings triée n’est pas un plan. Il faut des remplaçants, un séquencement et une estimation d’effort.

Bonne réponse : Un remplaçant recommandé par actif, aligné sur FIPS 203/204/205 lorsque c’est pertinent, et des findings regroupés en vagues de migration.

7. Correspondance réglementaire européenne

À quelles obligations les findings sont-ils rattachés, et avec quelle précision ?
« Prêt pour DORA » sur une plaquette ne dit rien à votre équipe conformité.

Bonne réponse : Un rattachement à des dispositions nommées, par exemple l’article 9 de DORA et le règlement délégué 2024/1774, l’article 21(2)(h) de NIS2 et le règlement d’exécution 2024/2690, le Cyber Resilience Act, ainsi que les jalons de la feuille de route post-quantique de l’UE et la doctrine de l’ANSSI.
L’éditeur évite-t-il d’affirmer que l’outil vous rend conforme ?
La conformité est un jugement porté sur votre organisation, pas une propriété d’un logiciel. Une promesse excessive doit faire douter du reste.

Bonne réponse : Une formulation du type « contribue aux activités de conformité », et des preuves lisibles par un auditeur : inventaire daté, méthode, limites.
Votre direction et vos auditeurs peuvent-ils exploiter le rapport sans la plateforme de l’éditeur ?
Les autorités de contrôle et les conseils lisent des documents, pas des tableaux de bord.

Bonne réponse : Un rapport daté dans un format standard, dans la langue de votre direction et de votre autorité de contrôle, qui se suffit à lui-même.

8. Aspects commerciaux et support

Le premier engagement a-t-il un périmètre et un prix fixes ?
Les projets de découverte sans limite sont difficiles à faire valider et encore plus à clôturer.

Bonne réponse : Un tarif publié ou forfaitaire pour un premier engagement borné, avec un livrable clair, avant tout engagement sur la plateforme.
Qui exécute l’outil, et qui vous accompagne ?
Interpréter un inventaire cryptographique demande de l’expertise, tout comme corriger un faux positif dans un contrôle qui bloque les mises en production.

Bonne réponse : Des personnes nommées qui cadrent et conduisent l’engagement, un engagement de support pour l’offre plateforme, et une politique de divulgation des vulnérabilités publiée.
L’éditeur exécutera-t-il l’outil devant vous, sur du code public ?
Une présentation ne prouve rien, et vous ne devriez pas avoir à confier votre code pour savoir si un outil fonctionne.

Bonne réponse : Une exécution en direct sur un dépôt public proche de votre stack, qui se termine par un CBOM que vous gardez et pouvez inspecter.

Comment noter les réponses

Notez chaque réponse par éditeur, en ne comptant que ce que vous avez vu, pas ce qu’on vous a dit.

Note	Signification
0	Pas de réponse, ou une réponse qui esquive la question.
1	Affirmé par écrit (fiche produit, proposition, contrat), pas encore démontré.
2	Démontré : vous l’avez vu sur du vrai code ou vous détenez l’artefact (CBOM, rapport, fichier SARIF).

Pondérez les sections selon votre situation. Une banque soumise à DORA privilégiera les preuves, le déploiement et la correspondance réglementaire ; un éditeur de logiciels qui se prépare au CRA privilégiera plutôt la CI/CD et le standard CBOM. Considérez un 0 aux questions 4, 7 ou 10 comme éliminatoire : sans findings traçables, sans CBOM valide et sans maîtrise de l’endroit où va votre code, le reste ne compte pas.

Comment CRYPTAGION répond à ces questions

Nous avons écrit cette checklist pour qu’elle nous soit appliquée aussi. En bref : CRYPTAGION découvre la cryptographie dans le code Python (AST), JavaScript/TypeScript, Java, Go et C/C++, les certificats X.509 (PEM, DER, CRT, CER) et les endpoints TLS en direct. Chaque finding porte son fichier et sa ligne ou son endpoint, et une étiquette de périmètre (production, test, exemple, tiers). Il exporte un CBOM CycloneDX 1.6 validé contre le schéma et conserve les scores de risque, avec leur justification, dans des sorties séparées. Les scores tiennent compte de la sensibilité des données et de l’exposition HNDL via une politique .cryptagion.yaml par chemin. Il s’exécute sur site ou en environnement isolé (air-gapped), et en CI avec un contrôle de politique et une sortie SARIF. L’analyse d’images de conteneurs et de binaires est sur notre feuille de route, pas disponible aujourd’hui. La page déploiement et flux de données et le document de posture de sécurité répondent aux questions sur les données ; nos tarifs sont publics.

Sources

Soumettez-nous à la checklist

En 30 minutes, nous exécutons CRYPTAGION en direct sur un dépôt public proche de votre stack, et vous repartez avec le CBOM. Aucun accès à votre code n’est nécessaire.

Demander une démo gratuite →

← Toutes les ressources · Accueil