Cyber Resilience Act (CRA) : Guide de conformité étape par étape

Le CRA constitue un tournant majeur, dans la mesure où il officialise la responsabilité des fabricants, et dans certains cas des importateurs et des distributeurs, quant au niveau de sécurité numérique des produits qu’ils mettent sur le marché. Ces derniers n’ont désormais d’autre choix que de penser et de garantir la sécurité numérique de leurs produits tout au long de leur cycle de vie, depuis les prémices de la conception jusqu’à la fin de la période de support.

Les objectifs du CRA

L’objectif du CRA est évidemment de protéger les consommateurs, mais aussi de renforcer le niveau global de résilience de l’Union. Rendre les produits numériques plus sûrs, c’est aussi réduire les risques pour tous les utilisateurs de ces produits, qu’il s’agisse de particuliers ou d’entités de première importance telles que celles réglementées par NIS2 – hôpitaux, banques, usines de production d’eau potable, services postaux, etc.

À cette fin, le Cyber Resilience Act établit :

1. Des règles pour la mise à disposition sur le marché des produits comportant des éléments numériques afin de garantir leur cybersécurité ;
2. Des exigences essentielles pour la conception, le développement et la production de ces produits ;
3. Des exigences essentielles en ce qui concerne les processus de gestion des vulnérabilités mis en place par les fabricants ;
4. Des règles et des dispositions relatives à la surveillance du marché et à son application.

Le CRA est bien entendu obligatoire, et son respect est une condition préalable au marquage CE des produits réglementés, ainsi qu’à leur distribution sur le marché européen. Il convient également de souligner que le CRA n’est pas un règlement inoffensif, mais qu’il se donne les moyens de se faire respecter, notamment par des mesures coercitives telles que des amendes, qui sont pour le moins salées.

Une vision défensive de la cybersécurité, calquée sur le Cybersecurity Act

Avant d’aller plus loin, il nous semble important de faire un point sur la notion de “cybersécurité” au sens où elle est entendue par le CRA.

L’Article 3 du Cyber Resilience Act précise que le terme “cybersécurité” est entendu au même sens que celui donné à l’Article 2 du Règlement 2019/881, qui n’est autre que le Cybersecurity Act (CSA), à savoir :

“La ‘cybersécurité’ désigne les activités nécessaires pour protéger les réseaux et les systèmes d’information, les utilisateurs de ces systèmes et les autres personnes concernées par les cybermenaces.” – Cybersecurity Act, Article 2

Le CRA adopte donc une définition défensive de la cybersécurité : il est question de défendre les produits, de les protéger des éventuelles menaces. Gardez donc en tête que “cybersécurité” sera par la suite synonyme de posture défensive – même si les approches offensives comme les tests d’intrusion y trouveront leur place, notamment pour évaluer la sécurité des produits et l’efficacité des mesures défensives.

Et la résilience numérique dans tout ça ?

Certains pourraient s’étonner de ce choix sémantique, à l’heure où le terme “résilience numérique” fleurit dans les différentes législations européennes, de l’intitulé du Cyber Resilience Act (CRA) au Digital Operational Resilience Act (DORA) qui régit le secteur financier.

En effet, la résilience est une notion qui va bien au-delà de la simple protection des actifs. Elle ne se cantonne pas à la simple défense, mais vise la résistance, la continuité des activités même sous un feu nourri. Mais il est important de comprendre que, contrairement à NIS2 ou DORA, le CRA réglemente des produits et non des entités. Cette distinction est fondamentale.

On peut attendre d’une banque ou d’une centrale nucléaire qu’elle soit résiliente, c’est-à-dire capable d’assurer la continuité de ses activités et de ses services même en cas d’attaque – de là à parler de PRA et PCA , il n’y a qu’un pas – afin d’épargner à l’Union européenne des effets systémiques désastreux. Mais on ne peut raisonnablement pas attendre la même chose d’une montre connectée ou d’un babyphone.

En revanche, on peut attendre d’un produit IoT qu’il soit opérationnel de manière à remplir sa fonction, et qu’il ne soit pas compromis afin de ne pas mettre en danger ses utilisateurs. En effet, du point de vue de l’attaquant, la compromission d’un produit connecté n’est jamais une fin en soi, mais toujours un moyen d’atteindre sa cible : l’utilisateur, qu’il s’agisse d’un particulier ou d’une organisation sensible.

En améliorant la sécurité des produits embarquant du numérique, le CRA contribue de fait à renforcer la résilience numérique de tous les utilisateurs, et par là même de l’ensemble de l’écosystème européen. Avec le Cyber Resilience Act, la cybersécurité défensive est au service de la résilience numérique.

Quand le CRA entrera-t-il en application ?

Ici, il faut se référer à l’Article 71 du règlement pour trouver la réponse. Le Cyber Resilience Act entrera en application 3 ans (36 mois) après sa publication au Journal officiel de l’Union européenne.

L’adoption et la publication du CRA sont attendues dans le courant de l’année 2024, ce qui amène à une date butoir de mise en conformité en 2027 pour les produits réglementés. Il convient de rappeler que le CRA est un règlement européen et qu’à ce titre, il sera applicable en l’état dans tous les pays membres de l’UE (à l’inverse d’une directive, comme NIS2, qui doit être transposée dans le droit national de chaque pays).

Une obligation de signaler les incidents et les vulnérabilités exploitées dès 2026

Il existe deux exceptions à ce délai de trois ans, clairement énoncées à l’Article 71 et au considérant 127.

Tout d’abord, la date d’application est fixée à 21 mois pour les obligations de signalement des incidents graves et des vulnérabilités activement exploitées – deux notions sur lesquelles nous reviendrons – à l’ENISA (Agence de l’Union européenne pour la cybersécurité) et aux CSIRT (Computer Security Incident Response Team) nationaux. Le CRA étant prévu pour 2024, les notifications aux autorités seront obligatoires dès 2026.

La deuxième exception porte sur les dispositions relatives à la notification des organismes d’évaluation de la conformité, qui seront effectives 18 mois après la publication du CRA. Nous ne nous attarderons pas sur ce point, car il concerne davantage les auditeurs que les fabricants.

Les sanctions et amendes prévues par le Cyber Resilience Act

Le Cyber Resilience Act entend bien se faire respecter, et il s’accompagne donc de sanctions pour les mauvais élèves. Et comme souvent, le meilleur moyen de dissuasion est de frapper là où ça fait mal : au portefeuille. L’Article 64 du CRA prévoit un certain nombre d’amendes administratives, qui peuvent s’ajouter à toute autre mesure corrective ou restrictive décidée par les autorités de surveillance du marché. Ces dernières peuvent également ordonner le retrait d’un produit du marché si des raisons de sécurité l’exigent.

Jusqu’à 15 M€ ou 2,5% du chiffre d’affaires mondial

Le montant de l’amende dépend principalement de deux facteurs : la structure en tort et l’objet de la non-conformité. Une start-up ne sera pas pénalisée de la même manière qu’une multinationale, et une faute portant sur la sécurité des produits sera plus lourdement sanctionnée qu’un manquement administratif. C’est somme toute assez logique.

Tous les éléments de conformité ci-dessous peuvent sembler assez vagues si vous n’êtes pas (encore) familiarisé avec le règlement, mais rassurez-vous, nous les expliquerons tout au long de ce guide.

En cas de non-respect des exigences essentielles du règlement, des obligations de notification des incidents et des vulnérabilités ou des autres obligations qui leur incombent, les fabricants sont passibles d’une amende pouvant aller jusqu’à 15 millions d’euros ou 2,5% du chiffre d’affaires annuel mondial total de l’exercice précédent, le montant le plus élevé étant retenu.

Pour leur part, les mandataires, les importateurs, les distributeurs, les organismes d’évaluation et leurs sous-traitants qui contreviennent à leurs obligations encourent des amendes pouvant aller jusqu’à 10 millions d’euros ou 2% du chiffre d’affaires annuel mondial total, là encore le montant le plus élevé étant retenu.

Ce deuxième barème s’applique également à tous les acteurs lorsque la non-conformité concerne des obligations relatives à la déclaration UE de conformité, à la documentation technique, aux règles d’apposition du marquage CE, à l’évaluation de la conformité ou à l’accès aux données et à la documentation.

Enfin, la fourniture d’informations inexactes, incomplètes ou trompeuses aux organismes notifiés ou aux autorités de surveillance du marché peut faire l’objet d’une amende pouvant aller jusqu’à 5 millions d’euros ou 1% du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu.

Les exceptions : logiciels open-source, micro-entreprises et PME

L’Article 64.10 du Cyber Resilience Act prend soin de noter deux exceptions à ces régimes de sanction.

Premièrement, les fabricants considérés comme des micro ou petites entreprises ne peuvent pas être sanctionnées financièrement en cas de manquement aux délais de signalement des incidents graves et des vulnérabilités activement exploitées (voir Chapitre 10).

Deuxièmement, les administrateurs de logiciels open-source ne peuvent pas faire l’objet de sanctions financières, quelle que soit la violation du Cyber Resilience Act.

Tout ceci étant dit, nous pouvons désormais passer au cœur de ce guide, à savoir les différentes démarches à entreprendre pour se mettre en conformité.

1. Vérifiez si vos produits sont réglementés par le Cyber Resilience Act

En tant que fabricant, la première chose à faire est de savoir quels sont les produits réglementés par le Cyber Resilience Act. À cet égard, l’Article 2 est on ne peut plus clair :

“Le présent règlement s’applique aux produits comportant des éléments numériques mis à disposition sur le marché, dont l’usage prévu ou raisonnablement prévisible inclut une connexion logique ou physique, directe ou indirecte, à un dispositif ou à un réseau.” – CRA, Article 2.1

Oui, le CRA concerne donc énormément de produits ; c’est précisément pour cette raison qu’il est un texte législatif incontournable en matière de cybersécurité. Et pour peu que vous ayiez encore un peu d’espoir de lui échapper, l’Article 3 précise la définition de “produits comportant des éléments numériques” – que l’on abrègera le plus souvent par “produits” dans la suite de ce guide.

“‘Produit comportant des éléments numériques’ : tout produit logiciel ou matériel et ses solutions de traitement des données à distance, y compris les composants logiciels ou matériels devant être mis sur le marché séparément.” – CRA, Article 3

Cette définition est importante, car elle confirme que toutes les solutions logicielles qui vont de pair avec un produit réglementé entrent également dans le champ d’application du CRA. Les plateformes SaaS et autres applications mobiles qui accompagnent les produits IoT sont donc assujetties aux mêmes obligations, comme celles qui sont associées aux montres et balances connectées par exemple. À l’inverse, une plateforme SaaS qui n’est adossée à aucun produit n’est pas concernée par le CRA (mais elle peut l’être par la Directive NIS2).

La liste des exceptions

L’Article 2 fait état de rares exceptions, mais qu’il vaut mieux avoir en tête. Sont donc exclus du périmètre du CRA :

• Les dispositifs médicaux professionnels soumis aux règlements (EU) 2017/745 et (EU) 2017/746 ;
• Les véhicules à moteurs et leurs remorques ainsi que leurs systèmes, composants et entités techniques distinctes qui sont dans le scope du règlement (EU) 2019/2144 ;
• Les systèmes d’aviation civile et les équipements marins, respectivement régis par les règlements (EU) 2018/1139 et 2014/90/EU ;
• Les éléments numériques développés ou modifiés exclusivement à des fins de sécurité ou de défense nationale.

Les quatre catégories de produits réglementées par le CRA

Le Cyber Resilience Act distingue quatre catégories parmi les produits embarquant du numérique qu’il réglemente :

• La catégorie par défaut, qui n’est pas mentionnée en tant que telle, mais qui existe de facto. Elle comprend tous les produits qui répondent aux définitions générales données précédemment ;
• Les produits importants de Classe I ;
• Les produits importants de Classe II;
• Les produits critiques.

Il est essentiel de bien comprendre cette classification, car elle détermine, entre autres, la procédure d’évaluation de la conformité attendue pour chaque produit. Ainsi, plus le produit est critique, plus l’évaluation sera rigoureuse – comprenez ici l’intervention d’un auditeur tiers.

Les produits importants

Les produits importants sont ordonnés en deux classes : la Classe I et la Classe II, toutes deux détaillées dans l’Annexe III du règlement, que nous examinerons ci-dessous.

Selon l’Article 7 du CRA, un produit est considéré comme important s’il répond à au moins l’un des deux critères suivants :

• Le produit remplit principalement des fonctions essentielles à la cybersécurité d’autres produits, réseaux ou services, y compris la sécurisation des authentifications et des accès, la prévention et la détection des intrusions, la sécurité des endpoints ou la protection des réseaux ;
• Le produit remplit une fonction qui comporte un risque significatif d’effets néfastes par son intensité et sa capacité à perturber, contrôler ou endommager un grand nombre d’autres produits ou la santé, la sécurité ou la sûreté de ses utilisateurs par une manipulation directe, telle qu’une fonction de système central, y compris la gestion du réseau, la gestion de configuration, la virtualisation ou le traitement de données à caractère personnel.

Ce n’est évidemment pas aux fabricants de décider si leurs produits sont importants ou non, le CRA ayant pris soin de dresser une liste exhaustive, bien que généraliste. Par ailleurs, l’Article 7 exige que la Commission européenne précise les descriptions techniques des catégories de produits importants et critiques dans un délai de 12 mois à compter de la publication du règlement.

