La préparation quantique est un enjeu de chaîne d’approvisionnement logicielle. Votre SBOM ne révèle pas tous les risques

La préparation quantique devient un enjeu de chaîne d’approvisionnement logicielle. Avant de prioriser une migration vers la cryptographie post-quantique, les organisations doivent localiser les mécanismes cryptographiques dans leurs applications, leurs systèmes de compilation, leur infrastructure et chez leurs fournisseurs. Une nomenclature logicielle (SBOM) aide à identifier les composants, mais elle ne révèle pas automatiquement tous les algorithmes employés, la cryptographie négociée par un service à l’exécution, ni la capacité d’un fournisseur à effectuer une transition.

Le 14 octobre 2026, l’Agence de cybersécurité de Singapour (CSA) a précisé plusieurs jalons de migration vers des solutions résistantes à l’informatique quantique. Les directives CII publiques de la CSA exigent que les opérateurs CII soumettent leur plan de migration à la CSA au plus tard le 31 mars 2027 ; le 31 décembre 2031 est l’objectif d’achèvement de la migration. Elles indiquent aussi que les nouveaux achats de systèmes CII doivent tenir compte des considérations de sécurité post-quantique à partir de 2028. Pour les autres organisations exposées au risque quantique, la CSA recommande de préparer un plan d’ici fin 2027 et de viser l’achèvement de la migration en 2035. Ces dates relèvent des orientations de Singapour et des publics visés ; elles ne constituent pas des échéances universelles pour toutes les entreprises. Annonce de la CSA de Singapour · Avis de la CSA · Directives CII publiques et subvention Quantum-Safe Kickstarter

Le signal pour la planification est clair : les équipes ont besoin d’une vue étayée par des preuves de leurs dépendances cryptographiques, des responsables et des contraintes. La première étape consiste à les découvrir, pas à affirmer que le chiffrement actuel a déjà été cassé.

Pourquoi la préparation quantique commence par un inventaire

La date d’arrivée d’un ordinateur quantique capable de compromettre la cryptographie n’est pas connue. La cryptographie à clé publique fondée sur RSA et sur les courbes elliptiques classiques est considérée comme vulnérable face à un ordinateur quantique suffisamment puissant. Cela ne signifie pas qu’une telle machine s’attaque aujourd’hui aux systèmes déployés. Les organisations doivent tout de même prévoir du temps pour découvrir, tester et coordonner les changements dans les produits à longue durée de vie et chez leurs fournisseurs. La durée pendant laquelle les données collectées aujourd’hui doivent rester confidentielles peut aussi orienter les priorités.

Une SBOM est un socle important : elle consigne les composants logiciels et leurs relations. À elle seule, elle ne prouve pas quels algorithmes sont sélectionnés en production, quels certificats et clés sont actifs, comment est configurée une passerelle gérée par un fournisseur ni à quelle vitesse le micrologiciel d’un appareil peut être remplacé.

La cryptographie peut se trouver dans des éléments faciles à négliger :

• Une bibliothèque qui vérifie les signatures JWT ou établit des connexions TLS.
• Un service cloud ou un SDK qui délègue la gestion des clés ou la signature à un fournisseur de services gérés.
• Un prestataire de paiement, d’identité ou de messagerie qui a ses propres certificats et calendrier de transition.
• Une chaîne de compilation qui signe des paquets, conteneurs ou mises à jour logicielles avec de la cryptographie classique à clé publique.
• Des VPN, micrologiciels, appareils à longue durée de vie et modules de sécurité matériels qui ne peuvent être mis à jour au rythme des versions d’une application.
• Des bases de données et connexions entre services dont les protocoles et configurations sont gérés séparément.

La préparation quantique mobilise donc la sécurité, l’ingénierie, les achats et la gestion des fournisseurs. L’inventaire des composants indique où enquêter ; les preuves d’exécution et les informations des fournisseurs sont nécessaires pour comprendre l’exposition réelle.

Quels mécanismes cryptographiques examiner de plus près ?

L’expression « résistant au quantique » doit désigner un algorithme et un usage précis, pas une étiquette ou un score non validé. Augmenter la taille d’une clé de cryptographie classique à clé publique ne change pas le risque quantique de sa famille d’algorithmes. RSA-4096 reste du RSA ; les courbes elliptiques classiques plus robustes restent classiques.

Le NIST a finalisé FIPS 203, 204 et 205 le 13 août 2024. Ce sont des normes établies, et non des nouveautés d’octobre 2026. Choisir une norme ne prouve pas à lui seul qu’une implémentation, un protocole ou un système a été migré en toute sécurité. Publications du NIST sur la cryptographie post-quantique

