Le reporting CRA a commencé : pouvez-vous nommer chaque produit concerné en 24 heures ?

Le Cyber Resilience Act (CRA), règlement (UE) 2024/2847, impose des exigences de cybersécurité obligatoires aux produits matériels et logiciels comportant des éléments numériques mis sur le marché de l'UE. L'essentiel du débat a porté jusqu'ici sur décembre 2027, date d'application des principales obligations. Mais une partie du règlement s'applique déjà : depuis le 11 septembre 2026, les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves qui touchent leurs produits.

Le délai court à partir du moment où le fabricant a connaissance du problème. Une alerte précoce est due sous 24 heures. Cette échéance transforme une question de données d'ingénierie en question de conformité : quand une vulnérabilité est découverte dans un composant, votre équipe peut-elle dire, en quelques heures, lesquels de vos produits le contiennent ?

Cet article explique ce que le CRA demande aujourd'hui et en 2027, pourquoi il est difficile d'y répondre avec des fichiers et des tableurs, et comment un système d'ingénierie IA du hardware réglementé y répond en quelques minutes. Pour une vue d'ensemble du règlement et de son effet sur les équipes hardware, voir notre article précédent sur le mur de conformité du CRA.

Ce que le CRA exige, en bref

Le CRA est entré en vigueur le 10 décembre 2024. Ses obligations s'appliquent en deux temps.

À partir du 11 septembre 2026 : le signalement. Les fabricants doivent notifier les vulnérabilités activement exploitées dans leurs produits et les incidents graves qui affectent la sécurité de leurs produits. Les notifications sont adressées au CSIRT désigné comme coordinateur et à l'ENISA.

À partir du 11 décembre 2027 : l'ensemble des obligations. Les produits doivent respecter les exigences essentielles de cybersécurité de l'annexe I, les fabricants doivent assurer la gestion des vulnérabilités pendant la période de support, réaliser l'évaluation de la conformité adaptée à la classe du produit, établir la documentation technique et apposer le marquage CE.

Quelques obligations méritent l'attention, parce que ce sont des obligations de données autant que de sécurité :

• —Le SBOM. Les fabricants doivent établir une nomenclature logicielle (SBOM) dans un format courant et lisible par machine, couvrant au moins les dépendances de premier niveau du produit, dans le cadre de la documentation technique.
• —La période de support. Elle doit refléter la durée d'utilisation attendue du produit, et dure au moins cinq ans, sauf si le produit est destiné à être utilisé moins longtemps. Les vulnérabilités doivent être traitées pendant toute cette période.
• —La conservation. La documentation technique doit être conservée dix ans après la mise sur le marché du produit, ou pendant la période de support si elle est plus longue.
• —Les classes de produits. Les produits sont par défaut, importants (classe I ou II) ou critiques. La classe détermine la procédure d'évaluation de la conformité, de l'auto-évaluation à l'évaluation par un tiers.

Ce que le délai de signalement demande vraiment

Pour une vulnérabilité activement exploitée, le CRA fixe trois échéances :

1. 1.Une alerte précoce sous 24 heures à compter de la prise de connaissance.
2. 2.Une notification de vulnérabilité sous 72 heures, avec des informations générales sur le produit, la vulnérabilité et les mesures correctives ou d'atténuation prises ou disponibles.
3. 3.Un rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective ou d'atténuation. Pour un incident grave, le rapport final est dû dans un délai d'un mois.

L'alerte précoce doit indiquer quel produit est concerné. En pratique, l'équipe ne peut pas la rédiger sans répondre à quatre questions :

• —Lesquels de nos produits contiennent le composant vulnérable, et dans quelles variantes ?
• —Quelles versions de firmware ou de logiciel l'embarquent, et quelles configurations sont sur le terrain ?
• —Qui est responsable de chaque produit concerné, et quels fournisseurs sont impliqués ?
• —Quelles exigences essentielles et quels essais la correction rouvre-t-elle ?

Pourquoi les fichiers et les tableurs échouent au test des 24 heures

Prenons un cas courant. Une vulnérabilité est publiée dans la pile réseau d'un module radio, ou dans une bibliothèque de cryptographie utilisée par un firmware de microcontrôleur. Le responsable sécurité reçoit l'alerte à 9 h.

Dans la plupart des entreprises hardware, la réponse est répartie entre plusieurs systèmes. Le SBOM, quand il existe, est un fichier généré au build et rangé avec la version. La correspondance entre versions de firmware et variantes de produit vit dans un tableur. La liste des configurations livrées est dans l'ERP ou une base de service. Le responsable de chaque produit est connu des personnes qui y ont travaillé. Le lien entre le composant et les exigences essentielles, si quelqu'un l'a fait, est dans un document de conformité.

Répondre aux quatre questions oblige à ouvrir chacune de ces sources, à réconcilier les identifiants à la main et à interroger des collègues. Pour une gamme de produits, cela prend une journée. Pour un portefeuille de produits avec des variantes et des années de versions de firmware, cela prend plusieurs jours. L'échéance de 24 heures n'attend pas la réconciliation.

Le problème n'est pas un manque d'expertise en sécurité. C'est que la réponse dépend de liens entre des données d'ingénierie que personne ne tient au même endroit.

Comment Koddex répond à la question

Koddex est un système d'ingénierie IA du hardware réglementé. Les équipes y modélisent leurs produits dans leur propre vocabulaire : pièces, assemblages, versions de firmware, exigences, essais et liens entre eux. Koddex n'a pas de « module CRA » prêt à l'emploi. Le CRA devient gérable parce que les données dont il a besoin peuvent être modélisées comme des éléments liés, auxquels s'appliquent alors les capacités suivantes.