Notons également que la Commission européenne peut modifier l’Annexe III comme bon lui semble, et ainsi ajouter, supprimer ou déplacer une catégorie de produits d’une classe à l’autre. Le cas échéant, la règle générale est d’observer une période de transition de 12 mois avant que les nouvelles règles ne s’appliquent.

Enfin, le CRA souligne qu’un produit qui intègre un produit important n’est pas systématiquement important en soi, et n’est donc pas nécessairement soumis aux mêmes obligations d’évaluation de la conformité.

La liste des produits importants de Classe I

Les produits importants de la Classe I sont détaillés dans l’Annexe III du CRA. La liste exacte est reproduite ci-dessous, bien que traduite par nos soins.

Les produits importants de Classe I sont :

1. Les systèmes de gestion de l’identité et les logiciels et matériels de gestion des accès privilégiés, y compris les dispositifs d’authentification et de contrôle d’accès, dont les lecteurs biométriques ;
2. Les navigateurs autonomes et intégrés ;
3. Les gestionnaires de mots de passe ;
4. Les logiciels qui recherchent, suppriment ou mettent en quarantaine les logiciels malveillants ;
5. Les produits contenant des éléments numériques avec la fonction de réseau privé virtuel (VPN) ;
6. Les systèmes de gestion de réseau ;
7. Les systèmes de gestion des informations et des événements de sécurité (SIEM) ;
8. Les gestionnaires de démarrage (boot managers) ;
9. Les infrastructures à clés publiques et les logiciels d’émission de certificats numériques ;
10. Les interfaces de réseau physiques et virtuelles ;
11. Les systèmes d’exploitation ;
12. Les routeurs et les modems destinés à la connexion à l’internet, ainsi que les commutateurs ;
13. Les microprocesseurs dotés de fonctionnalités liées à la sécurité ;
14. Les microcontrôleurs dotés de fonctionnalités liées à la sécurité ;
15. Les circuits intégrés spécialisés (ASIC) et les réseaux de portes programmables (FPGA) dotés de fonctionnalités liées à la sécurité ;
16. Les assistants virtuels polyvalents pour maison intelligente (smart home) ;
17. Les produits pour maison intelligente avec des fonctionnalités de sécurité, y compris les serrures de porte intelligentes, les caméras de sécurité, les systèmes de surveillance des bébés et les systèmes d’alarme ;
18. Les jouets connectés à l’internet couverts par la Directive 2009/48/CE qui ont des fonctions sociales interactives (par exemple, parler ou filmer) ou qui ont des fonctions de géolocalisation ;
19. Les produits personnels à porter ou à placer sur un corps humain qui ont une finalité de surveillance de la santé (comme le suivi) ou les produits personnels à porter qui sont destinés à être utilisés par et pour les enfants. (NDLR : sont exclus les dispositifs médicaux professionnels régis par les règlements (UE) 2017/745 et (UE) 2017/746).

La liste des produits importants de Classe II

Les produits importants de Classe II sont :

1. Les hyperviseurs et les systèmes d’exécution de conteneurs qui prennent en charge l’exécution virtualisée de systèmes d’exploitation et d’environnements similaires ;
2. Les pare-feu, les systèmes de détection et/ou de prévention des intrusions ;
3. Les microprocesseurs dits “tamper-resistant” (anti-sabotage) ;
4. Les microcontrôleurs dits “tamper-resistant” (anti-sabotage).

Les produits critiques

La classification critique des produits est la plus élevée de toutes celles établies par le CRA. Sans surprise, les produits appartenant aux catégories désignées sont ceux soumis aux obligations les plus strictes en matière d’évaluation de la conformité.

Pour savoir ce qui fait qu’un produit est critique, il faut se référer à l’Article 8 du CRA. Celui-ci dispose qu’une catégorie de produits peut être considérée comme critique si, en plus des critères relatifs aux produits importants, elle apparaît comme telle au regard des deux évaluations suivantes :

• La mesure dans laquelle il existe une dépendance critique des entités essentielles visées à l’Article 3 de la Directive (UE) 2022/2555 – alias NIS2 – vis-à-vis de cette catégorie de produits ;
• La mesure dans laquelle les incidents et les vulnérabilités exploitées concernant cette catégorie des produits peuvent entraîner de graves perturbations des chaînes d’approvisionnement critiques dans l’ensemble du marché intérieur.

Derrière ces formulations quelque peu sibyllines se cachent en réalité deux obsessions de la Directive NIS2 :

• Protéger les entités essentielles, celles dont la défaillance pourrait avoir des effets systémiques au sein de l’UE, à l’image des acteurs du transport, de l’énergie ou de la santé. Si vous souhaitez en savoir plus sur les Entités Essentielles (EE), vous pouvez vous référer à la section correspondante de notre guide de conformité NIS2 ;
• Sécuriser la chaîne d’approvisionnement, ces fameux prestataires de services qui, lorsqu’ils sont numériquement fragiles, représentent un vecteur d’attaque privilégié contre les entités qui travaillent avec eux. Si vous n’êtes pas familier avec le sujet, nous vous conseillons de vous pencher sur la cyberattaque contre SolarWinds, qui est aujourd’hui un cas d’école en matière de “supply chain attack”.

Dès lors, il est compréhensible que les produits jugés critiques par le CRA soient ceux qui présentent un risque pour les entités vitales au bon fonctionnement de l’Union, ou qui sont susceptibles de mettre en péril les chaînes d’approvisionnement les plus importantes.

La liste des produits critiques

Il convient de noter ici que la liste ci-dessous n’est pas gravée dans le marbre, puisque, comme pour les produits importants, la Commission européenne est libre de la modifier à sa guise par le biais d’actes délégués. Dans ce cas, la règle générale est d’observer une période de transition de 6 mois avant l’application des nouvelles règles.

Les produits critiques sont listés dans l’Annexe IV du CRA, à savoir :

• Les cartes à puce ou dispositifs similaires, y compris les éléments sécurisés ;
• Les dispositifs matériels avec boîtiers de sécurité (NDLR : les produits de type lecteurs sécurisés de cartes à puce, tachygraphes, Hardware Security Modules (HSM), etc.) ;
• Les passerelles de compteurs intelligents au sein des systèmes de comptage intelligents tels que définis à l’Article 2.23, de la Directive (UE) 2019/944, et autres dispositifs à des fins de sécurité avancée, y compris pour le traitement cryptographique sécurisé.

Le dernier point étant pour le moins opaque, nous nous permettons d’ouvrir une parenthèse. La Directive (EU) 2019/944 dont il est question est une législation européenne du 5 juin 2019 concernant des règles communes pour le marché intérieur de l’électricité. Elle définit un “système intelligent de mesure” comme suit :

“‘Un système électronique qui est capable de mesurer l’électricité injectée dans le réseau ou l’électricité consommée depuis le réseau en fournissant davantage d’informations qu’un compteur classique, et qui est capable de transmettre et de recevoir des données à des fins d’information, de surveillance et de contrôle en utilisant une forme de communication électronique.” – Directive (EU) 2019/944 , Article 2.23

2. Prenez connaissance des 21 exigences essentielles en matière de cybersécurité

On attaque ici un gros morceau du règlement ; si vous voulez vous servir un café, c’est le moment.

Le Cyber Resilience Act fixe des exigences essentielles – un doux euphémisme pour parler d’obligations – pour tous les produits réglementés et leurs fabricants. Elles sont détaillées dans l’Annexe I du règlement, qui sera régulièrement citée par la suite.

Les exigences essentielles du CRA se décomposent en deux parties :

1. Les exigences en matière de cybersécurité des produits. Il s’agit ici du niveau de sécurité et des caractéristiques intrinsèques des produits ;
2. Les exigences en matière de gestion des vulnérabilités. Il s’agit ici des mesures et des processus mis en œuvre par les fabricants.

Nous attirons votre attention sur le fait que ces exigences sont absolument cruciales. Elles sont au cœur du Cyber Resilience Act, et c’est leur mise en œuvre qui déterminera si un produit sera considéré comme conforme ou non. L’Article 6 du CRA dispose d’ailleurs que seuls les produits qui respectent TOUTES ces obligations peuvent être mis sur le marché européen.

Par conséquent, la mise en œuvre de ces exigences devrait être votre feuille de route pour la conformité au Cyber Resilience Act, votre lumière dans la nuit lorsque vous vous sentirez perdu face à l’ampleur de la tâche.

Ces exigences sont également la pierre angulaire du document que vous tenez entre les mains. Dans ce chapitre, nous les énumérerons telles qu’elles sont énoncées dans le règlement, puis nous reviendrons plus en détail sur chacune d’entre elles au fur et à mesure de la progression du guide. Il faut garder à l’esprit que le CRA est un texte de loi et non un manuel de spécifications techniques, si bien que certaines exigences peuvent sembler pour le moins opaques ou généralistes à la première lecture.

Les 13 exigences du CRA en matière de cybersécurité des produits

La première partie des exigences essentielles du CRA est consacrée aux propriétés des produits, lesquelles doivent garantir un niveau de sécurité intrinsèque solide. Le texte est on ne peut plus clair :

“Les produits comportant des éléments numériques doivent être conçus, développés et produits de manière à garantir un niveau approprié de cybersécurité en fonction des risques.” – CRA, Annexe I

Chose importante, les produits IoT doivent donc être sécurisés au regard des risques qui leur sont associés. Ces derniers sont à déterminer au moyen d’une évaluation des risques cyber (voir Chapitre 5), à la charge du fabricant et à réaliser en amont de la conception.

Les produits doivent satisfaire à une liste de 13 exigences essentielles en matière de cybersécurité (Source : Annexe I, Partie 1) :

1. Être mis à disposition sur le marché sans vulnérabilité exploitable connue ;
2. Être mis à disposition sur le marché avec une configuration sécurisée par défaut, sauf accord contraire entre le fabricant et l’utilisateur professionnel pour un produit sur mesure, avec la possibilité de réinitialiser le produit à son état d’origine ;
3. Garantir que les vulnérabilités peuvent être corrigées par des mises à jour de sécurité, y compris, le cas échéant, par des mises à jour de sécurité automatiques installées dans un délai approprié, activées par défaut, avec un système d’opt-out clair et facile à utiliser, en notifiant aux utilisateurs les mises à jour disponibles et en leur offrant la possibilité de les reporter temporairement ;
4. Assurer la protection contre les accès non autorisés au moyen de mécanismes de contrôle appropriés, y compris mais sans s’y limiter, des systèmes d’authentification, de gestion de l’identité ou de l’accès, ainsi que signaler les éventuels accès non autorisés ;
5. Protéger la confidentialité des données stockées, transmises ou traitées d’une autre manière, qu’elles soient personnelles ou autres, notamment en chiffrant les données pertinentes au repos ou en transit au moyen de mécanismes conformes à l’état de l’art, et en utilisant d’autres moyens techniques ;
6. Protéger l’intégrité des données stockées, transmises ou traitées d’une autre manière, qu’elles soient personnelles ou autres, des commandes, des programmes et de la configuration contre toute manipulation ou modification non autorisée par l’utilisateur, ainsi que signaler les corruptions ;
7. Ne traiter que des données, personnelles ou autres, qui sont adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité du produit (“minimisation des données”) ;
8. Protéger la disponibilité des fonctions essentielles et basiques, y compris après un incident, notamment par des mesures de résilience et d’atténuation des attaques par déni de service (DDoS) ;
9. Minimiser l’impact négatif des produits eux-mêmes ou des dispositifs connectés sur la disponibilité des services fournis par d’autres dispositifs ou réseaux ;
10. Être conçus, développés et produits de manière à limiter les surfaces d’attaque, y compris les interfaces externes ;
11. Être conçus, développés et produits de manière à réduire l’impact d’un incident à l’aide de mécanismes et de techniques d’atténuation de l’exploitation appropriés ;
12. Fournir des informations relatives à la sécurité en enregistrant et/ou en surveillant l’activité interne pertinente, notamment l’accès aux données, services ou fonctions ou leur modification, avec un système d’opt-out pour l’utilisateur ;
13. Donner la possibilité aux utilisateurs de supprimer de manière sûre, simple et permanente toutes les données et tous les paramètres et, lorsque ces données peuvent être transférées à d’autres produits ou systèmes, veiller à ce que cela se fasse de manière sécurisée.

Les 8 exigences du CRA en matière de gestion des vulnérabilités

La deuxième partie des exigences essentielles du CRA concerne les obligations des fabricants en matière de gestion des vulnérabilités. Celles-ci sont tout aussi importantes que les exigences applicables aux produits, et leur mise en œuvre conditionne aussi la mise sur le marché.

Les fabricants d’un produit réglementé par le CRA doivent satisfaire aux 8 exigences de gestion des vulnérabilités suivantes (Source : Annexe I, Partie 2) :