Une nomenclature des éléments cryptographiques (CBOM) peut faciliter la documentation des ressources cryptographiques et de leurs relations. Selon les sources de découverte et le format, elle peut représenter des algorithmes, des composants cryptographiques, des métadonnées liées aux clés et leur contexte d’utilisation. CycloneDX publie une capacité CBOM et des éléments de spécification. Une CBOM est un artefact d’inventaire, pas la preuve que la couverture est complète ou qu’un système résiste au quantique. Capacité CBOM de CycloneDX

Que signifient les jalons de 2027 à 2035 ?

L’annonce et l’avis de la CSA distinguent les opérateurs de CII des autres organisations exposées au risque quantique :

• Soumission du plan de migration CII au plus tard le 31 mars 2027 : selon les directives publiques de la CSA, les opérateurs CII doivent transmettre leur plan à la CSA avant cette date.
• À partir de 2028 : les nouveaux achats de systèmes CII doivent tenir compte des considérations de sécurité post-quantique. Directives CII publiques et informations de la CSA
• Migration CII d’ici au 31 décembre 2031 : c’est l’objectif annoncé pour achever la migration des systèmes CII.
• Autres organisations exposées : la CSA recommande un plan d’ici fin 2027 et une migration d’ici 2035.

Le Centre national de cybersécurité du Royaume-Uni (NCSC) publie séparément des objectifs de référence : achever la découverte et l’évaluation, puis établir un plan initial d’ici 2028 ; prioriser et faire progresser la migration d’ici 2031 ; viser son achèvement sur les systèmes, services et produits d’ici 2035. Le NCSC note qu’un petit nombre de technologies rarement utilisées pourrait être plus difficile à migrer d’ici 2035 ; les organisations devraient néanmoins s’efforcer de respecter les dates indiquées. Il s’agit d’orientations britanniques, pas d’une législation mondiale. Chaque organisation doit déterminer les obligations locales, sectorielles et contractuelles qui s’appliquent réellement. Calendrier de migration PQC du NCSC britannique

Au 16 octobre 2026, le plan de transition du NIST IR 8547 est un projet. Il ne doit pas être présenté comme une échéance juridique générale et définitive pour les entreprises privées. Projet NIST IR 8547

La leçon pratique est de commencer tôt la découverte. Une migration peut impliquer les responsables applicatifs, la compatibilité des protocoles, le renouvellement du matériel, les fournisseurs et les engagements clients. Remplacer une bibliothèque peut être la partie la plus simple du travail.

Des listes de composants aux inventaires connectés

CycloneDX prend déjà en charge les CBOM. La version 1.6 a introduit cette capacité et la version 1.7 a ajouté des identifiants de familles d’algorithmes cryptographiques et de courbes elliptiques. Le 5 août 2026, le projet a annoncé ses plans pour CycloneDX 2.0, en évoquant la possibilité d’associer les actifs cryptographiques à des risques et mesures de migration, des responsables, des dates cibles et un état d’avancement.

Au 16 octobre 2026, CycloneDX 2.0 a été annoncée comme prochaine version, attendue plus tard à l’automne ; elle n’a pas encore été publiée ni ratifiée. Les déclarations actuelles sur un produit ou la conformité ne doivent pas présumer de sa prise en charge. Annonce de CycloneDX 2.0 · CBOM CycloneDX

Un inventaire étendu peut relier trois questions distinctes :

1. SBOM : Quels composants logiciels, versions, fournisseurs et dépendances font partie du produit ?
2. CBOM : Quels algorithmes et contextes cryptographiques doivent être évalués ou migrés ?
3. AIBOM : Quels modèles d’IA, fournisseurs et composants associés sont utilisés dans le produit ?

Ces inventaires sont complémentaires ; ils ne constituent pas des garanties de sécurité interchangeables. Une nomenclature étendue (XBOM) est une approche permettant de les organiser et de les relier pour enquêter sur les dépendances tout en conservant leur contexte. Le contenu et la couverture réels dépendent toujours de ce qui a été analysé, de sa classification et des éléments externes ajoutés.

Le CISA et des agences partenaires ont publié le 8 septembre 2026 les 2026 Minimum Elements for an SBOM. Cette publication actualise les éléments minimaux recommandés et préconise de maintenir les SBOM à mesure que les logiciels évoluent ; elle ne crée pas de nouvelles obligations à elle seule. Il faut distinguer ces recommandations des obligations issues des lois, règlements, contrats ou règles sectorielles applicables. CISA et agences partenaires : éléments minimaux 2026 pour une SBOM

