Christophe Blaess

Imaginons une situation qui, malheureusement, risque de devenir familière aux fabricants de produits connectés.

Mardi matin, 9 h 15. Vous apprenez qu’une vulnérabilité concernant une bibliothèque Open Source utilisée dans votre produit est désormais activement exploitée. (La définition d’activement exploitée, terme utilisé dans le CRA, Cyber Resilience Act, sera détaillée plus bas)

Votre produit est déjà commercialisé. Plusieurs dizaines, centaines voire milliers d’équipements sont installés chez vos clients. Certains sont accessibles par le réseau, d’autres se trouvent derrière une infrastructure protégée. Comment réagir ?

La première question est évidemment d’ordre technique : êtes-vous réellement concernés par cette vulnérabilité ?

Mais depuis le mois de septembre 2026, une autre question doit immédiatement être posée : quelles sont vos obligations au regard du Cyber Resilience Act ?

Les obligations de notification prévues par l’article 14 du CRA sont en effet applicables depuis le 11/09/2026 et la plateforme unique de signalement, ou Single Reporting Platform (SRP), gérée par l’ENISA est désormais accessible aux fabricants de systèmes embarqués.

Nous allons examiner concrètement les étapes à suivre dans une telle situation et voir comment une plateforme comme Eris Linux peut simplifier une partie de ce travail.

Une vulnérabilité « activement exploitée »

Le CRA distingue plusieurs notions :

• Une vulnérabilité est une faiblesse susceptible d’être exploitée dans le cadre de la cybersécurité.
• Une vulnérabilité exploitable est une vulnérabilité qui peut effectivement être utilisée par un attaquant dans des conditions réelles. Toutes les vulnérabilités ne sont pas exploitables. Si l’unique moyen d’interagir avec un équipement est d’appuyer sur un bouton (imaginez un chronomètre), le débordement de buffer contenu dans une fonction de bibliothèque jamais appelée en fonctionnement nominal est bien une vulnérabilité, mais elle n’est pas exploitable. Si, en revanche, l’équipement dispose d’une connexion Internet pour télécharger ses mesures et récupérer des paramètres de configuration, le risque est plus grand de voir son comportement détourné par des données corrompues.
• Une vulnérabilité activement exploitée est définie plus précisément comme une vulnérabilité pour laquelle il existe des preuves fiables qu’un acteur malveillant l’a exploitée dans un système sans l’autorisation du propriétaire de ce système. Une découverte effectuée dans le cadre d’une recherche de sécurité ou d’un test effectué de bonne foi n’est donc pas, à elle seule, une exploitation active.

Une remarque importante : l’exploitation malveillante de la vulnérabilité ne doit pas nécessairement être observée sur votre produit. Si une vulnérabilité a été activement exploitée sur un autre produit (éventuellement un de vos concurrents), mais qu’elle est exploitable dans votre système, vous êtes concernés.

Reprenons notre exemple, supposons que l’information soit suffisamment confirmée pour considérer la vulnérabilité comme activement exploitée. Il faut alors déterminer si elle est contenue dans votre produit.

Vérification de présence du package vulnérable

Cette étape peut sembler triviale, mais elle ne l’est pas du tout sur un produit Linux embarqué moderne.

Une image Linux peut contenir plusieurs centaines de packages, eux-mêmes constitués de bibliothèques dont les versions ne sont pas toujours directement visibles par le développeur. Les applications métier ajoutent leurs propres dépendances.

Il faut donc être capable de répondre rapidement à une question simple : quels produits et quelles versions de ces produits contiennent réellement le composant vulnérable ?

C’est l’un des intérêts d’une nomenclature logicielle, ou Software Bill of Materials (SBOM). Le CRA prévoit d’ailleurs, parmi les exigences relatives au traitement des vulnérabilités, la documentation des composants présents dans le produit, avec une SBOM dans un format couramment utilisé et lisible par machine couvrant au minimum les dépendances de premier niveau. Un document au format standardisé SPDX par exemple avec une représentation JSON conviendra.

