Stratégie

Les DSI doivent préparer l'arrivée du très strict Cyber resilience act

Tous les produits contenant du logiciel, de l'outil back end au téléphone en passant par la cafetière connectée, sont soumis au règlement sur la cyber résilience. (Image : Pexels/Jakubzerdzicki)

Les premières exigences du Cyber resilience act européen entrent en vigueur en septembre. Il demandera progressivement aux entreprises de produire les preuves de la sécurité de tous les composants logiciels contenus dans leurs produits. Or, peu de DSI semblent encore s'y intéresser.

PublicitéContrairement à la plupart des réglementations en matière de cybersécurité, le règlement européen sur la cyber-résilience (CRA, Cyber resilience act) se concentre sur la sécurité des produits plutôt que sur les processus ou la certification. Il étend le marquage CE des produits physiques aux logiciels, aux firmwares, aux services back-end et à tout élément connecté à un réseau. Il intègre les bonnes pratiques existantes, impose des cycles de vie minimaux pour le support des produits et pourrait pousser les organisations à nouer des relations plus étroites avec la communauté open source. La mise en place du CRA sera progressive, mais dès le 11 septembre prochain, il exigera la mise en place de procédures de signalement des vulnérabilités et des incidents.

Le CRA contraint les organisations à signaler les vulnérabilités activement exploitées dans un de leur produit dans les 24 heures et à fournir un rapport complet dans les trois jours. Des obligations qui pourraient se révéler difficiles à respecter, même pour celles utilisant déjà des nomenclatures logicielles (SBOM, software bill of materials). Si la quasi-totalité des entreprises citées dans le récent rapport de l'éditeur Cloudsmith sur la gestion des artefacts logiciels, génèrent des SBOM, seules un quart d'entre elles le font automatiquement, et non manuellement ou à la demande. Plus de la moitié indiquent qu'un rapport complet exigerait un investissement considérable en temps et en ressources, tandis que moins d'un tiers se disent confiantes dans leur capacité à répondre à un audit inopiné de leur supply chain logicielle, comme le CRA pourra l'exiger.

Les DSI trop peu sensibilisés

« Il y a encore beaucoup d'organisations qui ne respectent pas les bonnes pratiques en matière de supply chain logicielle, insiste Alison Sickelka, vice-présidente produit chez Cloudsmith. Cela explique qu'elles soient obligées de travailler dans l'urgence pour générer des nomenclatures SBOM et produire des rapports dans les délais impartis. Même s'ils sont parfois perçus comme un frein au développement logiciel, les SBOM et l'auditabilité sont désormais indispensables. »

Pour autant, pour beaucoup de DSI, le CRA ne fait pas encore partie de la feuille de route. « Ils le perçoivent peut-être comme une simple formalité administrative, plutôt que comme une réglementation globale assortie d'exigences strictes de reporting couvrant l'intégralité du cycle de vie du produit, de la planification et la conception au support et à la maintenance, analyse Oli Venn, responsable de l'ingénierie chez le fournisseur de solutions de sécurité Watchguard. Un fournisseur, un fabricant ou un distributeur de systèmes numériques, qu'il s'agisse de thermostats intelligents, de machines à café ou de tout autre appareil connecté à Internet ou à un réseau, sont tous soumis à la réglementation. Si des développeurs et des consommateurs utilisent ces systèmes, vous êtes également concerné par le CRA. »

PublicitéTous les produits contenant du logiciel sont concernés

Le Cyber Resiliency Act européen s'applique aux logiciels et appareils tels que les téléphones mobiles, les systèmes d'exploitation embarqués, les bases de données, les jeux, les équipements réseau, les objets connectés et même les billets distribués via une application. Il ne s'applique en revanche pas aux logiciels libres non commerciaux, même si les fondations en assurant le développement ont néanmoins certaines obligations. Si le produit d'une entreprise intègre des éléments de logiciel libre, il lui incombe de garantir leur conformité. Les solutions SaaS pures ne sont pas concernées, mais les logiciels client, les appliances et les appareils utilisant une solution SaaS comme infrastructure le sont. « Le CRA inclut les composants backend, ce que nous appelons des solutions de data remote processing, si le produit inclut une partie serveur », explique Daniel Ehrenberg, ingénieur normalisation au sein du comité Cyber-EUSR de l' Institut européen des normes de télécommunications, créé en 2025 pour travailler sur les normes spécifiquement liées au CRA.

