Introduction
Le Cyber Resilience Act marque un tournant important dans la régulation européenne de la cybersécurité. Jusqu’ici, les organisations abordaient souvent la sécurité des produits numériques comme un sujet technique, traité par les équipes de développement, les équipes infrastructures ou les RSSI. Avec le CRA, cette approche devient insuffisante.
Le règlement européen introduit une logique plus structurante : les produits numériques devront être conçus, développés, mis sur le marché et maintenus avec un niveau de cybersécurité démontrable. Autrement dit, la sécurité ne pourra plus être ajoutée en fin de projet, après les tests fonctionnels ou au moment de l’audit. Elle devra être intégrée dès les premières phases du cycle de vie logiciel.
Le CRA ne concerne pas uniquement les éditeurs logiciels ou les fabricants d’objets connectés. Il concerne aussi les responsables sécurité, les directions techniques, les RSSI, les équipes produit, les responsables conformité, les achats IT et les organisations qui sélectionnent, intègrent ou exploitent des produits numériques dans des environnements critiques.
Cette évolution s’inscrit dans un mouvement réglementaire européen plus large, aux côtés du RGPD, de NIS2 et de DORA. Pour mieux comprendre cette convergence entre réglementation cyber, gouvernance et normes ISO, vous pouvez consulter notre analyse dédiée : RGPD, NIS2, DORA, CRA : comment les normes ISO structurent la conformité cyber.
Le CRA transforme la cybersécurité produit en obligation de gouvernance
Le Cyber Resilience Act introduit une rupture de logique. Il ne s’agit pas uniquement de protéger les systèmes d’information existants. Il s’agit de sécuriser les produits avec éléments numériques sur l’ensemble de leur cycle de vie : planification, conception, développement, production, livraison, maintenance et correction.
Cette évolution rapproche la cybersécurité produit des logiques déjà connues en matière de conformité, de qualité et de gestion des risques. Un produit numérique ne devra plus seulement être performant ou ergonomique. Il devra être accompagné de preuves : analyse de risques, documentation technique, processus de gestion des vulnérabilités, capacité de correction, suivi des composants et maintien de la sécurité pendant la période de support.
Pour les responsables sécurité, cela implique un changement de posture. Le sujet ne peut plus rester limité aux équipes projets ou aux équipes sécurité applicative. Il doit être porté comme un chantier de gouvernance, avec des responsabilités claires, des processus formalisés, des exigences documentées et des indicateurs suivis dans le temps.
Dans cette perspective, la gouvernance de la sécurité de l’information devient un socle essentiel. Une démarche structurée autour d’un SMSI permet de formaliser les responsabilités, les politiques, les contrôles, l’amélioration continue et la production de preuves. C’est précisément l’objectif de la formation ISO/IEC 27001 Lead Implementer, qui permet de comprendre comment mettre en place et piloter un système de management de la sécurité de l’information.
Le CRA impose ainsi une idée simple mais exigeante : la cybersécurité d’un produit ne se décrète pas au moment de sa mise en production. Elle se construit dès la conception.
Secure by design : passer d’une sécurité corrective à une sécurité intégrée
Le cœur du CRA repose sur une logique de secure by design. Cette expression est souvent utilisée, mais elle reste parfois mal comprise. Elle ne signifie pas simplement faire des tests de sécurité avant la mise en production. Elle signifie intégrer les exigences de sécurité dès l’expression du besoin, puis les maintenir à chaque étape du cycle de vie.
Dans un modèle classique, la sécurité intervient souvent trop tard. Le projet avance, les fonctionnalités sont développées, l’architecture est déjà arrêtée, les dépendances sont choisies, puis un test d’intrusion ou un audit révèle des vulnérabilités. L’organisation corrige alors dans l’urgence, parfois avec des arbitrages coûteux, car les défauts touchent à l’architecture elle-même.
Dans une logique secure by design, le raisonnement est inversé. Les risques sont identifiés dès le départ. Les exigences de sécurité sont intégrées aux spécifications. Les développeurs disposent de règles de codage sécurisé. Les composants sont analysés avant d’être intégrés. Les pipelines DevOps incluent des contrôles automatisés. Les vulnérabilités sont traitées selon une procédure formalisée. Les mises à jour sont anticipées dès la conception du produit.
Cette approche rejoint les principes du DevSecOps, qui vise à intégrer la sécurité dans les cycles de développement et de déploiement, plutôt qu’à la traiter comme une étape séparée. Pour les organisations qui souhaitent structurer cette montée en compétence, DEVFORMA propose la formation DevSecOps Foundation ainsi que la formation DevSecOps Practitioner, orientée vers l’industrialisation des contrôles de sécurité dans les pipelines.
SBOM : la transparence devient un enjeu de conformité
Le CRA renforce aussi l’importance de la transparence sur les composants logiciels. Aujourd’hui, très peu de produits numériques sont développés de bout en bout sans dépendances externes. Applications web, plateformes SaaS, logiciels embarqués, solutions IoT, outils métiers : tous reposent sur des bibliothèques, frameworks, modules open source, composants commerciaux, images conteneurisées ou services tiers.
Cette réalité crée un risque majeur : une organisation peut être exposée à une vulnérabilité critique sans même savoir qu’elle utilise le composant concerné.
C’est précisément là que le SBOM, ou Software Bill of Materials, devient stratégique. Un SBOM est un inventaire structuré des composants logiciels utilisés dans un produit. Il permet d’identifier les dépendances, les versions, les licences, les relations entre composants et les vulnérabilités potentielles.
Mais un SBOM ne suffit pas à lui seul. Il ne doit pas devenir un fichier produit une fois puis oublié dans un dossier documentaire. Sa valeur dépend de sa qualité, de sa mise à jour, de son intégration dans les processus de développement, de son exploitation par les équipes sécurité et de sa connexion avec les outils de détection de vulnérabilités.
Pour les responsables sécurité et les directions techniques, l’enjeu n’est donc pas seulement de demander un SBOM aux fournisseurs. Il est de savoir comment le lire, comment l’exploiter, comment l’intégrer dans la gestion des risques et comment l’utiliser pour prioriser les corrections. Cette logique rejoint les enjeux de résilience numérique déjà abordés dans notre article NIS2 et DORA : structurer la résilience numérique avec les normes ISO, où la maîtrise des prestataires, des dépendances et des chaînes de services devient un élément central de la conformité cyber.
Gestion des vulnérabilités : du correctif technique au processus de gouvernance
L’un des apports majeurs du CRA concerne la gestion des vulnérabilités. Le règlement impose une logique de suivi, de correction et de notification. Cette obligation dépasse largement la simple application de patchs.
Une gestion mature des vulnérabilités produit suppose plusieurs éléments : un canal de réception des signalements, une procédure de qualification, une méthode d’évaluation de la criticité, une capacité de correction, une politique de divulgation coordonnée, une communication claire vers les parties prenantes et une traçabilité des décisions.
C’est ici que des normes comme ISO/IEC 30111 et ISO/IEC 29147 deviennent utiles. Elles ne certifient pas l’entreprise comme ISO/IEC 27001 peut le faire pour un système de management de la sécurité de l’information. Elles apportent plutôt des repères structurants pour organiser la gestion et la divulgation des vulnérabilités.
ISO/IEC 30111 concerne le traitement des vulnérabilités : réception, analyse, remédiation, coordination interne et suivi. ISO/IEC 29147 concerne la divulgation : comment communiquer sur une vulnérabilité, comment interagir avec les chercheurs, comment informer les utilisateurs et comment réduire le risque d’exploitation.
Dans le contexte du CRA, ces référentiels ne doivent pas être perçus comme de simples bonnes pratiques techniques. Ils deviennent des briques de gouvernance opérationnelle.
La gestion des vulnérabilités doit également être reliée à une démarche plus globale d’analyse de risques. Identifier une vulnérabilité ne suffit pas : il faut évaluer son impact, son exploitabilité, son exposition réelle et les mesures de traitement adaptées. Pour structurer cette approche, la formation ISO/IEC 27005:2022 Risk Manager permet de maîtriser les fondamentaux de la gestion des risques liés à la sécurité de l’information. Pour les profils amenés à piloter cette démarche à un niveau avancé, la formation ISO/IEC 27005:2022 Lead Risk Manager permet d’approfondir la gouvernance du risque cyber.
ISO 27001, ISO 27005, ISO 27034 : comment relier le CRA aux cadres existants
Le CRA ne remplace pas les normes existantes. Il oblige plutôt les organisations à mieux articuler les référentiels de cybersécurité.
ISO/IEC 27001 permet de structurer la gouvernance globale de la sécurité de l’information à travers un SMSI. Elle aide à formaliser les responsabilités, les politiques, les objectifs, l’amélioration continue, l’évaluation des risques et les contrôles de sécurité.
ISO/IEC 27005 apporte une méthode pour gérer les risques liés à la sécurité de l’information. Elle permet d’identifier les scénarios de risque, d’évaluer leur vraisemblance et leur impact, puis de définir des mesures de traitement adaptées.
ISO/IEC 27034 est particulièrement pertinente pour la sécurité applicative. Elle aide les organisations à intégrer la sécurité dans les processus de gestion des applications, qu’il s’agisse d’applications développées en interne, acquises auprès de tiers ou opérées par des prestataires.
Dans une perspective CRA, ces référentiels peuvent être combinés : ISO 27001 pour la gouvernance, ISO 27005 pour le risque, ISO 27034 pour la sécurité applicative, ISO 29147 et ISO 30111 pour les vulnérabilités, IEC 62443 pour les environnements industriels et DevSecOps pour l’industrialisation opérationnelle.
L’objectif n’est pas d’accumuler les normes. L’objectif est de construire un système cohérent de preuves. Cette articulation entre textes européens et référentiels de cybersécurité est également au cœur de notre article sur EBIOS RM, NIS2, ReCyF et conformité cyber, qui montre comment les méthodes d’analyse de risques peuvent soutenir les démarches de conformité et de résilience.
DevSecOps : industrialiser la conformité dans les pipelines
Le CRA va pousser les organisations à sortir d’une conformité documentaire purement déclarative. Dans un environnement logiciel moderne, les versions évoluent rapidement, les composants changent, les dépendances se mettent à jour et les vulnérabilités apparaissent en continu.
La conformité doit donc être intégrée aux pipelines de développement. C’est précisément l’intérêt du DevSecOps : automatiser et industrialiser les contrôles de sécurité dans les cycles de développement et de déploiement.
Cela peut inclure l’analyse statique de code, l’analyse des dépendances, la détection de secrets, le scan d’images conteneurisées, les tests de configuration cloud, l’analyse des infrastructures as code, les tests dynamiques, la génération de SBOM et l’intégration des résultats dans les processus de gestion des vulnérabilités.
Le DevSecOps ne remplace pas la gouvernance. Il la rend exécutable. Il permet de transformer les exigences de sécurité en contrôles récurrents, mesurables et intégrés au flux de développement. Cette logique est particulièrement importante dans le contexte du CRA, car elle permet de rapprocher les obligations de conformité des réalités opérationnelles du développement logiciel. Les équipes ne se contentent plus de produire un dossier de sécurité en fin de projet : elles intègrent des contrôles continus dans les workflows de développement, de test et de livraison.
Ce que les organisations doivent commencer à documenter
La préparation au CRA doit commencer par une question simple : quelles preuves serions-nous capables de produire aujourd’hui si l’on nous demandait de démontrer que nos produits numériques sont conçus, développés et maintenus de manière sécurisée ? Les organisations devraient progressivement documenter plusieurs éléments :
- la cartographie des produits numériques concernés
- les responsabilités entre responsables sécurité, RSSI, métiers, achats, juridique, directions techniques et fournisseurs
- les analyses de risques produit
- les exigences de sécurité intégrées aux cahiers des charges
- les choix d’architecture sécurisée
- les règles de développement sécurisé
- la politique de gestion des composants tiers et open source
- les SBOM et leur processus de mise à jour
- les résultats des tests de sécurité
- les procédures de traitement des vulnérabilités
- les délais de correction selon la criticité
- les mécanismes de journalisation et de surveillance
- les procédures de notification en cas d’incident ou de vulnérabilité exploitée
- les engagements fournisseurs en matière de sécurité et de support.
Cette documentation ne doit pas être pensée comme une charge administrative. Elle devient une condition de pilotage. Une organisation qui ne sait pas documenter sa sécurité produit ne pourra pas démontrer sa maîtrise.
Conclusion : le CRA impose une cybersécurité démontrable
Le Cyber Resilience Act confirme une évolution de fond : la cybersécurité devient une exigence native des produits numériques. Elle ne peut plus être reléguée à la fin du projet, à l’audit final ou au correctif d’urgence.
Pour les responsables sécurité, RSSI, directions techniques, responsables conformité et équipes produit, le chantier prioritaire consiste à intégrer la cybersécurité dans tout le cycle de vie logiciel : conception, développement, intégration, achats, maintenance, gestion des vulnérabilités et documentation des preuves.
Les organisations qui anticipent cette évolution disposeront d’un avantage clair. Elles seront mieux préparées à la conformité CRA, mais aussi plus robustes face aux risques de supply chain, aux vulnérabilités logicielles, aux exigences clients et aux contrôles réglementaires.
Le CRA ne demande pas seulement de sécuriser davantage les produits numériques. Il demande de démontrer que cette sécurité est pensée, organisée, maintenue et pilotée.
DEVFORMA accompagne les organisations dans la montée en compétence de leurs équipes sur la gouvernance SSI, la gestion des risques, la sécurité applicative, les pratiques DevSecOps et la conformité cyber européenne.
