Qu’est-ce qu’un inventaire cryptographique ?
Un inventaire cryptographique recense chaque endroit où une organisation utilise de la cryptographie (algorithmes, clés, certificats et protocoles), avec l’emplacement de chacun, ce qu’il protège et s’il est vulnérable au quantique. La feuille de route post-quantique coordonnée de l’UE place les inventaires cryptographiques parmi les premières étapes attendues d’ici fin 2026, et l’inventaire est la base de preuve des politiques cryptographiques exigées par DORA et NIS2.
CRYPTAGION le construit à partir de trois sources (code source, certificats X.509 et endpoints TLS en production) et l’exporte en CBOM CycloneDX 1.6.
Examiner un exemple de CBOM Python figé
Deux analyses des 243 fichiers Python de pyca/cryptography ont produit des résultats normalisés identiques et un CBOM CycloneDX 1.6 valide contre le schéma. Les preuves distinguent le code de la bibliothèque, les tests et les scripts de documentation, et indiquent les limites de couverture sur Rust.
Explorer les 1 804 détections, liées au code → · méthodologie et téléchargements (en anglais)
On ne migre, ne gouverne et n’audite pas ce que l’on n’a jamais inventorié.
Pourquoi l’inventaire cryptographique est devenu un sujet de direction
La plupart des organisations ne savent pas répondre à une question simple : où se trouvent RSA, ECDSA, SHA-1, MD5, les certificats TLS et les clés codées en dur dans notre parc ? Sans cette carte, la migration post-quantique ne peut être ni cadrée ni budgétée, et les attentes de gouvernance cryptographique de DORA et NIS2 ne peuvent pas être démontrées.
Ce que CRYPTAGION inventorie
- Code : Python, JavaScript/TypeScript, Java, Go, C/C++.
- Certificats : X.509 (PEM, DER, CRT, CER), avec émetteur, validité et algorithme de signature.
- Endpoints TLS en production : protocoles et suites de chiffrement négociés.
Chaque résultat porte sa provenance (fichier, ligne ou endpoint) : l’inventaire est auditable, pas une boîte noire.
Anatomie d’un résultat
Un résultat en dit plus qu’un graphique agrégé. Voici le contexte que CRYPTAGION enregistre pour chaque actif cryptographique :
- Source
src/security/KeyManager.java:143·KeyManager.wrapKey()- Périmètre
- Code de production (ni test, ni exemple, ni code tiers)
- Détecté par
- Analyse statique du code source
- Usage
- Chiffrement (encapsulation de clé)
- Statut quantique
- Vulnérable : cassable par l’algorithme de Shor
- Sensibilité des données
- Secret · confidentialité 15 ans, d’après
.cryptagion.yaml - Exposition HNDL
- 9 ans au-delà du scénario de planification CRQC 2032
- Risque
- Critique · 100/100, avec justification écrite
- Transition recommandée
- ML-KEM (FIPS 203) · migrer d’ici 2028
Résultat illustratif. Les champs sont ceux que CRYPTAGION enregistre pour chaque actif ; les valeurs dépendent de votre code et de votre politique de sensibilité.
Les résultats sont étiquetés par périmètre : la cryptographie de production n’est jamais confondue avec des fixtures de test, des exemples ou des bibliothèques embarquées, et chacun conserve la méthode de détection qui l’a produit.
Plus qu’une recherche de motifs cryptographiques
Des scanners génériques savent trouver des API cryptographiques. CRYPTAGION utilise l’analyse statique comme une entrée parmi d’autres, puis transforme ces signaux en actifs cryptographiques gouvernés, avec provenance, contexte, risque, recommandations de migration et sortie CBOM standard :
- Détection : fichier, ligne et fonction, ou certificat et endpoint TLS
- Classification : famille d’algorithme, taille de clé ou courbe, mode, padding, usage
- Contexte : périmètre du code, sensibilité des données et exposition HNDL
- Risque : un score de 0 à 100 avec sa justification
- Décision : remplaçant recommandé, année de migration et vague de la feuille de route
- Sorties : CBOM CycloneDX, feuille de route, rapport PDF, SARIF et événements SIEM
| Capacité | Règles SAST génériques | Outils SBOM | CRYPTAGION |
|---|---|---|---|
| Trouver les usages d’API cryptographiques dans le code | Avec des règles sur mesure | Non conçu pour | Oui |
| Taille de clé, courbe, mode, padding | Selon les règles | Non conçu pour | Oui, quand c’est détectable |
| Inventaire des certificats X.509 | Non conçu pour | Non conçu pour | Oui |
| Inspection des endpoints TLS en production | Non conçu pour | Non conçu pour | Oui |
| Sensibilité des données et exposition HNDL | Non conçu pour | Non conçu pour | Oui, politique par chemin |
| Correspondance vers les remplaçants PQC | Non conçu pour | Non conçu pour | Oui |
| Actifs cryptographiques CycloneDX 1.6 | Non conçu pour | Composants logiciels | Oui |
| Feuille de route de migration | Non conçu pour | Non conçu pour | Oui, par vagues |
| Dérive cryptographique entre versions | Diff sur mesure nécessaire | Diff de composants | Oui, instantanés d’inventaire |
De l’inventaire à la décision
L’inventaire est scoré selon le risque quantique et l’exposition « récolter maintenant, déchiffrer plus tard » (calculateur HNDL), exporté en CBOM CycloneDX 1.6, puis transformé en rapport pour la direction et en plan de migration par vagues. C’est le socle de la crypto-agilité : savoir où la cryptographie est utilisée avant de devoir la changer. Il s’exécute dans votre périmètre, on-prem ou air-gapped : votre code source n’en sort jamais. Voir déploiement et flux de données (en anglais).
CRYPTAGION alimente vos activités de conformité ; l’utilisation du produit n’établit pas à elle seule la conformité réglementaire.
Inventaire cryptographique : questions fréquentes
Que doit contenir un inventaire cryptographique ?
Pour chaque actif cryptographique : l’algorithme, la taille de clé ou la courbe, le mode et le padding quand ils sont détectables ; pour les certificats, l’émetteur, la validité et l’algorithme de signature ; pour les endpoints TLS, les protocoles et suites de chiffrement négociés. Chaque entrée doit aussi porter sa provenance (fichier et ligne, certificat ou endpoint), son périmètre (production, test, exemple ou code tiers), son usage et son statut face au quantique. Sans provenance, un inventaire ne peut être ni audité ni exploité.
Une analyse trouvera-t-elle chaque usage de la cryptographie dans notre code ?
Nous ne le prétendons pas. La couverture dépend du langage et du style de code, et des valeurs transmises d’une méthode à une autre peuvent encore échapper à l’analyse. Dans notre comparatif publié sur Keycloak (en anglais), CBOMkit a trouvé des lignes de production que notre première analyse avait manquées ; nous avons corrigé les règles Java et publié la nouvelle analyse, y compris les 4 lignes encore manquées. Testez tout outil sur du code qui ressemble au vôtre avant de choisir.
Chaque détection est-elle une vulnérabilité ?
Non. Imports, tables de correspondance d’algorithmes, vecteurs de test et tests de capacité comptent tous comme des détections, et ils n’ont pas le même sens. Chaque résultat est étiqueté par périmètre, pour ne pas confondre fixtures de test et bibliothèques embarquées avec la cryptographie de production. Dans notre analyse publiée de pyca/cryptography, 1 746 des 1 804 détections se trouvent dans les tests et 46 dans le code de la bibliothèque.
Notre code source quitte-t-il notre environnement ?
Non. La découverte s’exécute dans votre périmètre, on-prem ou air-gapped : analyse statique, lecture des certificats, handshakes TLS, score de risque, CBOM et rapport, tout s’exécute localement. L’analyse du code et des certificats est statique : le code analysé n’est pas exécuté. Voir déploiement et flux de données (en anglais).
Combien de temps prend un premier inventaire, et combien coûte-t-il ?
Nos tarifs sont publics. Le Pilote PQC Readiness établit l’état des lieux d’un domaine critique (3 à 5 dépôts et jusqu’à 20 endpoints TLS) pour 18 000 €, au tarif du programme de référence réservé aux 5 premiers clients de référence. La Discovery est à prix fixe : 45 000 € sur 60 jours, pour jusqu’à 50 dépôts, 100 endpoints TLS et vos magasins de certificats. L’offre Platform, à partir de 80 000 € par an, maintient l’inventaire à jour.
L’inventaire peut-il servir de preuve pour DORA ou NIS2 ?
Oui, comme preuve à l’appui. Chaque résultat porte sa provenance, et l’export est un CBOM CycloneDX 1.6 validé contre le schéma. L’article 21(2)(h) de NIS2 exige des politiques relatives à l’usage de la cryptographie, et le RTS de gestion des risques de DORA (règlement délégué (UE) 2024/1774) exige une politique de contrôles cryptographiques, une gestion des clés et un registre des certificats ; l’inventaire est la façon de montrer qu’elles sont appliquées. L’utilisation du produit n’établit pas à elle seule la conformité réglementaire.
Voyez un vrai inventaire en 30 minutes. Nous lançons la découverte en direct sur un dépôt public proche de votre stack et vous repartez avec le CBOM : aucun accès à votre code, aucun paiement avant de l’avoir vu fonctionner.
Demander une démo gratuite →