1. Identifier et documenter les vulnérabilités et les composants contenus dans le produit, notamment en établissant une nomenclature logicielle – SBOM (Software Bill Of Materials) – dans un format couramment utilisé et lisible par une machine, couvrant au minimum les dépendances de premier niveau du produit ;
2. En ce qui concerne les risques posés par les produits comportant des éléments numériques, remédier sans délai aux vulnérabilités, notamment en fournissant des mises à jour de sécurité. Lorsque cela est techniquement possible, les nouvelles mises à jour de sécurité sont fournies séparément des mises à jour de fonctionnalité ;
3. Appliquer des tests et des examens efficaces et réguliers de la sécurité du produit ;
4. Une fois qu’une mise à jour de sécurité a été mise à disposition, partager et divulguer publiquement des informations sur les vulnérabilités corrigées, y compris une description des vulnérabilités, des informations permettant aux utilisateurs d’identifier le produit affecté, les impacts des vulnérabilités, leur gravité et des informations claires et accessibles aidant les utilisateurs à remédier aux vulnérabilités. Dans des cas dûment justifiés, lorsque les fabricants considèrent que les risques de sécurité de la divulgation l’emportent sur les avantages en matière de sécurité, ils peuvent retarder la diffusion des informations concernant une vulnérabilité corrigée jusqu’à ce que les utilisateurs aient eu la possibilité d’appliquer le correctif correspondant ;
5. Mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités (CVD pour Coordinated Vulnerability Disclosure) ;
6. Prendre des mesures pour faciliter le partage d’informations sur les vulnérabilités potentielles de leur produit et des éléments tiers contenus dans ce produit, en fournissant notamment une adresse de contact pour le signalement des vulnérabilités découvertes ;
7. Prévoir des mécanismes de distribution sécurisée des mises à jour des produits afin de garantir que les vulnérabilités sont corrigées ou atténuées en temps utile et, quand applicable, d’une manière automatique ;
8. Veiller à ce que les mises à jour de sécurité disponibles soient diffusées sans délai (sauf accord contraire entre le fabricant et l’utilisateur professionnel dans le cas d’un produit sur mesure), gratuitement et accompagnées de messages informatifs fournissant aux utilisateurs les informations pertinentes, y compris sur les éventuelles mesures à prendre.

3. Examinez les cas particuliers : importateurs, distributeurs et logiciels libres

Les 21 exigences susmentionnées s’appliquent aux fabricants de produits réglementés par le Cyber Resilience Act. Mais le règlement prend également soin de combler les angles morts, en précisant les obligations applicables aux importateurs, aux distributeurs et aux administrateurs de logiciels libres. Si ces cas particuliers ne vous concernent pas, vous pouvez passer directement au chapitre suivant.

Les obligations des importateurs

Le règlement consacre l’intégralité de son Article 19 aux obligations des importateurs. Il est évident qu’ils ont l’interdiction absolue de mettre sur le marché des produits qui ne sont pas conformes aux 13 exigences essentielles de cybersécurité, ou dont les fabricants n’appliquent pas les 8 exigences essentielles en matière de gestion des vulnérabilités. L’application de toutes ces exigences reste de la responsabilité des fabricants.

Avant de mettre sur le marché, l’importateur doit veiller à ce que :

1. Les procédures d’évaluation de la conformité ont été menées à bien par le fabricant ;
2. Le fabricant a établi la documentation technique ;
3. Le produit porte le marquage CE, en plus d’être accompagné de la déclaration UE de conformité, ainsi que des informations et instructions à destination des utilisateurs ;
4. Le produit porte un numéro de type, de lot ou de série ou tout autre élément permettant son identification. Lorsque cela n’est pas possible, cette information doit être fournie sur l’emballage ou dans un document accompagnant le produit ;
5. Le fabricant ET l’importateur ont tous deux indiqué leur nom, leur raison sociale ou leur marque déposée, ainsi que l’adresse postale, électronique ou de site web à laquelle ils peuvent être respectivement contactés. Ces informations doivent figurer sur le produit, sur son emballage ou dans un document l’accompagnant ;
6. Le fabricant a veillé à ce que la date de fin de la période de support, notamment le mois et l’année, soit précisée au moment de l’achat, d’une manière claire, compréhensible et aisément accessible et, selon le cas, sur le produit, son emballage ou par des moyens numériques.

Les importateurs doivent être en mesure de fournir tous les documents nécessaires prouvant le respect des exigences énoncées ci-dessus. Par ailleurs, si un importateur prend connaissance d’une vulnérabilité dans un produit, il est bien évidemment tenu d’en informer les autorités compétentes.

Les obligations des distributeurs

Pour les obligations qui incombent aux distributeurs, c’est vers l’Article 20 du CRA qu’il faut se tourner. Comme pour les importateurs, il s’agit surtout de vérifier que la paperasserie est en ordre. Les distributeurs doivent donc “agir avec la diligence requise”, vérifier que le produit porte bien le marquage CE et que le fabricant et l’importateur ont bien respecté tous les points de la liste ci-dessus.

Les produits en marque blanche

Exception notable : un importateur ou un distributeur est considéré comme un fabricant quand il met sur le marché un produit “sous son propre nom ou sa propre marque”, ou lorsqu’il apporte une “modification substantielle” à un produit déjà sur le marché. (Article 21) Toutes les obligations incombant aux fabricants s’appliquent alors.

Il en va de même pour toute personne physique ou morale autre que le fabricant, l’importateur ou le distributeur qui apporte une modification substantielle à un produit et le met à disposition sur le marché européen. (Article 22)

Les logiciels open source

Le logiciel libre a été un sujet majeur tout au long du processus d’élaboration du Cyber Resilience Act, suscitant de nombreuses levées de boucliers de la part des acteurs de l’open source.

Les premières versions du règlement menaçaient directement le modèle en engageant la responsabilité des créateurs, au point que la communauté craignait un “effet dissuasif” sur le développement des logiciels – libres ou non, les seconds dépendant souvent des premiers. En effet, il ne faut pas penser qu’il y a d’un côté les logiciels libres et de l’autre les logiciels sous licence. En réalité, les deux coexistent pour former l’écosystème logiciel que nous connaissons aujourd’hui, dans une sorte de symbiose profitable à tout le monde.

L’inquiétude était telle qu’en avril 2023, la Fondation Eclipse – qui compte parmi ses membres de grands noms tels que Google, IBM, Oracle et Microsoft – publiait une lettre ouverte à la Commission européenne, cosignée par de nombreux acteurs comme la Fondation Linux Europe ou le CNLL français.

Heureusement, la Commission européenne a pris soin de se concerter avec les représentants de l’open source, et la dernière version semble satisfaire tout le monde.

Quels sont les logiciels open source concernés par le CRA ?

Avant toute chose, définissons ce qu’est un logiciel open source au regard du CRA :

“‘Logiciel libre et ouvert’: un logiciel dont le code source est partagé de manière ouverte et qui est mis à disposition sous licence libre et ouverte prévoyant qu’il soit librement accessible, utilisable, modifiable et redistribuable pour tous ses droits.” – CRA, Article 3.48

Examinons ensuite le considérant 18, qui précise que “seuls les logiciels libres et ouverts mis à disposition sur le marché, donc fournis pour être distribués ou utilisés dans le cadre d’une activité commerciale, devraient relever du champ d’application du présent règlement.” Il est donc clair que les logiciels libres qui ne font pas partie d’une activité commerciale ne sont pas concernés par le CRA.

Reste à savoir ce qui caractérise une activité commerciale au sens de la réglementation… Sur ce point, le considérant 15 apporte un éclairage bienvenu.

La fourniture dans le cadre d’une activité commerciale peut être caractérisée par :

• Le prix facturé pour un produit ;
• Le prix des services d’assistance technique lorsqu’il ne sert pas uniquement à récupérer les coûts réels ;
• Une intention de monétisation, par exemple par la fourniture d’une plateforme logicielle par l’intermédiaire de laquelle le fabricant monétise d’autres services ;
• L’exigence, comme condition à l’utilisation, du traitement des données à caractère personnel pour des raisons autres qu’aux seules fins d’améliorer la sécurité, la compatibilité ou l’interopérabilité du logiciel ;
• L’acceptation de dons supérieurs aux coûts associés à la conception, au développement et à la fourniture du produit.

Si le logiciel répond à l’un de ces critères, il est visé par le Cyber Resilience Act. A l’inverse, précisons que les éléments suivants ne peuvent pas suffire à caractériser une activité commerciale :

• “Le fait d’accepter des dons sans intention lucrative” (Considérant 15) ;
• “La fourniture dans le cadre d’une prestation de service pour laquelle une rétribution est perçue à la seule fin de récupérer les coûts réels directement liés au fonctionnement de ce service, comme ce peut être le cas de certains produits fournis par des entités de l’administration publique.” (Considérant 16) ;
• “La fourniture de produits qui répondent aux critères de logiciels libres et ouverts qui ne sont pas monétisés par leur fabricant.” (Considérant 18)
• “Le simple fait qu’un fabricant verse un soutien financier à un logiciel libre ou qu’il contribue au développement d’un tel produit” (Considérant 18) ;
• L’existence de mises à jour régulières. (Considérant 18)
• Le développement par des organisations à but non lucratif, “pour autant que l’organisation concernée ait été créée de telle façon que tous les bénéfices sont utilisés pour atteindre des objectifs non lucratifs.” (Considérant 18)

Enfin, le CRA précise que les éléments suivants ne sont pas considérés comme une mise à disposition sur le marché :

• La fourniture d’un produit open source destiné à être intégré par d’autres fabricants à leurs propres produits SAUF SI “le composant est monétisé par son fabricant d’origine.” (Considérant 18) Il est donc possible de distribuer un logiciel libre sans avoir à s’inquiéter s’il venait à être monétisé par quelqu’un d’autre.
• “Le seul fait d’héberger des produits sur des répertoires ouverts, y compris par l’intermédiaire de gestionnaires de packages ou de plateformes collaboratives” (Considérant 20) Il est donc possible d’agréger et mettre à disposition d’autres projets libres sans être considéré comme un distributeur – à moins qu’il n’y ait une intention commerciale, évidemment.

Le statut d’administrateur de logiciels libres

Maintenant, qu’en est-il des organisations qui développent et maintiennent des logiciels libres à des fins commerciales ? Le CRA a pris soin de leur créer un statut à part, celui d’administrateur de logiciels libres, dont voici la définition :

“‘Administrateur de logiciels libres’ : une personne morale, autre que le fabricant, qui a pour objectif ou finalité de fournir un soutien systématique et continu au développement de produits spécifiques comportant des éléments numériques qui répondent aux critères de logiciels libres et ouverts et sont destinés à des activités commerciales, et qui assure la viabilité de ces produits.” – CRA, Article 3.14

Il ne fait aucun doute que ce sont les grandes fondations et structures de la communauté open source, telles que les fondations Linux, Mozilla et Eclipse, et leurs administrateurs qui sont visés. Les petites mains qui apportent leur brique au monde de l’open source sont épargnées :

“Le présent règlement ne s’applique pas aux personnes physiques ou morales qui contribuent, sous forme de code source, à des produits comportant des éléments numériques qui répondent aux critères de logiciels libres et ouverts ne relevant pas de leur responsabilité.” – CRA, Considérant 18

Quant aux administrateurs, rappelons qu’ils ne peuvent être condamnés à des amendes pour quelque infraction que ce soit au Cyber Resilience Act.

Les obligations des administrateurs de logiciels open source

Après cette longue mais nécessaire digression sur le cas particulier de l’open source, il est temps de se pencher sur les obligations spécifiques qui incombent aux administrateurs, détaillées dans l’Article 24.

Les administrateurs de logiciels open source doivent mettre en place et documenter de manière vérifiable une politique de cybersécurité. Cette dernière doit favoriser les développements sécurisés, ainsi que la gestion efficace des vulnérabilités par les développeurs. Cette politique doit “comprendre, en particulier, des aspects liés à la documentation, au traitement et à la correction des vulnérabilités, ainsi qu’à la promotion du partage d’informations sur les vulnérabilités découvertes au sein de la communauté des logiciels libres.”

Cette politique de cybersécurité doit être tenue à la disposition de toute autorité de surveillance du marché qui en fait la demande, en vue de parer à un éventuel risque de sécurité. La coopération de l’administrateur tout au long de la manœuvre sera bien entendu requise.

Par ailleurs, l’Article 24.3 dispose que les administrateurs sont soumis aux mêmes exigences de signalement qui s’appliquent aux fabricants, à savoir :

• Pour les vulnérabilités activement exploitées, dès lors qu’ils participent au développement des produits concernés ;
• Pour les incidents graves dès lors qu’ils touchent les réseaux et les systèmes d’information fournis pour le développement des produits affectés.

Nous ne détaillerons pas plus ici, puisque toutes ces exigences relatives à la notification des vulnérabilités exploitées et des incidents graves font l’objet du Chapitre 10 de ce guide.

Enfin, l’Article 25 du Cyber Resilience Act ouvre la voie à “des programmes volontaires d’attestation de sécurité” qui permettront d’évaluer la sécurité des logiciels open source. Il y a tout lieu de croire que ces programmes seront réalisés conjointement par le régulateur et les principales fondations open source.

Une partie de la communauté a déjà fait savoir qu’elle travaillait à l’élaboration de processus communs de cybersécurité pour la mise en conformité avec le CRA. Parmi les signataires se trouvent les fondations Apache, Blender, OpenSSL, PHP, Python, Rust et Eclipse – que du beau monde.

4. Préparez une documentation technique pour chaque produit mis sur le marché

Revenons à nos moutons : les obligations qui incombent aux fabricants de produits réglementés par le CRA. La production d’une documentation technique pour accompagner chaque produit est une condition sine qua non pour sa commercialisation en Europe. On ne fait que paraphraser le texte officiel :

“Avant de mettre sur le marché un produit comportant des éléments numériques, les fabricants établissent la documentation technique visée à l’Article 31.” – CRA, Article 13.12

