Cyber Resilience Act 2026 : SBOM, IA et post-quantique

Le 11 septembre 2026, l'article 14 du Cyber Resilience Act (UE 2024/2847) entre en application. Il impose la notification des vulnérabilités activement exploitées sous 24 heures. Pour respecter ce délai, les éditeurs et industriels doivent structurer un inventaire SBOM/VEX et adapter leur sécurité face aux risques de l'IA et du post-quantique. 

1. CRA Article 14 : les échéances du 11 septembre 2026 

Le Cyber Resilience Act (CRA) classe les produits numériques par niveau de criticité (produits par défaut, Classe I, Classe II, critiques). Si les exigences globales (marquage CE, documentation technique) s'appliqueront le 11 décembre 2027, l'obligation de signalement entre en vigueur dès le 11 septembre 2026 (article 14 du règlement UE 2024/2847).

Calendrier légal des notifications CRA : 

• H+24 : Transmission d'une alerte précoce dès la détection de la faille.
• H+72 : Envoi de la notification d'incident détaillée avec premières analyses.
• J+14 : Remise du rapport final après mise à disposition du correctif.

Point souvent négligé : l'obligation s'applique aussi aux produits déjà commercialisés, pas seulement aux nouvelles gammes. Les obligations « complètes » du CRA (documentation technique, marquage CE) n'entreront pleinement en vigueur qu'au 11 décembre 2027, mais le signalement, lui, ne laisse aucun délai de grâce.

Concrètement, toute entreprise sans PSIRT (Product Security Incident Response Team), sans canal de divulgation coordonnée (CVD) ni workflow de notification a un chantier à mener dès maintenant : contact sécurité identifié, procédure de tri, et clauses contractuelles revues avec ses fournisseurs pour garantir une remontée rapide en cas d'incident chez un sous-traitant. Deuxième chantier, indissociable du premier : une nomenclature logicielle à jour. La Commission européenne a publié fin juillet 2026 des lignes directrices non contraignantes pour clarifier le périmètre, mais le calendrier, lui, reste inchangé.

2. SBOM, VEX et CBOM : la traçabilité logicielle obligatoire 

Le signalement rapide d'une vulnérabilité exploitée suppose de savoir, en quelques heures,quels composants vulnérables sont présents et sur quels systèmes ils sont déployés. Sans inventaire fiable, impossible de tenir les délais de l'article 14.

Le SBOM (Software Bill of Materials) est la nomenclature exhaustive des composants logiciels d'un produit, open source et sous-dépendances compris. Les formats de référence attendus par le CRA sont CycloneDX et SPDX. Il répond à « qu'est-ce qu'il y a dedans ? ».

Le VEX (Vulnerability Exploitability eXchange) répond à une question différente et tout aussi critique : « ce composant vulnérable est-il réellement exploitable dans mon produit ? ». Une CVE (Common Vulnerabilities and Exposures) publiée sur une bibliothèque ne signifie pas que le produit qui l'embarque est affecté. Le VEX documente ce statut (affecté, non affecté, en cours de correction, corrigé) et évite qu'une équipe sécurité retraite manuellement des milliers d'alertes non pertinentes.

Un couple SBOM + VEX à jour permet de répondre en minutes, et non en jours, à « suis-je concerné par telle CVE ? », de documenter une non-exploitabilité vis-à-vis d'un auditeur, et de construire la trace exigée en cas de contrôle. Le SBOM s'intègre désormais dans la chaîne CI/CD, généré automatiquement à chaque build ; le VEX, lui, vit dans la durée et suppose une veille continue à chaque nouvelle CVE publiée sur le catalogue de composants.

Ce n'est plus un sujet « pour 2027 » : différer le SBOM en misant sur l'échéance de décembre 2027 ne tient pas face à l'obligation de notification, active dès septembre 2026.

3. La cryptographie post-quantique : anticiper une menace HNDL 