D’autres données sur la chaîne d’approvisionnement fournissent du contexte, pas des preuves d’attaques quantiques. Le rapport du troisième trimestre de Sonatype, publié le 8 octobre 2026, a recensé 149 329 paquets signalés au total dans ses catégories de paquets malveillants et indésirables ; 27 618 présentaient au moins un comportement manifestement malveillant. Le total des paquets signalés ne signifie pas que les 149 329 sont tous des logiciels malveillants confirmés. Ces chiffres étayent l’intérêt général du suivi des composants et de l’analyse d’impact ; ils ne signalent ni attaques quantiques ni échecs de migration cryptographique. Rapport Sonatype Q3 2026

Construire un inventaire utile à la décision

Pour chaque actif cryptographique important, consignez assez d’éléments pour répondre à des questions concrètes :

L’agilité cryptographique désigne la capacité à changer de mécanismes cryptographiques dans les applications, protocoles, matériels et infrastructures avec un risque opérationnel maîtrisé. Le livre blanc du NIST sur l’agilité cryptographique, CSWP 39 révision 1, a été finalisé le 29 juin 2026 ; la version initiale a été publiée en décembre 2025. Il propose des pistes de planification, pas une certification ni la preuve qu’une organisation donnée est agile. NIST CSWP 39 révision 1

Évitez la fausse précision. Un « pourcentage de préparation quantique » a peu de sens sans périmètre défini, classification validée, preuves de couverture, criticité des actifs et description des éléments non évalués. L’analyse du code seule ne peut pas établir l’état de chaque certificat en production, module de sécurité matériel, service géré ou environnement fournisseur. Vérifiez les classifications d’algorithmes par rapport aux références du NIST et complétez les inventaires avec des preuves d’exécution, de configuration et des fournisseurs.

Un plan de démarrage pratique sur 90 jours

Jours 1 à 15 : désigner un responsable et choisir le périmètre

Nommez un responsable du programme et choisissez un service ou produit représentatif et critique pour l’activité. Documentez la durée de conservation des données sensibles, les usages de signature et d’échange de clés, les interfaces réseau, le processus de publication et les principaux fournisseurs. Définissez le périmètre afin que le premier inventaire puisse être examiné.

Jours 16 à 30 : recueillir les premiers éléments

Rassemblez les inventaires logiciels et les informations cryptographiques disponibles à partir du code source, des systèmes de compilation, des configurations et des dossiers d’infrastructure. Notez les algorithmes et leurs versions, les références de certificats et de clés lorsque cela peut être fait sans risque, le contexte système, les frontières de confiance et les dépendances fournisseurs. Signalez explicitement les zones inconnues ou non observées.

Jours 31 à 45 : prioriser selon les conséquences

Examinez les données sensibles qui doivent rester confidentielles pendant plusieurs années, les services exposés à l’extérieur, l’infrastructure de signature, les dépendances critiques et les appareils ou micrologiciels difficiles à mettre à jour. Considérez RSA et l’ECC classique comme de la cryptographie à clé publique vulnérable au quantique, même si elle reste adaptée à la sécurité classique aujourd’hui.

Jours 46 à 60 : dialoguer avec les fournisseurs

Demandez quels produits et services utilisent la cryptographie à clé publique, comment les fournisseurs prévoient une transition post-quantique ou hybride lorsque cela convient, quelles modifications sont nécessaires côté client et comment ils testeront l’interopérabilité et communiqueront les jalons. Consignez leurs réponses et les preuves ; ne déduisez pas leur préparation d’un message marketing.

Jours 61 à 75 : tester dans des environnements contrôlés

Essayez certaines modifications d’établissement de clés ou de signature dans des systèmes hors production. Mesurez l’interopérabilité, la latence, la taille des certificats et signatures, les performances, le fonctionnement des solutions de repli, la supervision et les procédures de retour arrière. Faites examiner les résultats par les responsables concernés en ingénierie et sécurité.

Jours 76 à 90 : publier une feuille de route

Transformez les résultats en responsables, lacunes de preuves, dépendances, niveaux de confiance et jalons séquencés. Associez chaque jalon à un système et à une méthode de vérification. Mettez à jour l’inventaire lors de changements logiciels, cryptographiques ou fournisseurs.

N’attendez pas une couverture parfaite avant de traiter les risques les plus importants. Avancez de manière itérative et fondée sur les risques, en indiquant clairement les limites.

Quelle place pour Plexicus XBOM ?

La page publique Plexicus XBOM présente SBOM, CBOM et AIBOM dans un même flux de travail et permet de demander une présentation du produit. Elle peut servir de point de départ aux équipes qui explorent les inventaires connectés. Elle ne prouve pas une découverte cryptographique complète, une classification quantique correcte, une couverture de l’exécution ou du matériel, la vérification des fournisseurs, une migration PQC garantie ou la conformité réglementaire.