L’Article 31 en question dispose que la documentation doit contenir toutes les informations qui démontrent le produit et les processus mis en place par le fabricant sont conformes aux exigences essentielles du CRA. Oui, toutes. Plus précisément, elle doit inclure au minimum tous les éléments listés dans l’Annexe VII (cf. ci-dessous).

Une excellente feuille de route pour la mise en conformité

La préparation de la documentation technique est l’une des dernières étapes du processus de mise en conformité, précisément parce qu’elle doit contenir les informations nécessaires pour prouver que les étapes précédentes ont été réalisées dans les règles de l’art. Néanmoins, nous avons pensé qu’il serait judicieux de la présenter assez tôt dans ce guide.

En effet, puisqu’elle énumère à peu près tout ce qui doit être fait, la documentation technique constitue une excellente feuille de route pour la mise en conformité avec le CRA. Aussi, nous ne pouvons que vous conseiller de l’accrocher au-dessus de votre bureau aux côtés des 21 exigences essentielles en matière de sécurité des produits et de gestion des vulnérabilités.

Les éléments à inclure dans la documentation technique

Si vous êtes friand de documentations à rallonge, vous allez être comblé. La documentation technique doit comprendre au minimum tous les éléments énumérés dans l’Annexe VII du CRA, à savoir :

1. Une description générale du produit comportant des éléments numériques, notamment :
   • son utilisation prévue ;
   • les versions de logiciel ayant des incidences sur la conformité aux exigences essentielles ;
   • lorsque le produit est un produit matériel, des photographies ou des illustrations montrant les caractéristiques extérieures, le marquage et la disposition intérieure ;
   • les informations et instructions destinées à l’utilisateur (cf. Annexe II du CRA) ;
2. Une description de la conception, du développement et de la fabrication du produit et des processus de gestion des vulnérabilités, et notamment :
   • les informations nécessaires sur la conception et le développement du produit, y compris, le cas échéant, des dessins et des schémas et/ou une description de l’architecture du système expliquant comment les composants logiciels s’appuient les uns sur les autres ou s’alimentent et s’intègrent dans le traitement global ;
   • les informations et spécifications nécessaires concernant le processus de gestion des vulnérabilités mis en place par le fabricant, y compris la nomenclature des logiciels, la politique coordonnée de divulgation des vulnérabilités, la preuve de la fourniture d’une adresse de contact pour le signalement des vulnérabilités et une description des solutions techniques choisies pour la distribution sécurisée des mises à jour ;
   • les informations et spécifications nécessaires concernant les processus de production et de suivi du produit, et la validation de ces processus;
3. Une évaluation des risques de cybersécurité sur la base de laquelle le produit est conçu, développé, produit, livré et entretenu, y compris la manière dont les exigences essentielles en matière de cybersécurité des produits sont applicables ;
4. Les informations qui ont été prises en compte pour déterminer la période de support (voir Chapitre 13) ;
5. Une liste des normes européennes harmonisées, des spécifications communes ou des schémas européens de certification de cybersécurité qui ont été appliqués ;
   • Lorsqu’ils n’ont pas été appliqués : une présentation des solutions adoptées pour répondre aux exigences essentielles du CRA, y compris une liste des autres spécifications techniques pertinentes appliquées.
   • Dans le cas d’une application partielle, la documentation technique précise les parties appliquées ;
6. Les rapports des tests réalisés pour vérifier la conformité du produit et des processus de gestion des vulnérabilités aux exigences essentielles du CRA ;
7. Une copie de la déclaration UE de conformité ;
8. Le cas échéant, la nomenclature logicielle (Software Bill Of Materials) à la suite d’une demande motivée d’une autorité de surveillance du marché.

Cette documentation technique doit être tenue à la disposition des autorités de surveillance du marché pendant au moins 10 ans, ou pendant le reste de la durée de support, la durée la plus longue étant retenue.

Une documentation technique simplifiée pour les micro-entreprises et les PME

Il est à noter que les micro-entreprises et les PME, y compris les startups, peuvent produire une documentation technique simplifiée en vertu de l’Article 33.5. Celui-ci dispose que la Commission européenne devra préciser les détails du formulaire simplifié au moyen d’actes délégués. Affaire à suivre donc.

5. Réalisez une évaluation des risques cyber en amont de la conception d’un produit

Comme indiqué plus haut, les 13 exigences essentielles du règlement relatives aux produits doivent être appliquées en tenant compte des risques de cybersécurité spécifiques au produit dont il est question. Et pour déterminer ces risques, il n’y a pas trente-six mille solutions : il faut procéder à une évaluation des risques cyber.

La sécurité tout au long du cycle de vie des produits

L’évaluation des risques doit être réalisée par le fabricant, en amont de la conception du produit. Elle servira ensuite à alimenter les réflexions et les choix en matière de sécurité tout au long du cycle de vie du produit.

“Les fabricants d’un produit doivent réaliser une évaluation des risques de cybersécurité qui lui sont associés, et tenir compte des résultats de cette évaluation durant les phases de planification, de conception, de développement, de production, de livraison et de maintenance du produit, en vue de réduire au minimum les risques de cybersécurité, de prévenir les incidents de sécurité et de réduire au minimum les conséquences de ces derniers, notamment en ce qui concerne la santé et la sécurité des utilisateurs.” – CRA, Article 13.2

Cette notion de sécurité à chaque étape du cycle de vie du produit, depuis les prémices de sa conception jusqu’à la fin de la période de support, est au cœur de la Loi sur la cyber-résilience. Les fabricants ont désormais le devoir de veiller à ce que leurs produits soient toujours sécurisés, et pas seulement lorsqu’ils sont mis sur le marché. Puisqu’elle est la raison d’être de toutes les exigences essentielles du règlement, la sécurité continue des produits devrait être le point de mire de tous les gestionnaires de la sécurité concernés.

Les éléments à inclure dans l’évaluation des risques cyber

Ce même Article 13 dispose que l’évaluation doit comprendre au minimum une analyse des risques de cybersécurité fondée sur :

• L’utilisation prévue et l’utilisation raisonnablement prévisible du produit ;
• Les conditions d’utilisation du produit, telles que l’environnement opérationnel ou les actifs à protéger ;
• En tenant compte de la durée d’utilisation prévue du produit.

Elle doit également indiquer clairement :

• Comment les exigences essentielles relatives aux produits s’appliquent au produit concerné, et comment elles sont mises en œuvre ;
• Comment le fabricant s’assurera que le produit est conçu, développé et produit de manière à garantir un niveau approprié de cybersécurité ;
• Comment le fabricant appliquera les exigences essentielles en matière de gestion des vulnérabilités.

Un devoir de diligence si le produit intègre des composants tiers, y compris open-source

Le CRA prend soin de préciser que les fabricants doivent conduire une “due diligence” si leurs produits intègrent des composants tiers, y compris open-source. Il faut donc évaluer les risques intrinsèques à chaque composant tiers, ainsi que ceux posés par la manière dont ils sont intégrés dans le produit.

“Les fabricants font preuve de la diligence nécessaire lorsqu’ils intègrent des composants provenant de tiers de manière à ce que ces composants ne compromettent pas la cybersécurité du produit contenant des éléments numériques, y compris lorsqu’ils intègrent des composants gratuits ou open-source qui n’ont pas été mis à disposition sur le marché dans le cadre d’une activité commerciale.” – CRA, Article 13.5

Le règlement précise que les fabricants doivent prévenir l’entité ou la personne propriétaire du composant tiers s’ils venaient à y découvrir une vulnérabilité – ce qui semble être la moindre des politesses. Il faut ensuite la traiter et y remédier conformément aux exigences essentielles en matière de gestion des vulnérabilités (Article 13.6). C’est un point qui nous paraît délicat, puisque la correction de la vulnérabilité sera le plus souvent à la charge du propriétaire du composant tiers.

À notre avis, le plus sage est d’éviter, dans la mesure du possible, d’intégrer des composants tiers qui comportent une vulnérabilité identifiée ; d’autant plus que le CRA ne fait ici aucune différence entre les vulnérabilités qui représentent un vrai risque de sécurité et celles qui n’auraient aucun impact. Néanmoins, précisons que si le fabricant décide de mettre sur pied un correctif, logiciel ou matériel, il est tenu d’en partager le contenu avec le propriétaire du composant tiers.

Enfin, sachez que l’évaluation des risques doit être incluse dans la documentation technique, en plus d’être documentée et mise à jour tout au long de la période de support du produit (voir Chapitre 13).

6. Intégrez la sécurité à chaque étape du processus de création d’un produit

Une fois l’évaluation des risques réalisée, il faut s’atteler au gros du travail : la création du produit. Ici comme ailleurs, le plus important est, comme le veut la formule consacrée, de penser la sécurité au plus près du produit. Concrètement, il s’agit de mettre en œuvre les 13 exigences essentielles de cybersécurité des produits en intégrant des jalons de sécurité à chaque étape du cycle de vie.

Passer des exigences généralistes du CRA à des normes harmonisées

Avant tout, il convient de spécifier les solutions techniques qui permettront de répondre aux exigences essentielles. En effet, le CRA est un texte de droit européen, et pas une documentation technique rédigée par et pour des ingénieurs. Les exigences essentielles ne sont jamais plus que cela ; le CRA énumère des objectifs à atteindre, mais ne dit jamais comment les atteindre.

Prenons l’exemple de la seconde exigence applicable aux produits, à savoir qu’ils soient “mis à disposition sur le marché avec une configuration sécurisée par défaut.” Tout le monde est à même de comprendre l’objectif, clair et général, mais c’est une autre paire de manches que de faire en sorte qu’il soit atteint.

Transposer ces exigences réglementaires générales en exigences techniques auxquelles les fabricants peuvent se conformer, c’est le rôle des normes harmonisées européennes. Un ensemble de lignes directrices élaborées par des organismes de normalisation, fournissant des spécifications techniques dont l’utilisation prouve que les produits et les services atteignent un certain niveau de qualité, de sécurité et de fiabilité.

Il existe des normes harmonisées pour toutes sortes de choses, et ce n’est qu’une question de temps avant que n’arrivent celles préconisées pour le CRA. Pour autant, il existe déjà un certain nombre de standards et de bonnes pratiques en matière de cybersécurité dont l’application ne peut être que bénéfique. Les normes harmonisées européennes viendront standardiser l’existant et adresser les angles morts, mais certains efforts à fournir sont déjà clairement identifiés pour peu que l’on sache où chercher.

Mettre en miroir les exigences essentielles avec des spécifications techniques

Dans l’attente de normes harmonisées spécifiques, l’un des meilleurs documents disponibles à ce jour est la Cartographie des normes relatives aux exigences du Cyber Resilience Act (2024), publiée conjointement par le Centre Commun de Recherche (CCR) et l’Agence de l’Union européenne pour la cybersécurité (ENISA).

Ce document précieux fait correspondre chacune des exigences essentielles du CRA avec un ou plusieurs standards existants. L’objectif premier de cette publication est de contribuer à l’élaboration de normes harmonisées en recensant ce qui existe déjà, mais elle peut également être utile aux fabricants qui souhaitent adopter dès à présent les bonnes pratiques en matière de cybersécurité.

Prenons l’exemple de la septième exigence essentielle relative aux produits : “Ne traiter que des données, personnelles ou autres, qui sont adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité du produit.”

Ici, le document du CCR et de l’ENISA souligne la valeur de la norme ISO/IEC 27701, une extension des normes ISO/IEC 27001 et ISO/IEC 27002 pour la gestion des informations relatives à la vie privée. Bien qu’elle ne soit pas spécifique aux produits, l’ISO 27701 propose une correspondance utile entre diverses normes et législations comme le RGPD, en plus de couvrir correctement le concept de minimisation des données. Elle sera donc utile aux fabricants en ce qui concerne l’exigence essentielle susmentionnée.

Ce n’est qu’un exemple, mais la Cartographie des normes offre des pistes de réflexion intéressantes pour chacune des exigences essentielles du règlement, aussi bien pour ce qui est de la cybersécurité des produits que de la gestion des vulnérabilités – même si, bien souvent, le constat des auteurs est que l’existant est trop théorique, et donc insuffisant, et que les futures normes harmonisées devront préciser les spécifications techniques attendues.

Quoi qu’il en soit, nous recommandons vivement cette lecture à toute personne impliquée dans la réflexion sur la sécurité des produits, qu’il s’agisse d’ingénieurs, de développeurs, de chefs de produits, de CTO, CPO ou autres.

Planifier les spécifications techniques à chaque phase du cycle de vie du produit

Chaque exigence essentielle peut être satisfaite par des spécifications techniques appropriées, lesquelles peuvent être planifiées pour une phase spécifique du cycle de vie du produit. Définir clairement quelles exigences et spécifications doivent être adressées à quelle étape vous aidera à organiser vos tâches et celles des équipes de manière plus efficace.

La première chose à faire est de définir précisément les étapes du cycle de vie de votre produit. Elles peuvent varier d’un produit à l’autre, mais certaines décompositions générales offrent une base de travail solide. Par exemple, l’Article 13 du CRA découpe le cycle de vie en six phases : planification, conception, développement, production, livraison et maintenance.

Pour notre part, nous préférons le découpage avancé dans la Cartographie des normes relatives aux exigences du CRA, où les auteurs décomposent le cycle de vie d’un produit de la manière suivante :

