Cyber Resilience Act : intégrer les obligations au développement produit

Le règlement sur la cyberrésilience (Cyber Resilience Act, CRA) intègre des obligations de cybersécurité dans le cycle de vie des produits comportant des éléments numériques qui entrent dans son champ d’application. Pour un CTO, la tâche concrète consiste à relier ce que l’ingénierie conçoit, livre et maintient aux preuves nécessaires pour démontrer le respect de ces obligations.

Ce lien doit fonctionner au niveau du produit et de la version. Une politique de sécurité à l’échelle de l’entreprise n’explique pas si une version donnée dispose de paramètres par défaut sécurisés, quelles dépendances elle contient ni comment les clients recevront une mise à jour de sécurité. Un ticket de vulnérabilité marqué « corrigé » n’établit pas quelles versions prises en charge restent exposées.

Le point de départ utile est donc un modèle de cycle de vie du produit : champ d’application, exigences de sécurité, preuves de mise en production, gestion des vulnérabilités, engagements de support et décisions assumées par des responsables identifiés. Intégrez ce modèle au développement plutôt que de l’assembler séparément avant une évaluation.

Définir le périmètre du produit avant d’attribuer des mesures

Le CRA concerne les produits comportant des éléments numériques qui entrent dans son champ d’application, y compris les matériels et logiciels couverts. Ce n’est pas une règle universelle applicable à tout service SaaS. Un service hébergé et un logiciel distribué aux clients peuvent nécessiter des analyses différentes, et le traitement de données à distance faisant partie intégrante d’un produit doit également être examiné.

Utilisez les orientations de la Commission européenne sur le CRA comme référence de départ, puis tranchez les questions juridiques propres au produit. Consignez la conclusion plutôt que de vous fier à une hypothèse informelle de l’équipe.

Pour chaque produit candidat, établissez :

• Ce que reçoivent les clients : du matériel, un logiciel installé, des composants téléchargeables ou une combinaison de ces éléments.
• Quelles fonctions de traitement à distance sont nécessaires pour que le produit remplisse ses fonctions.
• Comment le produit est fourni sur le marché de l’UE et quelle entité le fournit.
• Votre rôle d’opérateur économique : fabricant, importateur, distributeur ou autre rôle pertinent.
• Les exclusions applicables, la législation spécifique au produit et les considérations relatives à l’open source.
• La catégorie du produit et les exigences d’évaluation de la conformité qui en découlent.

L’open source exige une attention particulière. Le régime applicable aux logiciels fournis en dehors d’une activité commerciale ne signifie pas qu’un fabricant commercial peut ignorer les composants open source intégrés à son produit. Distinguez la situation du contributeur en amont de votre responsabilité pour le produit que vous fournissez.

Le livrable d’ingénierie doit être un bref enregistrement du périmètre comprenant un schéma d’architecture, les identifiants du produit, les entités commerciales concernées, les hypothèses et une conclusion approuvée. Désignez la personne chargée de rouvrir cette conclusion lorsque les fonctionnalités ou la distribution changent.

Par exemple, une application de gestion téléchargeable et son service d’analytique hébergé ne doivent pas automatiquement faire l’objet d’une seule décision de périmètre indifférenciée. Identifiez les fonctions qui s’exécutent localement, celles qui dépendent du service et si ce traitement à distance relève du périmètre du produit. Cette distinction a des effets sur l’appréciation des risques, les enregistrements de dépendances et la responsabilité en cas d’incident.

Partir des dates d’application actuelles

La Commission retient le 11 septembre 2026 pour les obligations de notification et le 11 décembre 2027 pour les principales exigences du CRA. Au 7 octobre 2026, la date applicable aux notifications est déjà passée. Traitez la préparation aux notifications comme une exigence opérationnelle actuelle, et non comme une tâche reportée à la préparation de la conformité.

Gardez deux chantiers bien visibles :