Les composants du SBOM comme éléments liés. Chaque composant logiciel du SBOM est un élément, relié aux versions de firmware qui l'intègrent. Les versions de firmware sont reliées aux variantes de produit et aux révisions matérielles sur lesquelles elles tournent. Quand un composant est signalé vulnérable, la chaîne du composant au produit est déjà déclarée.

L'analyse d'impact en quelques secondes. Sélectionnez le composant vulnérable : l'analyse d'impact liste chaque version de firmware, variante et produit qui en dépend, en amont et en aval, avec le responsable et le statut de chaque élément. La réponse à la première question de l'alerte précoce prend quelques secondes au lieu de plusieurs jours.

Des baselines de version figées. Chaque version est figée en baseline : la configuration exacte livrée, avec son SBOM, ses exigences et ses résultats d'essais à cette date. Vous pouvez montrer quelles configurations sur le terrain contiennent le composant, et comparer deux versions pour voir quand il a été introduit ou retiré.

Les exigences essentielles reliées à leurs preuves. Les exigences de l'annexe I sont des éléments, reliés aux choix de conception et aux essais qui y répondent. Quand une correction modifie un composant, Koddex montre quelles exigences et quels essais elle rouvre, et les preuves de conformité restent à jour. C'est la même approche que la traçabilité prête pour l'audit dans d'autres industries réglementées.

Des décisions tracées et des accès par périmètre. Chaque modification et chaque décision est journalisée avec son auteur, personne ou agent. Chaque fournisseur ne voit que son périmètre du modèle : un fournisseur de module peut mettre à jour ses composants sans voir le reste de votre portefeuille. L'hébergement et le contrôle d'accès sont décrits sur la page sécurité.

Les agents IA pendant les premières 24 heures

Les échéances de signalement sont le moment où les agents IA aident le plus, comme des coéquipiers qui prennent les tâches qu'on leur assigne et rendent le résultat pour validation.

Quand l'alerte arrive, le responsable sécurité assigne une tâche à un agent : confronter le composant signalé aux éléments du SBOM et lister ce qu'il touche. L'agent travaille avec les droits de son compte de service. Il lit le composant, les versions de firmware, les variantes et les baselines, et rend la liste des produits concernés avec leurs responsables. Il commente les éléments qu'il a consultés, pour que la trace reste sur les données.

Une seconde tâche prépare le brouillon de l'alerte précoce puis, plus tard, de la notification à 72 heures, à partir de la liste des produits concernés et des informations confirmées par l'équipe. Le brouillon va au responsable de la sécurité produit, qui le corrige et l'approuve. Les agents n'envoient rien aux autorités de leur propre chef : un ingénieur relit et signe chaque notification.

Quand la correction est prête, l'agent liste les exigences et les essais que la modification rouvre et prépare les preuves du rapport final. L'ingénieur approuve le résultat, comme une pull request.

Préparer décembre 2027

Le travail fait pour le signalement prépare aussi les obligations complètes de décembre 2027 :

• —Une documentation technique par baseline. Chaque baseline de version contient son SBOM, ses exigences, son évaluation des risques et ses preuves d'essais, et peut être exportée comme documentation technique de cette version.
• —La période de support. Comme les baselines sont conservées avec leurs liens, une vulnérabilité découverte des années après une version peut encore être reliée aux produits et configurations qu'elle touche.
• —La conservation sur dix ans. La documentation n'est pas reconstruite pour chaque audit. C'est l'état du modèle, figé à chaque version et conservé.

Une liste de contrôle pratique

1. 1.Classez vos produits comportant des éléments numériques : par défaut, importants de classe I ou II, ou critiques.
2. 2.Générez un SBOM pour chaque version dans un format lisible par machine, couvrant au moins les dépendances de premier niveau.
3. 3.Reliez les composants du SBOM aux versions de firmware, et les versions de firmware aux variantes de produit et aux révisions matérielles.
4. 4.Figez chaque version en baseline avec son SBOM, ses exigences et ses résultats d'essais.
5. 5.Nommez un responsable pour chaque produit et chaque composant fourni par un fournisseur.
6. 6.Reliez les exigences essentielles de l'annexe I aux choix de conception et aux essais qui y répondent.
7. 7.Répétez le scénario des 24 heures : choisissez un composant, mesurez le temps nécessaire pour lister chaque produit concerné, et corrigez ce qui vous ralentit.
8. 8.Définissez qui approuve chaque notification avant tout envoi.

Si l'étape 7 prend plus d'une heure, ce sont vos données qui vous ralentissent, pas votre équipe sécurité.

Conclusion

Le CRA transforme une question que les équipes d'ingénierie posent rarement sous pression en une question à laquelle elles doivent répondre en 24 heures : où est ce composant, et que touche-t-il ? Les équipes qui gardent leur SBOM, leurs versions de firmware, leurs variantes, leurs baselines et leurs exigences dans des fichiers séparés passeront la première journée à les réconcilier. Celles qui les gardent reliés dans un seul modèle la passeront à corriger le problème.

Koddex est conçu pour cette seconde situation. Pendant une démo de 20 minutes, nous montrons comment un composant vulnérable est relié à chaque produit concerné sur un portefeuille comparable au vôtre, puis votre premier cas d'usage est en service dans votre propre Koddex sous un mois. La même approche s'applique à tout le hardware réglementé, de la robotique au manufacturing avancé.