Découverte confirmée

Supposons que vous découvrez dans un de vos produits la présence d’un composant présentant une vulnérabilité activement exploitée (même si cette exploitation active a lieu sur un produit différent).

Supposons également que vous ne pouvez pas éliminer l’hypothèse que cette vulnérabilité soit exploitable sur votre équipement. Tant que vous n’avez pas établi que la vulnérabilité est inexploitable dans votre produit, son analyse devient prioritaire : le délai de notification est suffisamment court pour qu’il soit dangereux d’attendre avant d’étudier sérieusement la situation. Dès lors que les conditions de notification sont établies, le délai prévu par l’article 14 s’applique.

L’heure tourne

À partir de ce moment, vous avez des obligations de notifications. Je vous conseille de prendre date en communiquant la situation en interne, à votre hiérarchie ou à vos collègues avec un média conservant trace de la date et l’heure de découverte. Par exemple un simple e-mail peut suffire :

Bonjour,

Je viens d'apprendre que la libfoo présente une vulnérabilité
activement exploitée au moins jusqu'à sa version 1.2.3.
Pour en savoir plus : CVE-2026-.....
Dans notre produit XYZ v2 nous embarquons la version 1.2.1.
Je vais vérifier si la vulnérabilité est exploitable dans
notre produit et le cas échéant démarrer les notifications
réglementaires.

Cordialement.

Ce message permet de tracer en interne le moment où l’information a été portée à votre connaissance ; il ne permet évidemment pas de choisir artificiellement le point de départ du délai réglementaire.

L’article 14 prévoit plusieurs étapes :

• Au plus tard 24 heures après en avoir pris connaissance, le fabricant doit transmettre une alerte simplifiée par l’intermédiaire de la Single Reporting Platform (SRP). Cette première notification n’a pas vocation à contenir une analyse technique complète. Le fabricant peut encore être en train d’étudier la vulnérabilité et son impact.
• Au plus tard 72 heures après la prise de connaissance, une notification plus complète doit être transmise. Elle doit notamment contenir les informations disponibles sur le produit concerné, la nature générale de la vulnérabilité et de son exploitation, les mesures correctives ou d’atténuation déjà prises ainsi que celles que les utilisateurs peuvent mettre en œuvre.
• Enfin, un rapport final doit être transmis au plus tard quatorze jours après la disponibilité d’une mesure corrective ou d’atténuation. Il doit notamment préciser la vulnérabilité, sa gravité, ses répercussions et les mesures mises en place pour y remédier.

Cela signifie que deux activités doivent immédiatement progresser en parallèle : la réponse réglementaire d’une part, et l’analyse technique (puis la correction) d’autre part.

Sommes-nous réellement vulnérables ?

Revenons à notre exemple. Supposons que la vulnérabilité concerne une bibliothèque nommée libfoo dans sa version 1.2.3. Cette bibliothèque est utilisée dans votre application métier (avec Eris Linux, elle est embarquée dans le container de l’application).

À noter : si la vulnérabilité concernait un composant du socle Eris Linux, la correction prendrait la forme d’une mise à jour du système fournie par Eris plutôt que d’une nouvelle version du container applicatif

La première chose à faire est de déterminer si cette bibliothèque est présente dans les versions du produit actuellement déployées. Mais la simple présence d’une version vulnérable ne signifie pas nécessairement que le produit soit exploitable dans sa configuration réelle.

Il faudra par exemple déterminer si la fonction vulnérable est utilisée, si elle est accessible à un attaquant, si un service concerné est exposé au réseau ou encore si des protections existantes rendent l’exploitation impossible ou sensiblement plus difficile. Ce travail d’analyse est important pour évaluer le risque et choisir les mesures appropriées.