Avant de vous appuyer sur un outil d’inventaire pour prendre des décisions de migration, vérifiez sa couverture réelle et sa classification au regard des références du NIST. Complétez les résultats issus du code par des contrôles d’exécution et de configuration, des éléments fournis par les fournisseurs et des tests dans les systèmes concernés.

Commencez par savoir clairement ce qui est connu et ce qui ne l’est pas encore.

Découvrir Plexicus XBOM et demander une présentation →

Aujourd’hui, le sujet quantique relève de la planification

Rien ne prouve qu’un ordinateur quantique pertinent pour la cryptographie casse actuellement les déploiements habituels de cryptographie à clé publique. La tâche immédiate consiste à déterminer quels systèmes dépendent de mécanismes vulnérables au quantique, où l’information est incomplète et combien de temps prendront l’évaluation et la migration.

Une SBOM fournit une base précieuse sur les composants. Une CBOM peut décrire les actifs cryptographiques si la découverte et la classification sont adaptées. Une XBOM peut relier les inventaires logiciels, cryptographiques et d’IA. Aucune ne remplace les tests d’exécution, les échanges avec les fournisseurs, la responsabilité technique ou un plan de migration.

La préparation quantique commence par un programme d’inventaire et de gouvernance. Le plan doit rendre visibles son périmètre, les preuves, les incertitudes, les responsables et les jalons locaux applicables.

Demander une présentation de Plexicus XBOM →

Questions fréquentes

RSA-4096 résiste-t-il à l’informatique quantique ?

Non. Une clé plus longue ne change pas la famille d’algorithmes RSA. RSA, y compris RSA-4096, et la cryptographie classique à clé publique sur courbes elliptiques sont considérés comme vulnérables face à un ordinateur quantique suffisamment puissant.

Une CBOM est-elle légalement obligatoire pour migrer vers la cryptographie post-quantique ?

Il n’existe pas de règle mondiale unique qui impose à toutes les organisations de produire une CBOM dans un format donné. Les exigences dépendent du pays, du secteur, des contrats et des règles applicables. Un inventaire cryptographique structuré facilite la planification ; chaque organisation doit vérifier les obligations qui la concernent.

Une SBOM ou une CBOM peut-elle, à elle seule, prouver la préparation quantique ?

Non. L’inventaire doit avoir un périmètre adapté et des classifications exactes, puis être confronté à la configuration d’exécution, au matériel et aux informations des fournisseurs. Des tests, une priorisation et une feuille de route de migration sont également nécessaires.

CycloneDX 2.0 est-il déjà disponible ?

Au 16 octobre 2026, le projet décrit CycloneDX 2.0 comme une prochaine version. Ne présumez ni de sa disponibilité générale ni de sa prise en charge par un produit donné. CycloneDX 1.7 est la dernière version 1.x publiée mentionnée dans les ressources publiques du projet.

Quelles normes post-quantiques du NIST sont finalisées ?

Le NIST a finalisé FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) et FIPS 205 (SLH-DSA) le 13 août 2024. Leur choix et leur déploiement demandent encore une conception, une mise en œuvre et des tests propres à chaque système.

Les jalons singapouriens de 2031 et 2035 sont-ils des échéances mondiales ?

Non. Ce sont les jalons de la CSA pour les opérateurs CII et des recommandations pour les autres organisations exposées au risque quantique. Le NCSC britannique publie des objectifs distincts. L’applicabilité dépend du pays, du secteur, des contrats et de l’organisation.

Plexicus XBOM garantit-il une migration PQC ou la conformité ?

Non. La page publique présente SBOM, CBOM et AIBOM dans un même flux de travail et invite à demander une présentation. Cela ne démontre ni une découverte complète, ni une classification correcte, ni une couverture de l’exécution ou des fournisseurs, ni une migration réussie ou la conformité.

Sources

• CSA de Singapour, annonce des jalons de migration quantique et d’une nouvelle subvention, 14 octobre 2026.
• CSA de Singapour, avis sur la migration résistante au quantique pour les organisations, 14 octobre 2026.
• CSA de Singapour, subvention Quantum-Safe Kickstarter et informations sur les achats.
• NCSC britannique, calendrier de migration PQC.
• NIST, publications et normes de cryptographie post-quantique.
• NIST, CSWP 39 révision 1 : Considerations for Achieving Crypto Agility, finalisé le 29 juin 2026.
• NIST, premier projet public IR 8547.
• Centre canadien pour la cybersécurité et partenaires du G7, Preparing for the Post-Quantum Era, septembre 2026.
• CycloneDX, capacité CBOM et annonce de CycloneDX 2.0.
• CISA et agences partenaires, 2026 Minimum Elements for an SBOM, 8 septembre 2026.
• Sonatype, Q3 2026 Open Source Malware Index, 8 octobre 2026.
• Plexicus, XBOM.