Les produits fournis avant la date principale d’application exigent une attention particulière aux dispositions transitoires et aux modifications substantielles. Ne supposez pas qu’un produit plus ancien est sans intérêt pour les notifications au seul motif que sa première mise sur le marché est antérieure à décembre 2027.

Tenez un registre daté des exigences légales. Pour les seuils de déclenchement, les délais de notification par étapes, les destinataires et les procédures de transmission, vérifiez le texte juridique en vigueur et les orientations officielles de mise en œuvre. Ne remplacez pas le processus propre au CRA par un modèle générique de réponse aux incidents.

Transformer les exigences de sécurité en critères de conception et de mise en production

Les exigences essentielles du CRA couvrent les propriétés de sécurité des produits et la gestion des vulnérabilités. Leur mise en œuvre doit découler de l’évaluation des risques de cybersécurité du produit, plutôt que d’une liste de contrôle universelle appliquée sans contexte architectural.

Commencez par la manière dont le produit peut causer un préjudice. Décrivez les utilisateurs, les environnements de déploiement, les interfaces exposées, les opérations privilégiées, les données sensibles et les usages abusifs prévisibles. Incluez les hypothèses d’exploitation du client : un équipement déployé sur un réseau industriel présente une exposition et des contraintes de restauration différentes de celles d’un utilitaire de bureau.

Un exercice pratique de modélisation des menaces peut soutenir ce travail ; les recommandations de l’OWASP sur la modélisation des menaces proposent une approche éprouvée. Le résultat doit relier les menaces à des exigences, à des décisions de mise en œuvre et à des tests précis.

Voici comment des exigences familières deviennent testables :

Il s’agit d’exemples pratiques de mise en œuvre, et non d’un substitut aux exigences applicables. Déterminez leur pertinence et leur suffisance au moyen de l’évaluation des risques.

Ajoutez des critères d’acceptation de sécurité aux développements de fonctionnalités. Une nouvelle API d’administration doit arriver avec des décisions sur l’authentification, l’autorisation, le traitement des entrées et la journalisation, et non avec la promesse que l’équipe sécurité l’examinera plus tard. Revoyez le modèle de menace lors de l’ajout d’une interface distante, d’un composant privilégié ou d’une nouvelle frontière de confiance.

L’approbation de mise en production doit identifier les vulnérabilités non résolues, leur exploitabilité, les configurations concernées et leur traitement. Appliquez l’exigence du CRA selon laquelle les produits sont mis à disposition sur le marché sans vulnérabilités exploitables connues, en tenant compte de l’évaluation des risques et des exigences essentielles applicables ; consigner ou accepter un risque ne suffit pas en soi à satisfaire cette exigence. Un résultat de scanner ne peut à lui seul trancher : l’atteignabilité, les prérequis et le comportement du produit comptent. À l’inverse, un faible score numérique de gravité ne justifie pas d’écarter une vulnérabilité lourde de conséquences dans votre modèle de déploiement.

L’enregistrement de mise en production doit relier la révision source approuvée, l’artefact de build, l’inventaire des dépendances, les résultats des tests et la décision de sécurité. L’évaluation devient ainsi reproductible lorsqu’un client ou une autorité pose ultérieurement une question sur une version précise.

Intégrer la vigilance sur les composants au processus de build

Les composants tiers créent des obligations dont on ne s’acquitte pas en transférant un avis de sécurité émis en amont. Vous devez savoir ce que vous avez livré, si ce composant est affecté et comment vous pouvez y remédier.

Le CRA prévoit, parmi ses exigences de gestion des vulnérabilités, une nomenclature logicielle (SBOM) dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de premier niveau. À titre de recommandation pratique, recueillez des informations plus approfondies sur les dépendances chaque fois que vos outils de build peuvent produire des résultats fiables. Les dépendances transitives déterminent souvent l’exposition.

Une SBOM n’est utile que si elle correspond à un artefact réel du produit. Associez-la à l’identifiant de version et au build, et distinguez les composants livrés des outils réservés au développement. Incluez, le cas échéant, le micrologiciel, les paquets du système d’exploitation, les bibliothèques embarquées et les composants commerciaux ; un export du gestionnaire de paquets peut en omettre plusieurs.