1. Conception ;
2. Réalisation ;
3. Validation ;
4. Mise en service ;
5. Surveillance / Maintenance ;
6. Fin de vie.

Ce découpage est particulièrement approprié, puisqu’il considère la fin de vie du produit comme partie intégrante du cycle ; un choix judicieux, puisque les exigences de sécurité du CRA doivent s’appliquer de bout en bout.

Une fois que les phases du cycle de vie et les spécifications techniques à mettre en œuvre ont été déterminées, il ne reste plus qu’à les mettre en correspondance pour avoir une vue d’ensemble de ce qu’il faut faire et quand – oui, c’est plus facile à dire qu’à faire. Gardez toutefois à l’esprit qu’il faudra attendre les normes harmonisées pour que le travail soit fait dans les règles de l’art.

7. Réalisez des tests de sécurité “efficaces et réguliers”

S’il est essentiel (et obligatoire) de penser à la sécurité tout au long du cycle de vie, il l’est tout autant de tester la sécurité réelle des produits.

La sécurité numérique ne peut pas être seulement théorique : il faut s’assurer que tout ce qui a été mis en place est bien efficace. Autrement dit, il faut introduire des jalons de sécurité tout au long de la vie des produits pour s’assurer qu’ils ne présentent pas de vulnérabilités susceptibles d’être exploitées par un acteur malveillant.

La réalisation de tests réguliers et efficaces est une obligation pour les fabricants, puisque ce n’est est autre que la troisième exigence essentielle en matière de gestion des vulnérabilités.

“Les fabricants soumettent les produits comportant des éléments numériques à des tests et examens de sécurité réguliers et efficaces.” – CRA, Annexe I, Partie 2.

De plus, certains modules d’évaluation de la conformité, comme le module H, sur lequel nous reviendrons plus loin, demandent de dresser une description détaillée des tests “qui seront effectués avant, pendant et après la production et la fréquence à laquelle ils auront lieu”. Il ne suffit donc pas de réaliser des tests de sécurité : il faut élaborer et documenter une stratégie de test cohérente, exhaustive et continue.

Pourquoi réaliser des tests de sécurité ?

Au-delà de leur caractère obligatoire, les tests sont une évidence pour assurer un niveau minimum de cybersécurité. Tout produit comportant des éléments numériques contient des vulnérabilités, c’est inévitable. Les tests sont justement là pour les débusquer, puis les classifier.

Certaines vulnérabilités peuvent être extrêmement difficiles à détecter, là où d’autres sauteront aux yeux du premier testeur venu. De même, l’exploitation de certaines vulnérabilités peut avoir des conséquences dramatiques, alors que d’autres n’auront aucun impact sur la sécurité réelle du produit. Après tout, une vulnérabilité peut tout à fait porter sur des fonctionnalités non exploitables, ou ne pouvant pas altérer la sécurité ni l’usage du produit. Supposons qu’une faille dans un radio-réveil connecté permette uniquement de changer la couleur de l’affichage numérique de bleu à rouge : c’est ennuyeux, mais ce n’est pas le piratage du siècle…

Il est d’ailleurs étrange de constater que cette notion d’impact des vulnérabilités exploitables est absente du Cyber Resilience Act ; un fait d’autant plus regrettable que certains acteurs du monde de la cybersécurité avaient déjà souligné cette inconséquence dès les premières versions du règlement. On pense notamment à l’Alliance pour la Confiance Numérique (ACN), qui déplorait déjà début 2023 qu'”une vulnérabilité exploitable n’est en aucun cas un concept absolu ou binaire”. Espérons que les passerelles entre le CRA et les schémas de certification introduits par le Cybersecurity Act, qui font eux cette distinction, et dont nous parlerons dans le chapitre suivant, permettront de gommer ce manque de nuance.

Quoi qu’il en soit, il est impératif de réaliser des tests de sécurité car, au-delà de la détection, ce sont eux qui permettront d’ évaluer le niveau de criticité et l’impact potentiel des vulnérabilités sur le produit et ses utilisateurs. Une vulnérabilité exploitée avec succès par un acteur malveillant peut non seulement compromettre la sécurité de tous, mais aussi avoir des conséquences en termes d’image de marque et de business. En tant que fabricant, il est donc essentiel de faire tout ce qui est en votre pouvoir pour réduire les risques.

Quels tests de sécurité privilégier ?

Il n’existe pas de forme unique de test qui suffirait à tout vérifier. Les tests à mettre en œuvre dépendent de l’objectif poursuivi et, surtout, de la phase du cycle de vie du produit. Les tests de cybersécurité sont nombreux et éclectiques, ont des visées différentes, et n’interviennent pas aux mêmes stades. C’est la combinaison des différents tests qui permettra de construire une stratégie de test solide.

Par exemple, pendant la phase de développement logiciel, il est opportun de mettre en place des revues du code source, des tests unitaires, des tests d’intégration ou des tests de bout en bout. Ceux-ci interviennent en amont de la mise en production, au cours du cycle de vie de développement (SDLC) dans le cadre d’une approche DevSecOps. Ils ne cherchent pas spécifiquement à identifier des vulnérabilités, mais plutôt des problèmes en général, non seulement en termes de sécurité, mais aussi de compatibilité ou de logique. Dans de mauvaises mains, ces derniers peuvent conduire à des vulnérabilités exploitables et dangereuses (ou tout simplement nuire à la qualité et au bon fonctionnement du produit).

D’autres formes de tests sont spécifiquement conçues pour détecter les vulnérabilités de manière proactive. Cela peut être de façon automatique, comme les scanners de vulnérabilités, ou manuelle comme les tests d’intrusion. Elles font partie de ce qu’on appelle plus généralement la Sécurité Offensive, ou OffSec pour Offensive Security.

Le rôle de la Sécurité Offensive dans la stratégie de tests

La Sécurité Offensive est une approche proactive de la cybersécurité : elle ne cherche pas à protéger les produits, mais à identifier leurs vulnérabilités avant les acteurs malveillants. Les tests OffSec simulent des attaques en adoptant la posture des cyber-attaquants, et leurs méthodes, afin d’éprouver les défenses des organisations et de leurs produits, d’identifier leurs faiblesses potentielles, et d’évaluer leur niveau de sécurité réel. Pour le dire plus simplement : la Sécurité Offensive permet aux fabricants de mettre à l’épreuve leurs propres produits afin d’identifier les failles pour mieux les corriger.

L’OffSec permet de tester presque tous les types d’actifs, des infrastructures cloud aux applications web et mobiles, en passant par toutes les formes de produits physiques, qu’ils soient destinés au grand public ou à l’industrie.

Si l’on vous dit tout cela, ce n’est pas par hasard, mais parce que nous, Yogosha, sommes spécialisés dans les tests de sécurité offensifs.

Pentest as a Service (PtaaS)

Le pentest, ou test d’intrusion, est une technique qui vise à simuler une attaque informatique contre un actif, ici un produit, afin d’identifier ses vulnérabilités. C’est une technique éprouvée, que les équipes de sécurité de France et de Navarre connaissent déjà bien, et il est impératif d’y avoir recours pour tester les produits réglementés avant de les mettre sur le marché.

Yogosha propose une approche innovante du test d’intrusion : le Pentest as a Service (PtaaS). Une solution idéale pour toutes les organisations qui doivent réaliser de multiples tests tout au long de l’année, sur de nombreux produits et périmètres.

Le Pentest as a Service (PtaaS) permet :

1. La continuité des tests de sécurité, qui peuvent être échelonnés tout au long du cycle de vie des produits, avant et après leur mise sur le marché, afin de garantir une sécurité solide et permanente conformément aux exigences essentielles du CRA ;
2. L’accès direct à la Yogosha Strike Force (YSF), une communauté de plus de 1000 experts en sécurité certifiés et spécialisés dans différents types d’actifs et de technologies ;
3. La digitalisation et l’industrialisation des activités de test grâce à une plateforme OffSec européenne disponible en SaaS, ou en auto-hébergement pour les acteurs aux exigences de sécurité les plus élevées.

Adopter une approche continue des tests de sécurité

Le CRA appelle à la sécurité continue des produits tout au long de leur cycle de vie. Chez Yogosha, c’est une philosophie que nous appliquons au quotidien.

Historiquement, les tests de sécurité ont toujours été occasionnels : un pentest avant la mise en production, puis plus rien pendant des mois, voire des années. Mais le caractère ponctuel des tests de sécurité traditionnels fait qu’ils ne sont plus adaptés pour répondre aux enjeux de sécurité des fabricants d’aujourd’hui. Ils sont certes utiles pour identifier les vulnérabilités à un instant T, mais ils sont par nature insuffisants pour faire face à la nature fluctuante des cybermenaces.

L’écosystème numérique est dynamique, les mises à jour des produits sont nombreuses et régulières, de nouvelles vulnérabilités apparaissent chaque jour, et les acteurs malveillants renouvellent sans cesse leurs approches. Les tests ponctuels n’offrent qu’une visibilité restreinte, qui expose les entreprises aux risques potentiels qui peuvent survenir entre deux tests.

Pour les fabricants réglementés par le CRA, aux besoins de sécurité croissants, la réponse est donc ailleurs que dans les approches traditionnelles. Il faut pouvoir répondre aux projets en mode Agile, aux livraisons nombreuses et régulières, aux impératifs business… Il faut une approche du test d’intrusion qui soit flexible, évolutive, rationalisée et continue.

Avec le Pentest as a Service, Yogosha propose des tests d’intrusion à la demande, qui peuvent être facilement programmés et répétés tout au long du cycle de vie des produits. Cela permet non seulement de compléter les capacités internes, mais aussi de garder un œil vigilant et constant sur la sécurité des produits réglementés. Il s’agit d’un sérieux avantage, étant donné que l’exécution régulière de tests de sécurité est l’une des exigences essentielles du CRA.

Trouver des experts en sécurité qualifiés

La mise en place de tests de sécurité soulève une autre difficulté : il faut trouver des experts qualifiés pour les réaliser. Là, deux options s’offrent aux fabricants.

Premièrement, disposer des ressources humaines compétentes en interne. Cette option présente de nombreux avantages, mais il existe malheureusement une pénurie mondiale de talents en cybersécurité. Forbes estimait à 3,5 millions le nombre de postes vacants dans le secteur au début de l’année 2023, soit une augmentation de 350% en moins de 10 ans. Les talents sont donc rares et coûteux.

Deuxième solution : faire appel à un prestataire de services spécialisé. C’est la solution retenue par de nombreuses entreprises, qui choisissent d’externaliser les tests de sécurité à un prestataire, le plus souvent un cabinet d’audit. Mais l’expertise d’un cabinet est toujours limitée à celle de ses propres employés, ainsi qu’à leur nombre. Même le pentester le plus talentueux ne sera pas familier avec tous les types de produits et de technologies, c’est impossible. Au moment de choisir le prestataire qui effectuera les tests, il est donc essentiel de s’assurer qu’il dispose des compétences internes correspondant aux spécificités du périmètre à éprouver.

Face à ces deux difficultés – recruter des professionnels qualifiés, ou s’assurer des compétences internes d’un prestataire –, nous apportons une réponse unique : la Yogosha Strike Force.

La Yogosha Strike Force, 1000+ chercheurs en sécurité triés sur le volet

La Yogosha Strike Force (YSF) est une communauté privée et sélective qui regroupe plus de 1000 chercheurs en sécurité internationaux qui sont :

• Spécialisés dans la recherche des vulnérabilités les plus critiques en simulant les attaques sophistiquées des pirates informatiques.
• Experts dans de multiples types d’actifs – Applications Web et Mobiles, IOT, Cloud, Réseaux, API, Infrastructure…
• Titulaires de certifications reconnues en matière de cybersécurité – OSCP, OSEP, OSWE, OSEE, GXPN, GCPN, eWPTXv2, PNPT, CISSP…

Nous sélectionnons uniquement les chercheurs les plus talentueux : seuls 10% des candidats sont acceptés, après avoir réussi des examens techniques et pédagogiques. Leur identité et leurs antécédents sont également vérifiés.

A travers la Yogosha Strike Force, les fabricants visés par le Cyber Resilience Act ont donc accès à :

• Un grand nombre d’experts en sécurité internationaux triés sur le volet ;
• Un panel de compétences sans pareil pour adresser au mieux tous les types de produits et de technologies.

“Par l’intermédiaire de Yogosha, nous avons réussi à trouver des gens vraiment talentueux.” — Éric Vautier, RSSI du Groupe ADP (Aéroports de Paris)

Yogosha, une plateforme de Sécurité Offensive disponible en SaaS ou Self-Hosted

Les tests de sécurité impliquent un certain nombre de données sensibles, comme des informations sur des vulnérabilités potentiellement exploitables. Il est donc essentiel de choisir un prestataire de tests fiable et solide. Il appartient ici aux organisations de se renseigner sur la qualité de chaque fournisseur.

De notre côté, nous proposons plusieurs types de déploiement de notre plateforme de Sécurité Offensive afin de répondre au mieux aux impératifs de sécurité de chaque organisation, y compris les plus sensibles.

La plateforme Yogosha est disponible :

• en SaaS : une solution clé en main, hébergée via 3DS Outscale et son cloud souverain certifié SecNumCloud, la plus haute norme de sécurité française, établie par l’ANSSI. Les données sont hébergées sur le sol français.
• en Self-Hosted : une solution taillée pour les entités aux exigences de sécurité les plus strictes. Vous êtes libre d’héberger la plateforme Yogosha où bon vous semble – cloud privé, on prem – pour garder le contrôle total de vos données et du contexte d’exécution.