Les produits déjà commercialisés dans l'UE ne sont pas tenus de se conformer pleinement au CRA, sauf s'ils font l'objet de mises à jour importantes. Les entreprises doivent toutefois signaler les incidents et les vulnérabilités les concernant, même si le règlement reconnaît qu'il peut s'avérer impossible de les corriger. Par ailleurs, seuls les produits déjà soumis à des réglementations plus strictes dans des secteurs tels que l'automobile et le médical sont exemptés.

Une indispensable évaluation des risques

Le CRA impose aussi que les produits numériques soient sécurisés by design et par défaut, et interdit leur commercialisation s'ils contiennent des vulnérabilités connues, comme des mots de passe par défaut trop évidents et exploitables, par exemple. Ils doivent également pouvoir être mis à jour au cas où de telles vulnérabilités sont découvertes ultérieurement. L'entreprise doit être capable de minimiser l'impact de ces dernières en réduisant la surface d'attaque et en protégeant la confidentialité et l'intégrité des données grâce au chiffrement et à une collecte minimale de données. « Cela revient à exiger que les logiciels commerciaux gèrent correctement ces sujets, en mettant en place un processus efficace pour traiter les rapports de bugs », explique Daniel Ehrenberg.

« Cela doit commencer par une évaluation des risques », poursuit-il. « Lorsqu'on lance un produit sur le marché, il est indispensable d'évaluer les risques de cybersécurité et de réaliser un audit continu pour connaître les dépendances qui existent en production et déterminer si des mises à jour sont nécessaires. » Et cela inclut les composants issus de fournisseurs . « Il faut s'assurer que ceux-ci respectent aussi les normes et signalent toute faille de sécurité », précise Oli Venn. « Les exigences SBOM sont plus raisonnables que contraignantes, ajoute de son côté Nigel Douglas, responsable des relations avec les développeurs chez Cloudsmith. Avez-vous par exemple de la visibilité sur les noms et les identifiants des packages logiciels qui vous permettent de vérifier si la version présente dans votre supply chain logicielle et si le code source utilisé et payé par les utilisateurs contient du code potentiellement malveillant susceptible de les affecter ? L'essentiel est de prouver sa capacité à réagir rapidement en cas d'incident. »

Contribution à l'open source imposée sur les vulnérabilités identifiées

Pour les logiciels libres, le texte implique également d'évaluer les projets dont une organisation dépend. « Le CRA exige des organisations qu'elles connaissent et comprennent l'état des projets open source qu'elles utilisent, et prennent ainsi des décisions éclairées et pertinentes les concernant », souligne Kat Cosgrove, membre du steering committee de Kubernetes. Les entreprises qui découvrent et corrigent des vulnérabilités dans des projets open source seront par ailleurs tenues de contribuer à leur intégration en amont, complète Oli Venn. « Elles ne peuvent plus se contenter d'être de simples consommatrices de ces technologies, affirme-t-il. Si elles veulent les utiliser, elles doivent faire partie de la communauté. »

Contrairement aux réglementations traditionnelles en matière de cybersécurité, « le CRA ne se concentre ni sur le développement logiciel ni sur les certifications, qui pourraient ne pas correspondre aux nouvelles exigences, mais sur le produit vendu », souligne Daniel Ehrenberg. « Avez-vous conçu un produit qui minimise la quantité de données traitées afin de réduire les risques liés à une mauvaise gestion de ces données ? Protégez-vous les données lorsqu'elles sont exposées à des risques et lors de leur transfert ? » Les DSI doivent adopter une approche globale des produits vendus par leur entreprise, en s'intéressant à leur conformité aux exigences de sécurité plutôt qu'à une simple conformité technique. « Il s'agit d'un changement de responsabilité, insiste l'ingénieur en normalisation. Vous êtes responsable du produit final, et non plus seulement de la bonne exécution des étapes amont. »