Construisez la revue des composants autour de questions qui modifient les décisions d’ingénierie :

• Le composant est-il maintenu, et sa durée de support est-elle compatible avec la nôtre ?
• Pouvons-nous obtenir rapidement les informations sur les vulnérabilités et les mises à jour de sécurité ?
• Disposons-nous d’un accès au code source, d’un canal de correctifs du fournisseur ou d’une stratégie de remplacement ?
• Le composant introduit-il une exécution privilégiée ou une nouvelle connexion externe ?
• Le produit peut-il encore être maintenu si le fournisseur cesse de prendre en charge le composant ?

Pour les composants commerciaux, les achats doivent établir les contacts de sécurité, les modalités de notification et l’accès aux correctifs. Les délais du fournisseur doivent laisser le temps nécessaire à votre propre évaluation et à vos obligations de notification. Le fabricant du produit a toujours besoin d’une voie d’escalade interne lorsque la réponse d’un fournisseur est incomplète.

Pour les dépendances open source, conservez la provenance et un plan de maintenance réaliste. Qu’un dépôt soit accessible publiquement ne prouve pas que quelqu’un produira un correctif compatible pendant votre période de support.

Concevoir ensemble la période de support et le mécanisme de mise à jour

Le support est un engagement d’ingénierie aux conséquences commerciales. Le CRA exige en général une période de support d’au moins cinq ans, sauf si la durée d’utilisation prévue du produit est plus courte. Déterminez la période applicable selon les critères du règlement plutôt que de choisir une date arbitraire adaptée à la feuille de route.

Consignez la justification, communiquez aux clients les informations de support requises et rattachez-les aux versions maintenues du produit. L’engagement de support doit tenir compte de la capacité à fournir des mises à jour de sécurité, et pas seulement du maintien d’une adresse d’assistance.

Avant d’approuver le plan de support d’un produit, demandez-vous si vous êtes en mesure de :

• Reconstruire les anciennes branches prises en charge avec des chaînes d’outils maintenues.
• Produire, authentifier et distribuer les mises à jour de sécurité de manière sécurisée.
• Tester les correctifs sur l’ensemble des matériels et configurations de déploiement pris en charge.
• Gérer les clés de signature et vous rétablir en toute sécurité après une compromission de clé.
• Maintenir disponibles les informations de mise à jour et de sécurité destinées aux clients.
• Gérer les dépendances dont le support en amont prend fin avant le vôtre.

Les mises à jour de sécurité doivent en principe être fournies gratuitement pendant la période de support, sous réserve des dispositions du règlement. Chaque mise à jour de sécurité publiée pendant cette période doit rester disponible au moins dix ans après sa publication ou pendant le reste de la période de support, la durée la plus longue étant retenue. Planifiez les correctifs de sécurité séparément du développement des fonctionnalités afin que les clients ne soient pas inutilement contraints d’accepter des changements fonctionnels sans rapport.

Testez davantage que le scénario nominal. Une installation interrompue, un espace de stockage insuffisant, des identifiants expirés ou un échec de vérification peuvent transformer un correctif valide en problème de disponibilité. Déterminez les mécanismes de récupération nécessaires au profil de risque du produit.

En fin de support, la communication aux clients et les enregistrements internes doivent concorder. Ne laissez pas une page de téléchargement suggérer une maintenance de sécurité continue alors que le registre des produits indique que l’engagement a pris fin.

Construire une procédure de notification qui résiste à l’incertitude

Une vulnérabilité ordinaire, une vulnérabilité activement exploitée et un incident de sécurité grave ne sont pas interchangeables. Le processus de notification du CRA exige une évaluation documentée du déclencheur pertinent : ni notification automatique de chaque alerte de scanner, ni rejet automatique de tout événement faute d’investigation forensique achevée.