Dans les deux cas, la robustesse intrinsèque de notre produit est au centre de nos préoccupations. Nous sécurisons continuellement nos actifs à travers un pipeline DevSecOps, les directives OWASP, des tests d’intrusion récurrents et un programme de bug bounty continu. Par ailleurs, Yogosha est en cours d’obtention de la certification ISO 27001 – un processus qui sera probablement achevé au moment où vous lirez ces lignes.

Le Bug Bounty, une approche recommandée par le Cyber Resilience Act

Le Bug Bounty est une autre approche de la Sécurité Offensive, mentionnée noir sur blanc dans le considérant 77 du CRA – qui préfère parler de “prime aux bogues”, dans un français impeccable. Elle permet aux fabricants de se confronter à la réalité du terrain en mobilisant de nombreux chercheurs en sécurité pour tester tout ou partie de leurs produits ou systèmes.

Le Bug Bounty est une chasse aux bugs qui repose sur une logique de paiement au résultat. Les organisations versent des récompenses monétaires – les bounties donc – aux chercheurs pour chaque vulnérabilité valide qu’ils parviennent à identifier. Plus la vulnérabilité est critique, plus la prime est importante. Si les chercheurs ne trouvent rien, l’organisation ne dépense rien.

Nous ne nous attarderons pas davantage ici sur le Bug Bounty, car il s’agit d’un élément important de la politique de divulgation coordonnée des vulnérabilités (CVD), qui est l’une des exigences essentielles du CRA et le sujet du Chapitre 11 de ce guide.

Néanmoins, précisons dès à présent que Yogosha, en tant que spécialiste de la Sécurité Offensive, propose bien évidemment des programmes de bug bounty. C’est d’ailleurs l’une de nos activités historiques, puisque nous sommes la seule plateforme européenne entièrement privée à proposer des programmes de bug bounty, et ce depuis 2015.

8. Obtenez une certification de cybersécurité pour vos produits

Si les tests permettent de réduire les risques en identifiant les vulnérabilités des produits, la certification permet d’attester d’un niveau de sécurité général élevé. Obtenir une certification de cybersécurité, c’est obtenir la preuve que le produit est aussi sécurisé que possible.

En effet, la certification implique une évaluation approfondie de la sécurité du produit et des processus mis en place par son fabricant. Si tous les voyants sont au vert, la certification vient récompenser le travail bien fait.

Pourquoi obtenir une certification de cybersécurité ?

L’obtention d’une certification demande du temps, de l’argent et un certain engagement de la part des équipes concernées. D’aucuns se demanderont alors si le jeu en vaut la chandelle – spoiler : oui.

Les avantages de la certification sont nombreux, et pas seulement en matière de sécurité. Dans un environnement concurrentiel, la certification peut être un facteur de différenciation fort entre les produits. Les clients peuvent être plus enclins à choisir un produit certifié qu’un produit qui ne l’est pas, car ils auront l’assurance qu’il répond à des normes de sécurité élevées. Si les considérations de cybersécurité ne font pas (encore) partie des principaux critères de choix du commun des mortels, elles peuvent être absolument primordiales si les clients s’avèrent être des organisations, a fortiori lorsqu’elles sont réglementées par la Directive NIS2.

En ce qui concerne le CRA en particulier, l’obtention d’une certification de cybersécurité présente un avantage majeur : elle dispense des procédures d’évaluation de la conformité par un tiers – sous certaines conditions, évidemment.

Les produits certifiés dans le cadre d’un schéma européen présumés conformes aux exigences du CRA

Avant toute chose, il nous faut parler brièvement du Cybersecurity Act (CSA), ou Loi sur la cybersécurité. Il s’agit d’un autre règlement majeur de l’UE adopté en 2019, qui a notamment introduit un cadre de certification de la cybersécurité à l’échelle de l’Union pour les produits, les services et les processus TIC. L’objectif était de garantir un niveau adéquat de cybersécurité et d’harmoniser les évaluations, afin que les entreprises opérant dans l’UE puissent certifier leurs produits une seule fois avec un certificat reconnu sur l’ensemble du territoire.

Si l’on vous dit cela, vous vous doutez bien que ce n’est pas pour la culture générale. En effet, le Cyber Resilience Act dispose que les produits certifiés selon un schéma de certification européen élaboré dans le cadre du Cybersecurity Act sont présumés conformes aux exigences essentielles du CRA, dès lors qu’elles ont été appréciées au cours du processus de certification.

“Les produits comportant des éléments numériques et les processus mis en place par le fabricant pour lesquels une déclaration UE de conformité ou un certificat de cybersécurité européen ont été délivrés dans le cadre d’un schéma européen de certification de cybersécurité adopté conformément au règlement (UE) 2019/881 [NDLR : le Cybersecurity Act] sont présumés conformes aux exigences essentielles énoncées à l’annexe I, dans la mesure où celles-ci sont couvertes par la déclaration UE de conformité ou le certificat de cybersécurité européen, ou des parties de ceux-ci.” – CRA, Article 27.8

Le règlement précise bien que seules les certifications délivrées dans le cadre d’un schéma européen au titre du Cybersecurity Act peuvent constituer une preuve de conformité.

Par ailleurs, la certification à un niveau d’assurance au moins “substantiel” dispense de l’obligation d’effectuer une évaluation de la conformité par un tiers, autrement obligatoire pour certaines catégories de produits – on y reviendra.

“En outre, la délivrance d’un certificat de cybersécurité européen au titre de tels schémas, au minimum au niveau d’assurance dit ‘substantiel’, supprime l’obligation d’un fabricant de procéder à une évaluation de la conformité par un tiers pour les exigences correspondantes.” – CRA, Article 27.9

Les schémas de certification européens introduits par le Cybersecurity Act (CSA)

Le Cybersecurity Act a amené avec lui trois schémas de certification européens, dont l’élaboration à été confiée à l’ENISA :

• Le schéma EU5G sur la sécurité des réseaux 5G ;
• Le schéma EUCS sur la sécurité des services cloud ;
• Le schéma EUCC pour les produits TIC (matériel, logiciels et composants).

C’est ce dernier schéma qui nous intéresse particulièrement dans le contexte du CRA.

Le schéma EUCC : des règles de certification harmonisées pour les produits TIC

Le schéma EUCC (EU Common Criteria) est le premier – et le seul à ce jour – des trois cadres à avoir été officiellement adopté par la Commission européenne, le 31 janvier 2024. Il fournit un ensemble de règles et de procédures harmonisées pour certifier les produits TIC, matériels comme logiciels, ceux-là mêmes qui sont réglementés par le Cyber Resilience Act.

Le cadre EUCC repose sur les Critères Communs (un ensemble de normes d’évaluation des systèmes informatiques) et pioche dans les différents cadres nationaux existants qui étaient rassemblés au sein du SOG-IS, un accord européen de reconnaissance mutuelle des certificats délivrés par une autorité nationale, comme l’ANSSI en France. Cette dernière a d’ailleurs confirmé que “les certificats SOG-IS existants pourront être réévalués en certificats EUCC dès lors que les nouvelles exigences seront respectées.” (Source)

Nous ne détaillerons pas davantage le contenu du schéma EUCC, car le sujet est si riche qu’il pourrait faire l’objet d’un autre guide. Toutefois, si le sujet vous intéresse, voici quelques documents de référence :

• L’acte d’exécution du schéma EUCC publié au Journal officiel de l’UE ;
• Un ensemble de textes sur l’état de l’art pour le schéma EUCC, publié par l’ENISA. Vous y trouverez de nombreux documents portant sur des sujets tels que l’accréditation des organismes d’évaluation de la conformité, ou les aspects techniques de l’évaluation des cartes à puce ou des dispositifs matériels dotés de boîtiers de sécurité, deux catégories de produits critiques aux yeux du CRA.

À noter que les premiers certificats EUCC pourront être délivrés à partir de février 2025, un an après la publication du schéma.

Quels sont les produits soumis à une obligation de certification ?

Les produits critiques au regard du CRA peuvent être soumis à une certification obligatoire, mais pas par défaut. En effet, l’Article 8 donne à la Commission européenne le droit de décider, au moyen d’actes délégués, quelles catégories de produits critiques sont tenues d’obtenir une certification européenne de cybersécurité à un niveau d’assurance au moins “substantiel”. Là encore, le niveau de dépendance des entités réglementées par la Directive NIS2 vis-à-vis des produits examinés pèsera dans la balance.

Cette obligation n’est matérialisée que par un tel acte délégué ; en son absence, les produits critiques ne sont pas tenus d’être certifiés. Ils sont alors soumis à la même procédure d’évaluation de la conformité que les produits importants de Classe II, sur laquelle nous reviendrons dans le chapitre suivant.

Dans le cas d’un acte délégué qui introduit une obligation de certification pour une catégorie de produits critiques, la règle générale est d’observer une période de transition de 6 mois avant que les nouvelles règles ne soient appliquées, à moins qu’un impératif de sécurité ne justifie une application plus rapide.

9. Déterminez la procédure d’évaluation de la conformité à appliquer pour chaque produit

La mise en œuvre des exigences essentielles du Cyber Resilience Act est obligatoire, et les fabricants devront montrer patte blanche avant de mettre des produits réglementés sur le marché. Il faudra donc apporter la preuve de la preuve de la conformité, au moyen d’une évaluation.

Le CRA instaure différentes procédures d’évaluation de la conformité, plus ou moins strictes selon le niveau de risque des produits. Le premier niveau consiste en une auto-évaluation par les fabricants, tandis que les procédures avancées exigent le recours à un organisme d’évaluation tiers, ou l’obtention d’une certification de cybersécurité.

Quatre procédures d’évaluation basées sur différents modules

L’Article 32 du CRA introduit quatre procédures d’évaluation de la conformité, chacune basée sur un ou plusieurs modules :

• Procédure d’évaluation 1 : Module A
• Procédure d’évaluation 2 : Module B + Module C
• Procédure d’évaluation 3 : Module H
• Procédure d’évaluation 4 : L’obtention d’une certification selon un schéma européen publié dans le cadre du Cybersecurity Act, sujet que nous avons évoqué dans le chapitre précédent.

Les fabricants peuvent utiliser n’importe laquelle de ces procédures, à l’exception des produits importants ou critiques qui ne peuvent pas bénéficier de la première.

Les modules en question sont :

1. Module A : Procédure d’évaluation de la conformité basée sur le contrôle interne ;
2. Module B : Examen UE de type ;
3. Module C : Conformité au type sur la base du contrôle interne de la fabrication ;
4. Module H : Conformité sur la base de l’assurance complète de la qualité.

Le module A correspond à une auto-évaluation par le fabricant, tandis que les modules B + C impliquent le recours à un organisme de certification indépendant. Le module H consiste en l’application d’un système de qualité approprié et approuvé par un organisme tiers.

Nous ne détaillerons pas le contenu exact de chaque module dans ce guide, car toutes les informations pertinentes sont édictées de façon claire et précise dans l’annexe VIII du Cyber Resilience Act.

Sachez néanmoins que, quel que soit le module, la documentation à rassembler est conséquente. Aucun des quatre n’est une mince affaire, et tous nécessiteront de l’organisation et de la rigueur dans la gestion du projet de mise en conformité.

Le cas général : l’auto-évaluation

Lorsque les produits ne sont ni importants ni critiques, les fabricants peuvent opter pour l’auto-évaluation, ce qui correspond à la première procédure d’évaluation (Module A). Il s’agit de la méthode la plus simple de toutes celles prévues par le règlement.

Dans ce cas, le fabricant assure et déclare sous sa seule responsabilité que les produits satisfont à toutes les exigences essentielles de cybersécurité, et qu’il a bien respecté les exigences essentielles en matière de gestion des vulnérabilités. Il doit également établir la documentation technique et la déclaration UE de conformité, et apposer le marquage CE sur le produit.

Les fabricants qui peuvent bénéficier de l’auto-évaluation mais qui souhaitent appliquer une procédure plus stricte sont bien entendu libres de le faire.

L’évaluation des produits importants et critiques

Les produits importants (classes I et II) ne peuvent être évalués qu’à l’aide des procédures 2, 3 ou 4. En d’autres termes, il est obligatoire de faire appel à un organisme d’évaluation indépendant, ou d’obtenir une certification de cybersécurité appropriée (voir le point suivant). L’auto-évaluation n’est pas possible.

Attention, certains produits critiques peuvent être soumis à une obligation de certification de cybersécurité, en particulier lorsque des entités réglementées par NIS2 en dépendent, afin de s’assurer qu’ils ne peuvent pas être utilisés comme vecteurs d’attaque à leur encontre. La Commission européenne devra préciser les catégories concernées au moyen d’actes délégués. En l’absence d’un tel acte, les produits critiques peuvent choisir entre la certification, la deuxième procédure (module B+C) ou la troisième (module H).

La certification selon un schéma européen comme preuve de conformité

Comme indiqué plus haut, l’obtention d’une certification selon un schéma européen publié dans le cadre du Cybersecurity Act peut suffire à prouver la conformité avec les exigences essentielles du CRA. Il s’agit plus précisément du schéma EUCC, dont nous avons parlé dans le chapitre précédent.

