TL;DR

Le CRA (Cyber Resilience Act) rend la sécurité obligatoire pour tout ce qui est "numérique" vendu dans l'UE - applications, micrologiciels, IoT, logiciels.

Exige la sécurité dès la conception, l'application de correctifs, la mise en place de SBOM et la divulgation des vulnérabilités tout au long du cycle de vie d'un produit.

Début en décembre 2027. Vous manquez la cible ? Attendez-vous à des amendes de plus de 15 millions d'euros ou à des interdictions de commercialisation.

Résumé de la fiche d'évaluation de la loi sur la cyber-résilience de l'UE (CRA) :

• Effort du développeur : Élevé (nécessite l'intégration de la sécurité tout au long du cycle de vie du produit : conception sécurisée, codage sécurisé, tests rigoureux, mise en œuvre de processus de traitement des vulnérabilités, mise à disposition de mises à jour sécurisées, maintien des SBOM).
• Coût de l'outillage : Modéré à élevé (nécessite des outils SDLC sécurisés - SAST/SCA/DAST, des outils de génération de SBOM, des plateformes de gestion des vulnérabilités, éventuellement une infrastructure de mise à jour sécurisée - plateformes OTA).
• Impact sur le marché : Très élevé (obligatoire pour la quasi-totalité des produits matériels/logiciels vendus dans l'UE ; établit une nouvelle référence mondiale pour les attentes en matière de cybersécurité des produits).
• Flexibilité : Modérée (définit les exigences essentielles mais permet différentes voies d'évaluation de la conformité en fonction de la classification des risques du produit).
• Intensité de l'audit : Modérée à élevée (exige des évaluations de la conformité - auto-évaluation pour les produits standard, évaluation par un tiers pour les produits critiques ; les autorités de surveillance du marché veilleront à l'application de la réglementation).

Qu'est-ce que la loi européenne sur la cyber-résilience ?

La loi européenne sur la cyber-résilience (CRA) est un règlement qui établit des exigences harmonisées en matière de cybersécurité pour les "produits contenant des éléments numériques" (PDE) mis à disposition sur le marché de l'Union européenne. Il vise à s'attaquer au problème généralisé des produits matériels et logiciels non sécurisés et à l'absence de mises à jour de sécurité en temps utile.

L'ARC s'applique largement à presque tous les produits logiciels ou matériels qui peuvent se connecter directement ou indirectement à un autre appareil ou réseau, à quelques exceptions près (par exemple, les appareils médicaux, l'aviation, les voitures déjà couvertes par une législation spécifique, le SaaS à moins qu'il ne soit critique). Cela inclut les appareils IoT grand public, les équipements de réseau, les composants de contrôle industriel, les systèmes d'exploitation, les applications mobiles, les logiciels de bureau, et plus encore.

Les principaux piliers de l'ARC:

1. Exigences essentielles en matière de cybersécurité (annexe I) : Les fabricants doivent s'assurer que les EDP répondent à des objectifs de sécurité spécifiques tout au long de leur cycle de vie. Ceci couvre
   
   • Sécurité dès la conception et par défaut : Les produits doivent être conçus, développés et fabriqués de manière à garantir un niveau approprié de cybersécurité. Ils doivent être livrés avec une configuration sécurisée par défaut.
   • Gestion des vulnérabilités : Les fabricants doivent disposer de processus permettant d'identifier les vulnérabilités et d'y remédier tout au long de la durée de vie prévue du produit ou au moins pendant cinq ans, y compris en fournissant des mises à jour de sécurité "sans délai" et gratuitement.
   • Protection des données : Protection de la confidentialité, de l'intégrité et de la disponibilité des données traitées par le produit.
   • Contrôle d'accès : Prévention de l'accès non autorisé.
   • Résilience : Capacité à résister aux incidents et à s'en remettre.
   • Minimiser la surface d'attaque : Limiter les surfaces d'attaque et atténuer l'impact des incidents.
2. Obligations des opérateurs économiques :
   
   • Fabricants : Ils sont les premiers responsables de la conformité à l'ARC - conception sécurisée, évaluation de la conformité, documentation technique (y compris le SBOM), traitement des vulnérabilités, rapports sur les incidents et les vulnérabilités, mise à jour et instructions claires. Cette obligation s'applique même si le fabricant est établi en dehors de l'UE.
   • Importateurs/distributeurs : ont l'obligation de vérifier la conformité du fabricant (par exemple, le marquage CE, la documentation) avant de mettre les produits sur le marché.
3. Traitement et signalement des vulnérabilités : Les fabricants doivent mettre en place des processus pour traiter efficacement les vulnérabilités et signaler à l'ENISA (Agence européenne pour la cybersécurité) les vulnérabilités activement exploitées dans les 24 heures suivant leur découverte. Ils doivent également informer les utilisateurs des vulnérabilités corrigées et des mises à jour disponibles.
4. Évaluation de la conformité et marquage CE : Les PDE doivent faire l'objet d'un processus d'évaluation de la conformité (allant de l'auto-évaluation du fabricant à la certification par un tiers en fonction de la criticité du produit) pour démontrer leur conformité avant de recevoir un marquage CE et d'être mis sur le marché de l'UE.
5. Surveillance du marché : Désigne les autorités nationales de surveillance du marché chargées de faire appliquer l'ARC, d'enquêter sur les cas de non-conformité et d'imposer des sanctions ou d'exiger le retrait/rappel des produits.

L'ARC est entrée en vigueur fin 2024, la plupart des obligations devenant applicables 36 mois plus tard (vers décembre 2027), tandis que les obligations de déclaration des fabricants s'appliquent plus tôt (vers septembre 2026).

Pourquoi est-ce important ?

L'ARC est un texte législatif qui fait date et dont les implications sont considérables :

• Déplacement de la responsabilité : La responsabilité de la sécurité des produits incombe directement aux fabricants, plutôt qu'aux utilisateurs finaux.
• Renforcement de la sécurité de base : Établit des normes minimales obligatoires en matière de cybersécurité pour une vaste gamme de produits connectés vendus dans l'UE.
• Sécurité de la chaîne d'approvisionnement des logiciels : Traite les vulnérabilités provenant de composants tiers par le biais d'exigences telles que les SBOM et la gestion des vulnérabilités tout au long du cycle de vie.
• Protège les consommateurs et les entreprises : vise à réduire le nombre de produits non sécurisés exploités par les pirates, protégeant ainsi les utilisateurs contre les violations de données, les pertes financières et les risques pour la sécurité.
• Harmonisation des exigences : La création d'un ensemble unique de règles dans l'UE remplace les approches nationales potentiellement fragmentées en matière de cybersécurité des produits.
• Impact mondial : Compte tenu de la taille du marché de l'UE, l'ARC fixe effectivement une norme mondiale, influençant les fabricants du monde entier qui souhaitent vendre leurs produits en Europe.
• Complète d'autres règlements : Ce règlement s'ajoute au NIS2 (sécurisation des services critiques), au GDPR (protection des données personnelles) et au DORA (résilience financière) afin de créer un paysage européen plus complet en matière de cybersécurité.

Pour les fabricants de logiciels et de matériel connecté, la conformité à l'ARC deviendra une exigence fondamentale pour l'accès au marché de l'UE.

Quoi et comment mettre en œuvre (technique et politique)

La mise en œuvre de l'ARC nécessite l'intégration de ses exigences essentielles (annexe I) tout au long du cycle de vie du produit :

1. Conception et développement sécurisés (Security by Design) :
   
   • Modélisation des menaces : Identifier les menaces potentielles et concevoir des contrôles de sécurité dès le départ.
   • Pratiques de codage sécurisées : Former les développeurs et appliquer des normes de codage sécurisées (par exemple, OWASP ASVS, normes de codage CERT). Utiliser des outils SAST.
   • Réduire la surface d'attaque : Limiter les fonctionnalités, les ports ouverts et les privilèges au minimum nécessaire.
   • Sécurité des configurations par défaut : Veiller à ce que les produits soient livrés avec des configurations sécurisées (par exemple, pas de mots de passe par défaut, services inutiles désactivés). Mettre en œuvre une fonctionnalité de réinitialisation sécurisée.
   • Protection des données : Mettre en œuvre le cryptage des données au repos et en transit, le cas échéant. Protéger l'intégrité des données.
   • Contrôle d'accès : Mettre en œuvre des mécanismes d'authentification et d'autorisation robustes.
2. Gestion de la vulnérabilité :
   
   • Analyse des composants (SBOM) : Générer et maintenir une nomenclature logicielle précise (SBOM) identifiant tous les composants (y compris les bibliothèques open-source). Utiliser les outils SCA pour trouver les vulnérabilités connues dans les dépendances.
   • Tests de sécurité : Mettre en œuvre une analyse régulière des vulnérabilités (SAST, DAST, SCA, IaC), des tests fuzz et des tests de pénétration tout au long du développement et après la publication.
   • Processus de traitement des vulnérabilités : Établir des procédures claires pour recevoir les rapports de vulnérabilité (internes/externes), les analyser, développer des correctifs et distribuer les mises à jour "sans délai".
   • Corrections/mises à jour : Fournir gratuitement des mises à jour de sécurité pendant toute la durée de vie prévue du produit (au moins 5 ans). Mettre en œuvre un mécanisme de mise à jour sécurisé (par exemple, des mises à jour OTA sécurisées avec des contrôles d'intégrité).
3. Transparence et documentation :
   
   • Documentation technique : Maintenir une documentation technique détaillée démontrant la conformité aux exigences essentielles. Inclure le SBOM.
   • Information de l'utilisateur : Fournir aux utilisateurs des instructions claires sur l'utilisation sécurisée, la configuration, les mises à jour et la durée de vie du produit.
   • Divulgation des vulnérabilités : établir une politique et un point de contact pour la réception des rapports sur les vulnérabilités ; divulguer publiquement les vulnérabilités corrigées.
4. Évaluation de la conformité :
   
   • Classification des risques : Déterminer si le produit entre dans les catégories "par défaut", "important" (classe I) ou "critique" (classe II) sur la base de l'annexe III.
   • Procédure d'évaluation : Suivre la procédure requise (par exemple, contrôle interne/autoévaluation pour les défaillances, évaluation/certification par un tiers pour les catégories importantes/critiques).
   • Déclaration et marquage CE : Rédiger une déclaration de conformité UE et apposer le marquage CE une fois la conformité démontrée.
5. Obligations de déclaration :
   
   • Vulnérabilités activement exploitées : Rapport à l'ENISA dans les 24 heures suivant la découverte de la faille.
   • Incidents significatifs : Signaler à l'ENISA les incidents ayant un impact sur la sécurité des produits.

La mise en œuvre exige d'intégrer la sécurité dans la culture, les processus et les outils d'ingénierie, de la conception à la maintenance.

Les erreurs courantes à éviter

Les fabricants qui se préparent à l'ARC doivent éviter ces erreurs courantes :

1. Sous-estimation du champ d'application : Croire que l'ARC ne s'applique qu'aux dispositifs IoT complexes et non aux logiciels standard ou au matériel plus simple comportant des éléments numériques. Le champ d'application est très large.
2. Retarder l'action : Attendre une date plus proche de l'échéance de 2027, en sous-estimant les changements importants requis dans la conception, le développement, les essais, la gestion des vulnérabilités et les processus de mise à jour.
3. Traiter la sécurité comme une réflexion après coup : Ne pas intégrer la sécurité dès la phase de conception ("Security by Design") et essayer de l'ajouter plus tard, ce qui est moins efficace et plus coûteux.
4. Gestion inadéquate des vulnérabilités : Absence de processus ou d'outils robustes (SCA, SAST, DAST) pour identifier les vulnérabilités, ou incapacité à fournir des mises à jour de sécurité gratuites et en temps voulu pour le cycle de vie requis.
5. Imprécision/négligence du SBOM : Absence de génération d'un SBOM complet ou de mise à jour au fur et à mesure que les composants changent, ce qui entrave la gestion de la vulnérabilité.
6. Ignorer les mécanismes de mise à jour sécurisés : Ne pas disposer d'un moyen fiable et sécurisé (comme une plateforme OTA robuste) pour fournir des mises à jour "sans délai". Les mises à jour manuelles ne suffiront probablement pas.
7. Documentation insuffisante : Le fait de ne pas conserver la documentation technique, le SBOM et les preuves d'évaluation de la conformité nécessaires à la surveillance du marché.
8. Se concentrer uniquement sur le développement : Négliger les exigences post-commercialisation relatives à la gestion des vulnérabilités et aux mises à jour tout au long du cycle de vie du produit.

Ce que les évaluateurs/autorités pourraient demander (accent mis sur les promoteurs)

Les organismes d'évaluation de la conformité (pour les produits critiques) ou les autorités de surveillance du marché peuvent poser des questions relatives aux exigences de l'ARC ayant un impact sur le développement :

• (Annexe I) Conception sécurisée : "Comment la sécurité a-t-elle été prise en compte pendant la phase de conception ? Pouvez-vous montrer des modèles de menaces ou des documents d'architecture de sécurité ?"
• (Annexe I) Gestion des vulnérabilités : "Quels sont les outils et les processus utilisés pour identifier les vulnérabilités dans le code d'origine et les composants tiers (SAST, SCA) au cours du développement ?"
• (Annexe I) Codage sécurisé : "Quelles sont les normes de codage sécurisées qui sont suivies ? Comment la conformité est-elle assurée (par exemple, linters, examens de code, formation) ?"
• (Annexe I) Tests de sécurité : "Démontrer que des tests de sécurité (par exemple, des tests de pénétration, des tests fuzz) ont été effectués avant la publication.
• (Annexe I) Mises à jour sécurisées : "Décrire le mécanisme de fourniture des mises à jour de sécurité. Comment l'intégrité et l'authenticité des mises à jour sont-elles assurées ?"
• (Art. 10) SBOM : "Fournir la nomenclature du logiciel (SBOM) pour cette version du produit".
• (Art. 10) Traitement des vulnérabilités : "Décrire le processus de traitement d'une vulnérabilité signalée, depuis la réception jusqu'à la publication du correctif.
• (Annexe I) Configuration sécurisée par défaut : "Comment le produit garantit-il une configuration sécurisée dès sa sortie de l'emballage ?

Ils exigeront des preuves des phases de conception, de développement, de test et de maintenance, y compris de la documentation, des rapports d'outils, des descriptions de processus et, éventuellement, l'accès à la revue de code.

Des gains rapides pour les équipes de développement

Bien que la mise en conformité totale avec l'ARC prenne du temps, les équipes de développement peuvent commencer à préparer le terrain :

1. Mettre en œuvre la génération de SBOM : Intégrer des outils pour générer automatiquement un SBOM dans le cadre du processus de construction.
2. Intégrer SCA et SAST : S'assurer que l'analyse de la composition du logiciel et le test statique de la sécurité de l'application fonctionnent de manière fiable dans le pipeline CI/CD.
3. Adopter une modélisation de base des menaces : Commencez à discuter des menaces potentielles lors des réunions de conception des nouvelles fonctionnalités ou des nouveaux produits.
4. Examiner les configurations par défaut : Évaluer activement et renforcer les paramètres par défaut des produits avant leur expédition. Supprimer les informations d'identification par défaut.
5. Documenter le processus de mise à jour : Documenter clairement le processus actuel d'élaboration et de diffusion des mises à jour logicielles, même s'il s'agit initialement d'un processus manuel.
6. Mettre en place un système d'enregistrement des vulnérabilités : Créer un moyen simple et documenté pour les équipes internes ou les chercheurs externes de signaler les vulnérabilités potentielles (par exemple, une adresse électronique ou un formulaire dédié).

Ignorez ceci et... (Conséquences de la non-conformité)

Le non-respect de l'ARC peut avoir des conséquences graves appliquées par les autorités nationales de surveillance du marché :

• De lourdes amendes : Les amendes administratives peuvent atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial total du fabricant pour l'exercice précédent, le montant le plus élevé étant retenu, en cas de non-respect des exigences essentielles. Les infractions moins graves sont passibles d'amendes allant jusqu'à 10 millions d'euros/2 % ou 5 millions d'euros/1 %.
• Retrait/rappel du marché : Les autorités peuvent exiger que les produits non conformes soient retirés du marché de l'UE ou rappelés auprès des utilisateurs finaux.
• Interdiction/restriction de vente : La mise sur le marché de produits non conformes peut être interdite ou restreinte.
• Atteinte à la réputation : La divulgation publique de cas de non-conformité, de rappels ou de vulnérabilités importantes nuit à la confiance dans la marque et à la perception du marché.
• Perte d'accès au marché : Le non-respect des exigences de l'ARC bloque effectivement l'accès à l'ensemble du marché unique de l'UE pour les produits couverts.

FAQ

Quels sont les produits couverts par l'ARC ?

"Produits comportant des éléments numériques" (PDE) dont l'utilisation prévue ou raisonnablement prévisible inclut une connexion de données logique ou physique, directe ou indirecte, à un appareil ou à un réseau. Cela inclut la plupart des logiciels (autonomes, mobiles, intégrés) et le matériel avec connectivité (dispositifs IdO, routeurs, appareils intelligents, composants industriels, etc.) Il existe des exclusions spécifiques (par exemple, les dispositifs médicaux, les voitures, l'aviation, certains SaaS).

Quand les exigences de l'ARC deviennent-elles obligatoires ?

La plupart des obligations, y compris les évaluations de conformité et les exigences essentielles, s'appliquent 36 mois après l'entrée en vigueur de l'ARC (vers décembre 2027). Toutefois, l'obligation de notification du fabricant pour les vulnérabilités et les incidents activement exploités s'applique plus tôt, 21 mois après l'entrée en vigueur (vers septembre 2026).

L'ARC s'applique-t-elle aux logiciels libres ?

Les logiciels libres autonomes développés ou fournis en dehors d'une activité commerciale sont généralement exclus. Cependant, les logiciels libres intégrés dans un produit commercial sont couverts et le fabricant du produit final est responsable. Les projets de logiciels libres dotés de structures formelles (par exemple, des fondations) qui monnayent le soutien ou les versions pourraient également être soumis à certaines obligations de l'ARC (les spécificités sont encore débattues).

Qu'est-ce que le marquage CE dans le contexte de l'ARC ?

Comme pour les autres réglementations européennes sur les produits, les fabricants doivent apposer le marquage CE sur les PDE conformes pour indiquer qu'ils satisfont aux exigences essentielles de l'ARC avant de les mettre sur le marché de l'UE. Pour ce faire, il faut que l'évaluation de la conformité soit réussie.

Qu'est-ce qu'un SBOM et pourquoi est-il nécessaire ?

Une nomenclature logicielle (SBOM) est un enregistrement formel contenant les détails et les relations de la chaîne d'approvisionnement des différents composants utilisés dans la construction d'un logiciel. L'ARC exige des fabricants qu'ils génèrent et tiennent à jour un SBOM pour leurs produits afin d'améliorer la transparence et de faciliter la gestion de la vulnérabilité tout au long de la chaîne d'approvisionnement.

Pendant combien de temps les fabricants doivent-ils fournir des mises à jour de sécurité dans le cadre de l'ARC ?

Les fabricants doivent fournir des mises à jour de sécurité pendant la durée de vie prévue du produit ou pendant une période minimale de cinq ans à compter de la mise sur le marché du produit, la période la plus courte étant retenue. La durée de vie prévue doit être prise en compte lors de la conception. Les mises à jour doivent être gratuites et opportunes ("sans délai").

Quel est le lien entre l'ARC et le NIS2 ou le GDPR ?

• NIS2 : se concentre sur la sécurité des réseaux et des systèmes utilisés par les fournisseurs de services essentiels/importants. L'ARC se concentre sur la sécurité des produits eux-mêmes qui pourraient être utilisés par ces fournisseurs ou les consommateurs.

GDPR : se concentre sur la protection des données personnelles. L'ARC se concentre sur la cybersécurité des produits. Un produit sécurisé dans le cadre de l'ARC contribue à protéger les données à caractère personnel qu'il traite (ce qui va dans le sens du GDPR), mais le champ d'application de l'ARC est plus large que les seules données à caractère personnel. Il s'agit d'éléments complémentaires de la stratégie de l'UE en matière de sécurité numérique.