La procédure doit commencer par la réception des signalements. Les chercheurs, le support client, les fournisseurs et les équipes d’ingénierie ont besoin d’un canal connu vers la fonction chargée de la sécurité des produits. Conservez le signalement d’origine et consignez le moment où les informations pertinentes ont été connues ; ne réinitialisez pas les horodatages de prise de connaissance lorsqu’un ticket change d’équipe.

Pour les événements potentiellement à notifier, recueillez :

• Les identifiants du produit et les versions prises en charge concernées.
• Les éléments attestant l’exploitation ou l’impact de l’incident, avec le degré de confiance et les incertitudes.
• Les conditions d’attaque connues, les fonctions concernées et les hypothèses de déploiement.
• Les mesures d’atténuation disponibles et l’état des mesures correctives.
• L’évaluation du déclencheur, le responsable de la notification et le calcul des délais applicables.
• Les notifications transmises, les accusés de réception, les mises à jour ultérieures et les communications aux clients.

Vérifiez auprès des sources officielles les délais de notification par étapes, les exigences relatives au rapport final, les destinataires et la procédure de notification en vigueur. Les vulnérabilités activement exploitées et les incidents graves obéissent à des modalités de notification distinctes ; un seul champ d’échéance recopié ne suffit pas.

Désignez un responsable principal de la notification et un suppléant habilités à coordonner l’ingénierie, le juridique et la communication aux clients. Organisez à l’avance l’accès au mécanisme de notification applicable. La revue juridique doit être disponible dans le délai de notification plutôt que de devenir une file d’approbation sans limite.

Exercez le processus avec des informations incomplètes. Une répétition utile commence par un signalement crédible d’exploitation, une liste incertaine des versions concernées et un fournisseur de composant injoignable. L’équipe doit pouvoir prendre une décision de notification documentée et dans les délais pendant que l’investigation se poursuit.

La notification au titre du CRA ne remplace pas les autres obligations applicables. Un événement touchant un produit peut aussi exiger une évaluation au titre du droit de la protection des données ou d’un contrat client. Coordonnez ces évaluations, tout en conservant leurs déclencheurs, destinataires et décisions consignées distincts.

Confirmer la classification avant de choisir le plan d’évaluation

La classification du produit détermine les procédures d’évaluation de la conformité disponibles. Ne supposez pas que tout produit connecté nécessite la même évaluation externe, ni que tout fabricant peut s’appuyer sur une évaluation interne.

Déterminez la catégorie applicable à partir des fonctions du produit ainsi que des définitions et annexes du règlement. Confirmez ensuite la procédure autorisée, y compris les conditions éventuelles liées aux normes harmonisées, aux spécifications reconnues, aux schémas de certification ou à une évaluation par un tiers.

La planification en matière de normes exige un registre explicite des dépendances : quelles références sont applicables, leur statut actuel et ce qui change si une procédure attendue n’est pas disponible. Évitez de faire dépendre le plan de mise en production d’une hypothèse non confirmée concernant les normes ou la capacité d’évaluation.

Réexaminez la classification lorsque les fonctionnalités évoluent. L’ajout de capacités de gestion de la sécurité ou de contrôle du réseau peut modifier l’analyse, mais le nom d’une fonctionnalité ne suffit pas à établir une catégorie. Évaluez la fonction réelle et documentez la conclusion.

Gardez la classification, la procédure choisie et les livrables de conformité reliés à la documentation technique. Le marquage CE et la déclaration de conformité doivent suivre le processus applicable ; ils ne remplacent pas la mise en œuvre des exigences sous-jacentes.

Tenir un dossier de preuves capable d’expliquer une version

La documentation technique doit décrire à la fois le produit et le raisonnement qui sous-tend ses décisions de sécurité. Conservez les évaluations des risques et la documentation au fil de l’évolution du produit, et appliquez aux enregistrements concernés les durées de conservation légales.

Un dossier de preuves produit utile comprend la décision de périmètre, l’architecture, l’évaluation des risques, les exigences de sécurité, les informations sur les composants, les résultats de vérification, les procédures de gestion des vulnérabilités, la justification de la période de support et les enregistrements de conformité. Chaque élément a besoin d’un responsable et d’une version identifiable.