La certification EUCC à un niveau d’assurance au moins “substantiel” dispense de l’évaluation de la conformité par un tiers, autrement obligatoire pour les produits importants et critiques. Il appartient donc aux fabricants de ces produits de choisir entre l’obtention de la certification EUCC ou l’évaluation de la conformité par un organisme indépendant.

“En outre, la délivrance d’un certificat de cybersécurité européen au titre de tels schémas, au minimum au niveau d’assurance dit ‘substantiel’, supprime l’obligation d’un fabricant de procéder à une évaluation de la conformité par un tiers pour les exigences correspondantes.” – CRA, Article 27.9

Les cas particuliers : open-source, systèmes DME et systèmes d’IA à haut risques

Il existe quelques cas particuliers qu’il nous semble important de préciser : les produits open-source, les systèmes de dossiers médicaux électroniques (DME) et les systèmes d’IA à haut risques.

L’évaluation des produits avec des éléments open-source

Les produits contenant des éléments open-source peuvent avoir recours à l’auto-évaluation (module A). Cela s’applique également aux produits open-source considérés comme importants, comme précisé par l’Article 32.5 du CRA, et son considérant 92 :

“Les fabricants de produits importants comportant des éléments numériques qualifiés de logiciels libres devraient pouvoir suivre la procédure de contrôle interne basée sur le module A, à condition de mettre la documentation technique à la disposition du public.” – CRA, Considérant 92

L’évaluation des système de dossiers médicaux électroniques (DME)

Les systèmes de dossiers médicaux électroniques (DME) sont à la fois réglementés par le CRA et l’EHDS (European Health Data Space Regulation). Néanmoins, pour prouver leur conformité, les fabricants ne doivent pas appliquer les procédures d’évaluation du CRA mais celles détaillées dans le Chapitre III du EHDS.

Cette mesure est précisée à l’Article 32.6 du CRA, qui pourrait néanmoins disparaître de la version finale du règlement. En effet, ce même article pourrait être introduit directement dans l’EHDS si ce dernier venait être publié bien plus tard que le CRA. Mais ce n’est là qu’un jeu d’écriture, et ça ne changerait rien pour les fabricants concernés.

L’évaluation des systèmes d’IA à haut risques

Il peut arriver que des produits embarquant du numérique soient également considérés comme des systèmes d’IA à haut risques selon l’Article 6 de l’Artificial Intelligence Act (AI Act), la loi européenne sur l’intelligence artificielle adoptée en mars 2024.

En effet, l’Article 15 de l’AI Act amène des exigences en matière de précision, de robustesse et de cybersécurité des systèmes d’IA. Se pose alors la question de savoir quelle législation prévaut sur l’autre en matière de sécurité numérique…

L’Article 12 du CRA lève tout doute en indiquant que les systèmes d’IA à haut risque sont considérés comme étant conformes aux exigences de cybersécurité de l’AI Act si :

• Ces produits satisfont aux exigences essentielles du CRA en matière de cybersécurité des produits et de gestion des vulnérabilités ;
• Le niveau de cybersécurité est démontré par la déclaration UE de conformité délivrée en vertu du CRA.

De manière générale, c’est toujours la procédure d’évaluation de la conformité définie par l’Article 43 de l’IA Act qui s’applique, même si l’évaluateur doit être compétent en la matière des deux réglementations. En revanche, si le système d’IA à haut risques est également considéré comme un produit important ou critique par le CRA, alors ses procédures d’évaluation s’appliquent également en ce qui concerne ses exigences essentielles.

10. Connaissez (et respectez) les délais de signalement des incidents graves et des vulnérabilités exploitées

Dans la droite lignée de la Directive NIS2, le Cyber Resilience Act introduit également des obligations de signalement des incidents graves et des vulnérabilités activement exploitées aux autorités.

Nous attirons votre attention sur le fait que le respect de ces exigences est de la plus haute importance. Non seulement pour des raisons évidentes de sécurité générale, mais aussi parce que leur non-respect peut donner lieu à des amendes substantielles, exception faite des micro-entreprises, des PME et des gestionnaires de logiciels open-source.

En outre, toutes les dispositions à ce sujet seront applicables 21 mois après la publication officielle du CRA, contrairement aux autres qui entreront en application après 36 mois. La publication du règlement étant attendue pour 2024, il est raisonnable de dire que les obligations de signalement des incidents graves et des vulnérabilités exploitées s’appliqueront dès 2026.

Des signalements obligatoires à faire simultanément à l’ENISA et au CSIRT compétent

Les obligations en matière de signalement des incidents graves et des vulnérabilités exploitées sont introduites par l’Article 14. On vous épargne la paraphrase du texte officiel, qui est clair comme de l’eau de roche :

“Un fabricant doit notifier toute vulnérabilité activement exploitée contenue dans le produit comportant des éléments numériques dont il prend connaissance simultanément au CSIRT désigné comme coordinateur […] et à l’ENISA. Le fabricant notifie cette vulnérabilité activement exploitée par l’intermédiaire de la plateforme unique de notification établie conformément à l’Article 16.” – CRA, Article 14.1

L’Article 14.3 entérine quant à lui la même obligation en ce qui concerne les incidents graves.

Pour résumer, les fabricants doivent donc :

• Signaler les incidents graves et les vulnérabilités activement exploitées ;
• dans les délais impartis ;
• simultanément à l’ENISA et au CSIRT approprié ;
• via une plateforme unique de signalement.

Plusieurs questions se posent ici, auxquelles nous répondrons par la suite :

• Que sont l’ENISA et les CSIRT ?
• Comment savoir à quel CSIRT s’adresser ?
• Qu’est-ce que la plateforme unique de signalement ?
• Qu’est-ce qu’un “incident grave” ?
• Qu’est-ce qu’une “vulnérabilité activement exploitée” ?
• Quels sont les délais de notification introduits par le CRA ?

Que sont l’ENISA et les CSIRT ?

L’ENISA est l’Agence de l’Union européenne pour la cybersécurité, un acteur incontournable du paysage cyber de l’Union et, de facto, du Cyber Resilience Act. Parmi ses nombreuses missions, l’ENISA est notamment chargée de créer les différents schémas de certification en cybersécurité découlant du Cybersecurity Act évoqués précédemment (EU5G, EUCS, EUCC).

Dans le contexte du CRA, les CSIRT (Computer Security Incident Response Team) sont des équipes spécialisées désignées par les différents pays de l’UE, chargées de coordonner la cybersécurité au niveau national et de réagir aux incidents cyber sur leur sol. A titre d’information, vous croiserez peut-être le terme CERT (Computer Emergency Response Team), qui est souvent utilisé de manière interchangeable avec CSIRT.

Il y a par exemple le CERT-BE en Belgique, le CERT-Bund en Allemagne, le GR-CSIRT en Grèce, ou encore le CERT-FR en France, qui est le CSIRT à compétence nationale rattaché à l’ANSSI (Agence nationale de la sécurité des systèmes d’information). Vous trouverez la liste des CSIRT de chaque pays de l’Union sur le site officiel du réseau, CSIRTs Network.

Comment savoir à quel CSIRT s’adresser ?

C’est simple : en cas d’incident grave ou de vulnérabilité exploitée, les fabricants doivent avertir le CSIRT désigné comme coordinateur dans l’État membre où ils ont leur établissement principal dans l’Union.

L’Article 14.7 du CRA dispose qu’un fabricant est réputé avoir son établissement principal dans l’Union dans l’État membre où sont principalement prises les décisions relatives à la cybersécurité des produits comportant des éléments numériques.

Si un tel État membre ne peut être déterminé, l’établissement principal est considéré comme se trouvant dans l’État membre où le fabricant possède l’établissement comptant le plus grand nombre de salariés.

Si l’établissement principal ne peut toujours pas être déterminé, le fabricant doit avertir le CSIRT le plus approprié selon l’ordre suivant :

1. L’État membre dans lequel le mandataire agissant au nom du fabricant pour le plus grand nombre de produits comportant des éléments numériques de ce fabricant est établi ;
2. L’État membre dans lequel l’importateur qui met sur le marché le plus grand nombre de produits comportant des éléments numériques de ce fabricant est établi ;
3. L’État membre dans lequel le distributeur qui met à disposition sur le marché le plus grand nombre de produits comportant des éléments numériques de ce fabricant est établi ;
4. L’État membre dans lequel se trouvent le plus grand nombre d’utilisateurs de produits comportant des éléments numériques de ce fabricant.

Qu’est-ce que la plateforme unique de signalement ?

Les signalements doivent se faire simultanément à l’ENISA et au CSIRT approprié, et à chaque fois “par l’intermédiaire de la plateforme unique de notification” de l’Union européenne. Elle doit être administrée et maintenue par l’ENISA, et permettre à chaque CSIRT national de “mettre en place leurs propres points finaux de notification électronique.”

Malheureusement, il est difficile de vous en dire plus pour le moment, car cette plateforme est encore en gestation à l’heure où nous écrivons ces lignes. Si le CRA entérine la responsabilité de l’ENISA dans le développement du projet, les détails de sa mise en œuvre demeurent incertains. D’aucuns s’interrogent d’ailleurs sur sa capacité à mener à bien une telle tâche. Ce ne sont évidemment pas la compétence et la qualité des équipes de l’ENISA qui sont questionnées, mais bien ses effectifs et sa bande passante.

Pour mémoire, l’Agence européenne emploie une centaine de personnes réparties entre son siège à Athènes, Héraklion et Bruxelles. Un effectif somme toute modeste, surtout si l’on considère l’ampleur des travaux à réaliser, de ses missions quotidiennes à la conception des schémas de certification demandés par le Cybersecurity Act, en passant par la création d’une base de données européenne sur les vulnérabilités suite à NIS2, à l’image de la base CVE maintenue par le MITRE. Autant de tâches auxquelles s’ajoutent les impératifs du CRA, comme la plateforme de signalement ou les rapports techniques bisannuels sur les tendances émergentes en matière de risques cyber dans les produits comportant des éléments numériques (Article 17).

Qu’est-ce qu’un “incident grave” ?

C’est bien beau de devoir signaler les incidents graves, mais encore faut-il savoir de quoi il s’agit ! Heureusement, l’Article 14.5 du Cyber Resilience Act est là pour nous éclairer.

Un incident ayant un impact sur la sécurité du produit est considéré comme grave lorsque :

• Il entache ou est susceptible d’entacher la capacité d’un produit comportant des éléments numériques à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes ; ou
• Il a conduit ou est susceptible de conduire à l’introduction ou à l’exécution d’un code malveillant dans un produit comportant des éléments numériques ou dans le réseau et les systèmes d’information d’un utilisateur du produit.

Qu’est-ce qu’une “vulnérabilité activement exploitée” ?

Pour trouver la réponse, il faut se tourner vers l’Article 3 du CRA, consacré aux définitions.

“‘Vulnérabilité activement exploitée’ : une vulnérabilité pour laquelle il existe des preuves fiables qu’elle a été exploitée par un acteur malveillant dans un système sans l’autorisation du propriétaire du système.” – CRA, Article 3.42

Les délais obligatoires de signalement d’un incident grave

Les délais de signalement relatifs aux incidents graves sont détaillés dans l’Article 14.4. On ne peut que saluer la décision du régulateur de s’aligner sur les délais de notification introduits par la Directive NIS2, afin de standardiser les processus à travers l’Union et de simplifier la vie des entités régulées.

En cas d’incident grave, le fabricant doit soumettre simultanément à l’ENISA et au CSIRT compétent :

1. Une première notification au plus tard 24 heures après en avoir pris connaissance. Elle doit indiquer, au minimum, si l’incident est suspecté d’avoir été causé par des actes illicites ou malveillants et, le cas échéant, les pays de l’UE dans lesquels le produit a été mis à disposition ;
2. Une deuxième notification au plus tard 72h après avoir pris connaissance de l’incident, à moins que les informations pertinentes n’aient déjà été communiquées. Elle doit fournir :
   • les informations générales disponibles sur la nature de l’incident ;
   • l’évaluation initiale de l’incident, ainsi que toute mesure corrective ou d’atténuation qui a été prise ;
   • les mesures correctives ou d’atténuation que les utilisateurs peuvent prendre ;
   • s’il y a lieu, le degré de sensibilité que le fabricant prête aux informations notifiées.
3. Un rapport final dans un délai d’un mois à compter de la précédente notification, à moins que les informations pertinentes n’aient déjà été communiquées. Ce rapport doit comprendre au moins :
   • une description détaillée de l’incident, y compris de sa gravité et de son impact ;
   • le type de menace ou la cause profonde qui a probablement déclenché l’incident ;
   • les mesures d’atténuation appliquées et en cours.

Les délais obligatoires de signalement d’une vulnérabilité activement exploitée

Les délais de signalement relatifs aux vulnérabilités exploitées sont détaillés dans l’Article 14.2. Là encore, la Loi sur la cyber-résilience s’aligne peu ou prou sur les mêmes fenêtres que NIS2.

En cas de vulnérabilité activement exploitée, le fabricant doit soumettre simultanément à l’ENISA et au CSIRT compétent :

1. Une première notification au plus tard 24 heures après en avoir pris connaissance. Elle doit indiquer les États membres de l’UE dans lesquels le produit a, à sa connaissance, été mis à disposition ;
2. Une deuxième notification au plus tard 72h après en avoir pris connaissance, à moins que les informations pertinentes n’aient déjà été communiquées. Elle doit préciser :
   • les informations générales disponibles sur le produit concerné ;
   • la nature générale de l’exploitation et de la vulnérabilité concernée ;
   • toute mesure corrective ou d’atténuation qui a été prise ;
   • les mesures correctives ou d’atténuation que les utilisateurs peuvent prendre ;
   • s’il y a lieu, le degré de sensibilité que le fabricant prête aux informations notifiées.