Le calendrier post-quantique donne une fausse impression de confort : les ordinateurs capables de casser des algorithmes de chiffrement comme RSA ou les courbes elliptiques ne sont pas encore là. Le problème, c'est que la menace agit déjà via les attaques Harvest Now, Decrypt Later [3] : des données chiffrées aujourd'hui sont collectées par des acteurs malveillants, dans l'attente d'un ordinateur quantique assez puissant pour les décrypter. Toute donnée devant rester confidentielle au-delà de l'horizon quantique est donc, dès aujourd'hui, une donnée à risque.

Le NIST (National Institute of Standards and Technology) a finalisé une première série de standards post-quantiques, et des agences comme l'ANSSI (Agence nationale de la sécurité des systèmes d'information) recommandent une phase d'hybridation : combiner un algorithme post-quantique avec un algorithme classique éprouvé, au sein d'un même certificat. Cette approche offre un filet de sécurité aux systèmes non encore compatibles avec la cryptographie post-quantique, tout en apportant dès maintenant une résistance quantique à ceux qui le sont.

Pour l'embarqué en particulier, un terrain que nous connaissons bien chez Smile, la transition n'est pas triviale : taille des clés et signatures, impact sur les performances des microcontrôleurs, compatibilité avec les chaînes de boot sécurisé existantes (U-Boot, OP-TEE). Une migration par étapes, avec des outils comme Yocto pour intégrer les nouvelles primitives dans les chaînes de build, évite un chantier de dernière minute, d'autant plus pour les produits à durée de vie longue (dix ou quinze ans, typiques de l'industriel ou de la défense), qui risquent d'être obsolètes en sécurité bien avant la fin de leur cycle de vie.

Reste une question préalable : comment migrer ce qu'on n'a pas cartographié ? C'est le rôle du CBOM (Cryptography Bill of Materials), extension de CycloneDX aux actifs cryptographiques (algorithmes, clés, certificats), qui permet de localiser précisément où un algorithme vulnérable au quantique est utilisé. Le CBOM est un prérequis naturel pour les clients déjà engagés dans une démarche SBOM/VEX.

4. IA Générative : accélération des failles et triage

Le dernier front est le plus mouvant : l'IA générative a fait entrer la découverte de vulnérabilités dans une phase d'accélération inédite, à double tranchant.

Côté défenseur, les résultats sont spectaculaires. Le noyau Linux a intégré plus de 400 correctifs de sécurité sur un seul cycle de développement, une partie détectée par des outils d'IA - jusqu'à repérer en une heure une vulnérabilité dormante depuis près de neuf ans. Linus Torvalds parle désormais d'une nouvelle norme pour le projet.

Côté volumétrie, cette même capacité pose un problème d'échelle : les signalements de vulnérabilités liés à l'IA ont progressé de 210 % en un an selon HackerOne. L'IA abaisse le niveau d'expertise requis pour produire un rapport exploitable, mais creuse l'écart entre détecter une faille et en comprendre réellement l'impact. Résultat : des équipes de sécurité sous tension, submergées de signalements parfois redondants ou mal qualifiés.

Côté attaquant, la même mécanique joue en sens inverse : des campagnes d'intrusion ont déjà montré qu'un acteur peu qualifié, assisté par l'IA, pouvait compromettre plusieurs centaines d'équipements réseau dans de nombreux pays, en automatisant l'exploitation de mauvaises configurations et d'identifiants faibles plutôt qu'en exploitant des failles inédites. L'IA industrialise et démocratise l'exécution de vecteurs d'attaque déjà connus.

Pour nos clients, la conséquence est triple : la fenêtre entre découverte et exploitation se réduit (encore un argument pour un SBOM/VEX à jour) ; l'IA doit être intégrée comme outil de triage, pas seulement redoutée comme accélérateur offensif ; et l'hygiène de base (configurations, authentification forte, identifiants) redevient prioritaire, car c'est elle que l'IA offensive exploite en premier.

En synthèse

Chez Smile, nous accompagnons nos clients sur chacun de ces axes - de l'audit de code et l'analyse de risque cyber jusqu'à la mise en conformité CRA et la sécurisation de chaînes de boot embarquées face au risque quantique. Si l'un de ces chantiers résonne avec vos priorités 2026, parlons-en.