Utilisez des identifiants stables pour relier ces enregistrements. Un enregistrement de vulnérabilité doit expliquer les versions concernées, l’exposition, le traitement, la version corrective et la communication requise. Un « corrigé » sans contexte de version laisse le dossier de preuves du produit incomplet.

Les processus existants du SMSI peuvent fournir des preuves utiles en matière de gouvernance, de fournisseurs et de développement sécurisé. Cependant, l’ISO 27001 concerne un système de management de la sécurité de l’information au périmètre défini ; la certification n’établit pas la conformité au CRA d’un produit donné. Réutilisez les preuves pertinentes sans traiter les correspondances entre référentiels comme une équivalence juridique.

Exemple concret : une faille de dépendance dans un équipement pris en charge

Prenons l’exemple fictif d’un fabricant qui fournit dans l’UE un équipement connecté au réseau. Supposons que son périmètre et sa classification ont été examinés, que deux branches de versions restent prises en charge et qu’une bibliothèque embarquée est signalée comme activement exploitée ailleurs.

La première tâche n’est pas de clore l’avis émis en amont. L’ingénierie identifie quels builds de l’équipement contiennent la bibliothèque vulnérable et si la fonction concernée est atteignable. La SBOM indique que les deux branches la contiennent, mais l’analyse de la configuration révèle une exposition différente. Cette distinction est consignée avec les preuves correspondantes.

Le responsable de la sécurité des produits évalue ensuite si les faits disponibles remplissent le critère de déclenchement de notification applicable au titre du CRA. L’incertitude concernant une configuration de déploiement est consignée ; elle ne justifie pas de laisser le décideur non désigné. La procédure de notification fournit les étapes et la procédure de notification en vigueur.

L’ingénierie développe une mesure d’atténuation temporaire et un build corrigé pour chaque branche concernée. Les tests couvrent le chemin vulnérable, le fonctionnement normal et l’installation authentifiée de la mise à jour. Si une branche ne peut pas utiliser le correctif amont, l’équipe consigne son traitement alternatif et le risque résiduel plutôt que de marquer l’ensemble du produit comme corrigé.

La communication aux clients indique les versions concernées, les mesures de protection immédiates et la manière d’obtenir la mise à jour. Le calendrier de divulgation est coordonné avec les exigences applicables en matière de gestion des vulnérabilités et toute considération de sécurité justifiée.

L’enregistrement finalisé relie l’avis, l’analyse des builds concernés, la décision de notification, les notifications transmises le cas échéant, les commits de correctif, les résultats des tests, les artefacts de version et les communications. Un évaluateur peut désormais reconstituer à la fois la réponse technique et la décision de conformité.

Commencer par un produit et une chaîne de preuves complète

Choisissez un produit représentatif pris en charge et suivez une version récente ainsi qu’une vulnérabilité tout au long du cycle de vie. Les liens de version manquants, les engagements de support flous et les procédures de notification inaccessibles apparaîtront rapidement. Transformez chaque lacune en tâche attribuée à un responsable, puis étendez le modèle à l’ensemble du portefeuille.

Secani peut soutenir ce processus de gestion des preuves en reliant les exigences, les preuves, les responsables, les tâches et les décisions de revue. Les outils d’ingénierie restent les sources opérationnelles pour les builds, les versions et les vulnérabilités ; l’espace de travail de conformité relie ces enregistrements à l’obligation applicable. Maintenez une approbation humaine explicite pour les correspondances et les conclusions, et préservez la traçabilité des sources lorsque vous utilisez des brouillons assistés par l’IA.

La prochaine étape immédiate consiste à tester la procédure de notification. En parallèle, exigez que la prochaine version du produit soit accompagnée d’une décision de périmètre liée, d’une évaluation des risques à jour, d’un inventaire des composants et d’une approbation de sécurité. Vous créez ainsi une pratique d’ingénierie reproductible pendant que la préparation de la conformité progresse.