3. Un rapport final au plus tard 14 jours après la mise à disposition d’une mesure de correction ou d’atténuation, à moins que les informations pertinentes n’aient déjà été communiquées. Ce rapport doit comprendre au moins :
   • une description de la vulnérabilité, y compris de sa gravité et de son impact ;
   • le cas échéant, des informations concernant tout acteur malveillant ayant exploité ou exploitant la vulnérabilité ;
   • des précisions concernant la mise à jour de sécurité ou les autres mesures correctives qui ont été mises en place pour remédier à la vulnérabilité.

Une obligation de prévenir les utilisateurs affectés

Dans son Article 14.8, le CRA introduit également une notion de notification aux utilisateurs d’un produit sujet à un incident grave ou à une vulnérabilité exploitée.

“Après avoir pris connaissance d’une vulnérabilité activement exploitée ou d’un incident grave, le fabricant informe les utilisateurs du produit affectés et, s’il y a lieu, tous les utilisateurs de la vulnérabilité activement exploitée ou de l’incident grave ayant un impact sur la sécurité du produit et, le cas échéant, de toute mesure corrective ou d’atténuation des risques que les utilisateurs peuvent mettre en place pour atténuer l’impact de cette vulnérabilité ou de cet incident, s’il y a lieu dans un format structuré, pouvant être facilement traité automatiquement et lisible par machine.

Lorsque le fabricant n’informe pas les utilisateurs du produit […] en temps utile, les CSIRT notifiés désignés comme coordinateurs peuvent fournir ces informations aux utilisateurs lorsqu’ils le jugent proportionné et nécessaire pour prévenir ou atténuer l’impact de cette vulnérabilité ou de cet incident.” – CRA, Article 14.8

Le texte prend soin de distinguer les utilisateurs affectés, qu’il faut prévenir quoiqu’il arrive, de l’ensemble des utilisateurs du produit, qu’il faut prévenir “s’il y a lieu”. Dans les deux cas, la notification aux utilisateurs doit s’accompagner des mesures correctives ou d’atténuation qu’ils peuvent mettre en place – sans quoi le signalement n’aurait de toute façon que peu d’intérêt, voire causerait plus de tort que de bien…

Le sujet épineux de la notification aux utilisateurs

En effet, la notification des utilisateurs est un sujet sensible, où tout est question de timing – timing qui n’est pas spécifié par le Cyber Resilience Act, tant il sera spécifique à chaque situation.

Pour simplifier, on peut envisager trois possibilités :

• Trop tôt : Notifier les utilisateurs avant le déploiement d’une mise à jour les mettrait en danger, car cela alerterait également certains acteurs malveillants qui pourraient tenter de tirer profit de l’information.
• Lors du déploiement d’une mise à jour : Informer les utilisateurs des détails d’une vulnérabilité dès qu’une mise à jour est disponible pourrait exposer ceux qui ne l’appliquent pas immédiatement ; ce qui n’est pas rare dans le cas des produits IoT, qui ne sont parfois jamais mis à jour par les utilisateurs, voire jamais connectés à l’internet, entravant les mises à jour automatiques des fabricants.
• Trop tard : Ne jamais avertir les utilisateurs, ou les avertir trop tard, c’est courir le risque de les laisser vulnérables à une menace dont ils ne sont pas conscients, et face à laquelle ils ne chercheront pas à appliquer un correctif.

Comme disait un grand scribe de son temps : il n’y a pas vraiment de bonne ou de mauvaise situation. Il appartiendra aux fabricants d’évaluer la situation en fonction de la nature du problème, de celle du produit, mais aussi de celle des utilisateurs.

En effet, les enjeux de la notification aux utilisateurs ne seront pas les mêmes selon les profils concernés. Une vulnérabilité exploitée dans le grille-pain connecté de M. Tout-le-monde n’aura pas les mêmes conséquences qu’une vulnérabilité dans un lecteur de cartes à puce intégré dans tous les distributeurs de billets de France et de Navarre.

C’est notamment pour cette raison que le CRA donne aux CSIRT le droit d’informer les utilisateurs si le fabricant ne le fait pas, et s’ils le jugent “proportionné et nécessaire pour prévenir ou atténuer” les conséquences. Il y a fort à parier que cette mesure sera peu voire jamais appliquée dans le cas d’utilisateurs particuliers, mais elle peut permettre d’alerter efficacement des utilisateurs qui seraient des entités sensibles ou critiques, telles que celles réglementées par NIS2.

Enfin, rappelons que, si le CRA demande aux fabricants de “partager et divulguer publiquement des informations sur les vulnérabilités corrigées” dès qu’une mise à jour a été distribuée, il laisse aussi une certaine marge de manœuvre en acceptant que la diffusion de certaines informations soit retardée si des raisons de sécurité l’exigent. Nous vous renvoyons ici au Chapitre 14 de ce guide consacré aux mises à jour.

11. Mettez en place une politique de divulgation coordonnée des vulnérabilités (CVD)

Mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités est une obligation pour les fabricants, puisque ce n’est autre que la cinquième exigence essentielle du CRA en matière de gestion des vulnérabilités. La divulgation coordonnée des vulnérabilités est aussi appelée Coordinated Vulnerability Disclosure (CVD) ou Responsible Disclosure (divulgation responsable), tous ces termes étant utilisés de manière interchangeable.

Ce concept est né de la relation entre les entreprises et les hackers éthiques. Si certains hackers bienveillants souhaitaient exposer les vulnérabilités sur la place publique pour prévenir les utilisateurs, certaines organisations préféraient quant à elles les passer sous silence indéfiniment. En règle générale, aucune de ces deux attitudes ne sert correctement l’intérêt général et la sécurité de tous. La divulgation coordonnée des vulnérabilités s’est alors imposée comme un bon compromis, qui satisfait à la fois l’intérêt général et celui de toutes les parties prenantes.

Avec la divulgation responsable, les fabricants et les chercheurs en sécurité s’engagent à communiquer aux utilisateurs les éventuelles vulnérabilités dans un produit, mais pas avant qu’un correctif ne soit disponible. Les utilisateurs peuvent alors adopter les mesures de correction, sans être à l’entière merci d’une vulnérabilité exploitable.

Qu’est-ce que la divulgation coordonnée des vulnérabilités ?

La divulgation coordonnée des vulnérabilités (CVD) est le processus de collaboration entre les propriétaires d’actifs numériques et les personnes susceptibles de signaler une vulnérabilité dans ces actifs. Dans le contexte du CRA, les actifs sont les produits réglementés, les propriétaires sont les fabricants, et les personnes qui peuvent signaler les vulnérabilités sont tout un chacun. Néanmoins, comme l’identification d’une vulnérabilité dans un produit requiert un certain niveau d’expertise, les signalements sont généralement effectués par des chercheurs en sécurité, ou hackers éthiques.

Le processus de CVD commence par la collecte d’informations sur une vulnérabilité auprès de la communauté des chercheurs, et se poursuit par la coordination de ces informations entre les chercheurs et les fabricants. Il peut conduire à une divulgation coordonnée de la vulnérabilité (d’où son nom) : une divulgation publique après une remédiation appropriée qui sert les intérêts et la sécurité de toutes les parties concernées – le chercheur, les utilisateurs et le fabricant, mais aussi ses partenaires, ses fournisseurs et potentiellement le grand public.

Qu’est-ce qu’une politique de divulgation coordonnée des vulnérabilités ?

La politique de CVD est, comme son nom l’indique, une politique. Il s’agit d’un document qui consigne tout ce que le fabricant met en place pour faciliter le processus de divulgation responsable : le canal de communication mis à disposition pour le signalement des vulnérabilités, les parties prenantes internes, la procédure de traitement des signalements reçus et toutes les étapes de la collaboration, du premier contact jusqu’au déploiement d’un correctif et à la prévention des utilisateurs.

En d’autres termes, il s’agit de définir clairement et par écrit le processus de divulgation responsable, afin de s’assurer qu’il existe un plan d’action à suivre le jour où une vulnérabilité est signalée. On rappelle que la mise en place d’une politique de CVD est une exigence essentielle obligatoire du Cyber Resilience Act.

Si vous souhaitez approfondir la question, nous vous recommandons la lecture du CERT Guide to Coordinated Vulnerability Disclosure de l’Université Carnegie Mellon. Bien que publié en 2017, il reste l’un des documents de référence sur le sujet. Les standards ISO/IEC 29147:2020 et ISO/IEC 30111:2020 peuvent également se révéler utiles. Le premier propose des lignes directrices pour la divulgation des vulnérabilités, mais sans entrer dans les détails de la CVD, et le second se concentre sur les processus de gestion des vulnérabilités, y compris la divulgation responsable, bien qu’à un niveau théorique.

Mettre en place un canal de communication pour le signalement des vulnérabilités

Le processus de divulgation responsable commence lorsqu’une personne informe le fabricant d’une vulnérabilité potentielle dans un produit. Mais pour que cela soit possible, le fabricant doit avoir mis en place un canal de communication public dédié au signalement des vulnérabilités, et l’avoir clairement indiqué aux utilisateurs. La mise en place d’une telle adresse de contact est une obligation pour les fabricants, puisqu’il s’agit de la sixième exigence essentielle du CRA en matière de gestion des vulnérabilités.

“Toute politique de divulgation coordonnée des vulnérabilités par les fabricants devrait définir un processus structuré dans lequel les vulnérabilités sont signalées à un fabricant de manière à lui donner la possibilité de diagnostiquer la vulnérabilité et d’y remédier avant que des informations détaillées à ce sujet soient divulguées à des tiers ou au public.” – CRA, Considérant 77

Ce canal de communication porte un nom : un programme de divulgation des vulnérabilités, ou Vulnerability Disclosure Program (VDP). Il est important de comprendre que le VDP est un élément de la politique de CVD, mais que ce sont deux choses distinctes. Le premier est un canal de communication, là où le second est un document qui définit les étapes du processus de divulgation responsable.

Le programme de divulgation des vulnérabilités (VDP)

Un Vulnerability Disclosure Program (VDP) est un canal structuré fourni par une organisation pour que quiconque puisse lui signaler un problème de sécurité numérique. En d’autres termes, il s’agit d’un moyen sûr pour que les tiers sachent où et comment signaler des vulnérabilités.

Il est tout à fait possible de rédiger et mettre en place un VDP par soi-même. Il existe de nombreuses ressources pour vous guider, comme par exemple :

• le site Disclose.io, qui propose un générateur de politique de divulgation des vulnérabilités ;
• le site securitytxt.org, qui aide à créer des fichiers security.txt .

En effet, il est de bon ton d’indiquer le moyen de contact prévu par votre VDP dans une notice security.txt, disponible à l’adresse www.siteweb.tld/.well-known/security.txt. A titre d’exemple, voici le security.txt du site Yogosha.

Mettre en place un VDP gratuitement avec Yogosha

Une autre solution est de faire appel à une plateforme spécialisée pour créer et héberger votre VDP. Un exercice auquel nous sommes habitués chez Yogosha, puisque nous proposons des VDP à nos clients depuis 2015. D’ailleurs, la mise en place d’un VDP avec Yogosha est totalement gratuite pour les clients de nos tests de Sécurité Offensive.

Nous accompagnons les organisations à chaque étape du parcours, de la rédaction de la politique de divulgation – scope, règles de divulgation, directives, clauses juridiques et dites “Safe Harbor”, etc. – et nous mettons à disposition une plateforme sécurisée pour collecter et centraliser tous les rapports de vulnérabilités soumis.

Mettre en place un programme de Bug Bounty

Le bug bounty, ou “prime aux bogues”, est un élément important des politiques de divulgation coordonnée des vulnérabilités les plus solides, au point d’être recommandé par le considérant 77 du Cyber Resilience Act.

“[…] Étant donné que les informations sur les vulnérabilités exploitables dans les produits comportant des éléments numériques largement utilisés peuvent être vendues à des prix élevés sur le marché noir, les fabricants de ces produits devraient pouvoir utiliser, dans le cadre de leurs politiques de divulgation coordonnée des vulnérabilités, des programmes visant à encourager le signalement des vulnérabilités en veillant à ce que les personnes ou les entités soient reconnues et récompensées pour leurs efforts. Il s’agit de ce que l’on appelle les programmes dits de «prime aux bogues».” – CRA, Considérant 77

La mise en place d’un programme de bug bounty n’est donc pas une obligation pour les fabricants, mais une bonne pratique recommandée dans le cadre de la politique de CVD, qui elle est obligatoire.

La raison d’être du bug bounty dans une politique de divulgation responsable est très clairement expliquée par le considérant 77 : puisque les informations sur les vulnérabilités peuvent être revendues à prix d’or sur le marché noir, il est important de récompenser les chercheurs bienveillants pour leurs efforts. Du point de vue des fabricants, il est préférable d’encourager et de récompenser la collecte d’informations sur des vulnérabilités potentiellement critiques, plutôt que de les voir exploitées plus tard par des acteurs malveillants. Il existe des failles dans tous les systèmes, et l’enjeu est le même pour les “gentils” comme pour les “méchants” : identifier les vulnérabilités en premier.