Il ne faut cependant pas confondre cette évaluation avec la décision de notifier une vulnérabilité activement exploitée. Lorsque les conditions de l’article 14 sont réunies, le délai réglementaire ne s’interrompt pas pendant que les ingénieurs poursuivent leurs investigations.

Mardi 10 h 30, nous savons par exemple que trois versions de notre produit utilisent libfoo, mais nous ne savons pas encore si toutes sont réellement exploitables. Cette information est déjà utile.

Quels équipements sont concernés ?

L’étape suivante consiste à passer de la notion abstraite de « version du produit » à la réalité du parc installé.

Pour un fabricant, connaître la composition de son logiciel est nécessaire mais insuffisant. Il faut également savoir quelles versions fonctionnent effectivement sur les équipements déployés.

C’est ici que la gestion centralisée des équipements devient particulièrement importante.

Le Device Manager d’Eris Linux permet de connaître la version du système utilisée par les équipements enregistrés ainsi que les versions des applications conteneurisées qui y sont déployées. On peut ainsi déterminer quels groupes ou quels équipements utilisent encore une version potentiellement vulnérable.

Cette information est utile à la fois pour évaluer l’ampleur du problème et, quelques heures ou quelques jours plus tard, pour suivre le déploiement du correctif.

Première alerte transmise sur la plateforme SRP

Le mardi 16h45, vous avez la liste des équipements concernés où la vulnérabilité est exploitable.

Vous vous connectez sur le site SRP de l’ENISA : https://www.enisa.europa.eu/topics/product-security/vulnerability-services/eu-incident-response-and-cyber-crisis-management/single-reporting-platform-srp

Vous y indiquez :

• (Notification type) qu’il s’agit d’une « vulnérabilité » (la même plateforme permet aussi de notifier les « incidents sévères de sécurité« ).
• (Title) Une description concise (exemple : « Présence d’une vulnérabilité activement exploitée dans le produit XYZ » ) en anglais de préférence même si la traduction de la plateforme dans les langues européennes est en cours.
• (Summary) Une description plus complète précisant la vulnérabilité concernée, les numéros de versions, les mesures de correction en cours (exemple : « La librairie libfoo présente une vulnérabilité activement exploitée jusqu’à sa version 1.2.3. Notre produit XYZ en version v.2 inclut la version 1.2.1 de cette bibliothèque. Nous préparons une mise à jour de notre système dès que le correctif sera disponible auprès du fournisseur de la bibliothèque » ).
• (Manufacturer name) Votre nom de société.
• (Member states…) La liste des états de l’Union Européenne où le produit a été mis à disposition.
• (Product Name & Version) Le nom du produit et ses numéros de version concernés.
• (Date and type when you become aware.) La date et l’heure où vous avez été avertis de l’existence de la vulnérabilité.
• D’autres champs peuvent être remplis, mais ils restent optionnels à ce stade.

Evaluation de la situation et perspectives

Une mise à jour définitive n’est pas toujours disponible immédiatement. La bibliothèque vulnérable peut provenir d’un projet Open Source externe. Un correctif peut être en cours de développement. Il faudra ensuite l’intégrer, reconstruire le produit et réaliser les tests nécessaires avant son déploiement.

Dans l’intervalle, des mesures d’atténuation peuvent parfois être envisagées. On peut par exemple désactiver temporairement un service, modifier une configuration réseau, supprimer une fonctionnalité exposée ou recommander aux utilisateurs de filtrer certains accès.

Le CRA prévoit explicitement que la notification à 72 heures décrive, lorsqu’elles sont disponibles, les mesures correctives ou d’atténuation prises ainsi que celles que les utilisateurs peuvent appliquer. Dans les cas les plus graves on peut leur recommander de ne pas utiliser certaines fonctionnalités, voire d’éteindre complètement l’équipement pour les cas vraiment critiques.