Le support et les mises à jour également concernés

Les exigences du règlement concernent également le support produit, les mises à jour et les cycles de vie, dans la plupart des cas avec un minimum de cinq ans de mises à jour de sécurité gratuites, le tout figurant dans une déclaration de conformité que les produits numériques devront respecter à partir de décembre 2027. La déclaration et la documentation devront rester disponibles pendant 10 ans après la mise en vente du produit. La SBOM n'a pas besoin d'être publique, mais doit simplement être accessible aux autorités de surveillance du marché lorsqu'elles en font la demande.

Les différents types de produits numérique font l'objet de différents niveaux de contrôle. La plupart sont soumis à une réglementation par défaut, conformément aux normes horizontales de cybersécurité et de gestion des vulnérabilités, déjà disponibles sous forme de draft auprès des organismes européens de normalisation. Mais des produits importants comme les systèmes de gestion d'identité, les navigateurs Web, les gestionnaires de mots de passe, les VPN et les routeurs d'accès Internet, ainsi que les produits critiques comme les hyperviseurs, l'infrastructure PKI, les modules de sécurité matériels et les pare-feu industriels, nécessiteront des évaluations de conformité plus rigoureuses. Ces risques sont couverts par des normes verticales en cours d'élaboration, qui analysent des risques spécifiques et recensent des mesures d'atténuation potentielles, comme le développement d'un navigateur web avec un langage memory-safe. « Le CRA n'impose ni la migration vers ce type de langage ni l'abandon du Cobol, par exemple », précise cependant Daniel Ehrenberg.

L'opportunité pour les DSI d'obtenir des ressources cyber

Le CRA est un règlement et s'applique donc sans que les États membres de l'Union européenne aient à l'adapter. Les mécanismes nécessaires à son administration seront déployés cet été. « Les autorités de surveillance du marché alignent quant à elles leur capacité à examiner et approuver les dispositifs, et elles seront rapidement suivies par les organismes nationaux d'évaluation de la conformité », dit Daniel Ehrenberg. C'est l'Agence de l'Union européenne pour la cybersécurité (Enisa) qui gérera la plateforme unique de signalement des vulnérabilités et incidents exploités. Bien que le CRA soit pleinement applicable progressivement à partir du 11 décembre 2027, sa mise en oeuvre dépendra des capacités techniques des autorités de surveillance du marché. Celles-ci pourront exiger la mise en conformité des produits, en restreindre la vente, les retirer du marché, voire les rappeler, et infliger des amendes pouvant atteindre 15 millions d'euros ou 2,5% du chiffre d'affaires. « Il y aura probablement des batailles juridiques à l'avenir pour interpréter cette loi, estime Daniel Ehrenberg, car certains aspects ont déjà été critiqués pour leur imprécision et leur faiblesse. Mais les organisations qui s'en tiennent à une application limitée de la loi passent à côté d'une occasion d'améliorer leurs produits et leur propre sécurité. »

Face à la recrudescence des attaques ciblant la supply chain logicielle, les exigences de la CRA apporteront de réels avantages en matière de sécurité en obligeant les entreprises à suivre leur utilisation des logiciels libres et à informer rapidement les utilisateurs finaux des problèmes rencontrés, selon Neil Levine, vice-président senior des produits chez Anchore, fournisseur de solutions de cybersécurité. Il recommande d'adopter les SBOM dès septembre afin de faciliter la conformité aux obligations de déclaration, plutôt que d'attendre l'échéance de 2027. Les DSI les plus avisés devraient y voir une opportunité d'obtenir les ressources nécessaires pour mettre en oeuvre des améliorations de leurs procédures de sécurité. « La plupart des DSI souhaiteraient entreprendre ces actions, mais manquent tout simplement de temps, explique ainsi Oli Venn. Le CRA pourrait les aider à convaincre leur conseil d'administration de leur besoin de budget et de temps sur ces sujets. »