Il est donc utile d’avoir réfléchi avant l’incident aux moyens permettant de contacter les utilisateurs et de leur communiquer rapidement des instructions fiables. Cela nécessite de disposer d’un moyen de communication générale (par exemple une annonce sur le site web du produit) et si possible et si la criticité de la situation l’exige un contact direct par e-mail.

À noter : Le RGPD n’interdit pas de conserver des coordonnées destinées aux alertes de sécurité. Il faut néanmoins déterminer la base légale (par exemple « la poursuite d’un intérêt légitime » ) et définir une durée de conservation proportionnée à la finalité du produit.

Mise à jour de la notification SRP

Nous sommes à présent le jeudi matin 10h, quarante-huit heures après la découverte initiale. Vous allez compléter votre signalement initial en complétant les champs précédents et en ajoutant certains d’entre-eux :

• (Product Type & Class) Le type de produit et éventuellement sa classe (Défaut, Important avec des composants numériques, Critique avec des composants numériques). Eris Linux entre a priori dans le type « Important » de classe I, et les applications utilisateurs plutôt dans le type « Défaut« .
• (Composant name) Le composant concerné (exemple : « authentification utilisateur » , « bibliothèque de compression de données » , « module parser de fichiers de configuration » ).
• (Mitigation measure expected shortly) Des mesures de correction sont-elles envisagées rapidement ? (« oui » ou « non » ).
• (User action able to reduce impact) Les mesures que l’utilisateur peut prendre pour diminuer le risque (exemple : « ne pas sauvegarder ses statistiques hebdomadaires » ).
• (CVE ID) L’identifiant de CVE de la vulnérabilité s’il en existe une (exemple : « CVE-2026-000000 » ).
• (General information) Une description générale de la vulnérabilité et du risque encouru (exemple : « La vulnérabilité est un débordement de buffer dans une fonction de hashage, entraînant un risque de contournement de l’identification de l’utilisateur lors de la sauvegarde de ses statistiques » ).
• (Date and time when the AEV occured) La date et l’heure de l’exploitation effective de la vulnérabilité si on les connaît, une estimation sinon.
• Comme pour la première notification, d’autres champs optionnels peuvent être remplis.

Produire le correctif

Mercredi, 8 jours après la découverte initiale de la vulnérabilité, un correctif pour la bibliothèque incriminée vient d’être publié.

Dans un environnement Linux embarqué traditionnel, il faut maintenant produire une nouvelle version du système qui intègre cette correction. Cela signifie reconstruire l’image, vérifier que le changement ne provoque pas de régression, produire les images à jour et préparer leur déploiement. Ce travail ne doit évidemment pas être négligé : une mise à jour de sécurité non testée peut elle-même rendre les équipements inutilisables.

L’objectif d’Eris Linux est plutôt de rendre cette étape aussi simple et prévisible que possible. Vous allez produire le code métier dans un container que vous testerez sur un groupe dédié d’équipements avec lesquels vous pourrez valider l’efficacité et l’innocuité de la correction.

Même lorsqu’une vulnérabilité importante est activement exploitée, il serait dangereux d’envoyer immédiatement une nouvelle version de l’applicatif sur l’ensemble d’un parc sans aucune validation. Une stratégie raisonnable consiste à commencer par quelques équipements de test représentatifs de la production.

Une vulnérabilité de sécurité crée une situation urgente. Elle ne doit pas pour autant conduire à abandonner les précautions élémentaires utilisées lors de toute mise à jour d’un système industriel. On vérifie le démarrage des équipements de test, le fonctionnement des applications, les communications réseau et les éventuels périphériques spécifiques. Une fois cette validation effectuée, le correctif peut être affecté progressivement aux groupes d’équipements concernés.

Déployer et suivre

Au bout de 4 jours de tests intensifs, vous décidez de déployer la version corrigée vers l’ensemble des systèmes embarqués.

Toutefois, la publication d’un correctif n’est pas la fin du problème, il faut également savoir combien d’équipements l’ont réellement installé. Dans un parc réel, certains systèmes peuvent être éteints, temporairement hors ligne ou isolés du réseau. Il est donc nécessaire de distinguer « le correctif a été déployé » de « tous les équipements concernés utilisent maintenant une version corrigée ».

Avec un système de gestion centralisé comme le Device Manager d’Eris Linux, les contacts réguliers des équipements permettent de suivre leurs versions et leur état. On peut ainsi identifier les systèmes qui nécessitent encore une intervention.

Cette traçabilité devient particulièrement intéressante lorsqu’il faut, quelques jours plus tard, documenter précisément les mesures mises en œuvre pour répondre à la vulnérabilité.

Fermer la boucle réglementaire

Dès qu’une mesure corrective est disponible, un nouveau délai commence. Le rapport final prévu par le CRA doit être transmis au plus tard quatorze jours après cette date.

Outre les champs précédents, éventuellement complétés ou corrigés, on remplira les éléments suivants :

• (Corrective or mitigating measures taken) Les mesures correctives prises par le fabricant (exemple : « Remplacement de la version 1.2.1 de la libfoo par la version 1.2.4 dans tous nos produits concernés » ).
• (Corrective or mitigating measures that users can take) Les actions correctrices que l’utilisateur peut prendre (exemple : « Connecter son équipement à Internet et accepter l’installation de la nouvelle version de notre application » ).
• (Date when corrective or mitigating measure has been available) Date et heure à laquelle les mesures correctrices ont été prises ainsi que la description du correctif (exemple : « Application du patch permettant de passer à la version 1.2.4 de la libfoo » ).
• (Full description of the Severity & Impact of the vulnerability) Niveau de gravité et impact de la vulnérabilité (exemple : « Haute gravité, risque de compromission des comptes utilisateurs » ).

Le CRA impose par ailleurs, lorsqu’une mise à jour de sécurité est disponible, la communication des informations pertinentes aux utilisateurs, d’autant plus s’ils doivent prendre des actions pour assurer le fonctionnement sécurisé de leur équipement.

On voit donc que la gestion d’une vulnérabilité ne consiste pas simplement à modifier quelques lignes de code. Elle englobe l’identification, l’analyse, la communication, la production du correctif, les tests, le déploiement, le suivi des équipements et enfin la documentation de l’ensemble du processus.

Se préparer avant que cela arrive

Dans la situation décrite ici, les délais sont courts. Le moment où une vulnérabilité activement exploitée est annoncée n’est probablement pas le meilleur moment pour commencer à se demander :

• Qui est responsable de l’analyse ?
• Qui possède un compte sur la plateforme de signalement ?
• Qui peut décider d’un déploiement urgent ?
• Comment identifier les produits concernés ?
• Où se trouve leur nomenclature logicielle ?
• Comment prévenir les clients ?
• Comment distribuer une mise à jour ?
• Comment savoir ensuite quels équipements ont réellement été corrigés ?

Ces questions devraient idéalement avoir reçu une réponse avant l’incident.

Une procédure interne relativement simple, testée occasionnellement comme on testerait un plan de reprise après sinistre, peut probablement éviter beaucoup d’improvisation le jour où les délais de 24 et 72 heures commencent réellement à courir.

Eris Linux n’apporte évidemment pas de réponse automatique au Cyber Resilience Act.

Son objectif est plus pragmatique :

• vous fournir un socle Linux dont nous prenons en charge la maintenance, le suivi des vulnérabilités et les exigences CRA qui relèvent de ce socle,
• vous fournir les mécanismes permettant de maîtriser vos propres applications, de les mettre à jour et de documenter leur exploitation afin de faciliter la conformité CRA de votre produit final.

Si vous souhaitez plus de détails sur Eris Linux, n’hésitez pas à me contacter. Je pourrai vous proposer une présentation du produit avec mise en pratique sur une cible courante.