Le CRA, un changement de paradigme pour la responsabilité logicielle

À l’horizon 2026, le paysage de la cybersécurité européenne s’apprête à connaître une transformation structurelle, orchestrée par une législation d’une portée inédite : le Cyber Resilience Act (CRA). Pour les Directeurs des Systèmes d’Information (DSI) et les Responsables de la Sécurité des Systèmes d’Information (RSSI), appréhender le CRA comme une simple case à cocher sur une longue liste de conformité serait une erreur stratégique fondamentale. Ce règlement ne se contente pas d’ajouter une couche normative ; il redéfinit les fondements même de la responsabilité associée aux produits numériques. Il opère un basculement décisif, transformant ce qui était jusqu’alors considéré comme de la « dette technique » ou une question de bonnes pratiques en une responsabilité juridique et financière directe pour les fabricants.  

Cet article propose une méthodologie concrète pour cartographier les dépendances logicielles (y compris open source), évaluer les risques et mettre en place le processus de notification de vulnérabilités exigé par le CRA. Historiquement, la présence d’une vulnérabilité dans une bibliothèque tierce ou un composant open source était un problème technique, confiné aux équipes de développement et de sécurité. Le CRA, en imposant des obligations strictes au « fabricant » — c’est-à-dire l’entité qui met un produit contenant des éléments numériques sur le marché de l’Union Européenne — transfère légalement le risque de toute la chaîne d’approvisionnement logicielle vers l’entreprise elle-même. Un audit défaillant de cette  

supply chain n’est plus une simple lacune technique ; il constitue une violation d’une obligation réglementaire, susceptible d’entraîner des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial annuel.

Cette évolution propulse le CISO et le DSI bien au-delà de leurs rôles traditionnels de conseillers techniques. Ils deviennent des acteurs centraux dans la gestion du profil de risque légal et financier de l’entreprise. Leur mission n’est plus seulement de protéger l’entreprise, mais de garantir et de prouver que les produits qu’elle conçoit et commercialise sont sécurisés « by design » et tout au long de leur cycle de vie. Cet article se veut un guide pratique, une feuille de route en trois étapes pour construire un programme de conformité au CRA qui soit non seulement efficace, mais qui se transforme en un véritable levier de résilience stratégique.

Étape 1 – Cartographie exhaustive des dépendances : La fondation de la conformité

La première étape, et sans doute la plus fondamentale, pour se conformer au CRA est d’atteindre une visibilité totale sur la composition de ses propres produits. L’adage « on ne peut pas sécuriser ce que l’on ne voit pas » n’a jamais été aussi pertinent. Le CRA exige des fabricants qu’ils connaissent et documentent chaque composant logiciel qui constitue leur produit, qu’il soit développé en interne, acquis auprès d’un fournisseur commercial ou issu de la communauté open source. Cette exigence rend la constitution d’une nomenclature logicielle, ou Software Bill of Materials (SBOM), non plus une bonne pratique, mais une obligation de fait.

La constitution d’un Software Bill of Materials (SBOM) : Outils et meilleures pratiques

Un SBOM est un inventaire formel et structuré des composants, des bibliothèques et des modules logiciels requis pour construire et exécuter une application. Il s’agit de la « liste d’ingrédients » de votre logiciel. Les formats standardisés comme SPDX (Software Package Data Exchange) et CycloneDX sont devenus la norme de l’industrie, car ils permettent une communication claire et automatisée des informations sur les dépendances entre les différents acteurs de la chaîne d’approvisionnement.

Pour les DSI, la mise en œuvre de la génération de SBOM doit être intégrée au plus près du cycle de développement (DevOps). Des outils d’analyse de la composition logicielle (Software Composition Analysis – SCA) peuvent être intégrés directement dans les pipelines d’intégration et de déploiement continus (CI/CD). Ces outils scannent automatiquement le code source, les binaires et les conteneurs pour identifier les composants et générer un SBOM à chaque nouvelle version du produit. Cette automatisation est primordiale, car elle garantit que le SBOM est une représentation vivante et à jour du logiciel, et non un document statique rapidement obsolète.

Identifier les dépendances transitives : Le risque caché

Le véritable défi de la cartographie ne réside pas dans les dépendances directes — celles que vos développeurs ont explicitement choisi d’intégrer. Le risque le plus insidieux provient des dépendances transitives, ou « dépendances de dépendances ». Une bibliothèque que vous utilisez peut elle-même dépendre de dizaines d’autres, créant une arborescence complexe et profonde de composants. Une vulnérabilité dans une dépendance de troisième ou quatrième niveau est tout aussi exploitable que dans une dépendance directe, mais elle est infiniment plus difficile à détecter sans une analyse approfondie.

L’analogie de la poupée russe est ici pertinente : chaque composant que vous ouvrez peut en contenir un autre, et ainsi de suite. Des outils de SCA avancés sont conçus pour parcourir cette arborescence complète et révéler l’ensemble de la chaîne de dépendances. Sans cette capacité d’analyse en profondeur, votre SBOM serait incomplet et votre évaluation des risques, fondamentalement erronée, vous laissant exposé à des vulnérabilités cachées et à une non-conformité au CRA.

Le cas critique de l’Open Source

La quasi-totalité des applications modernes est construite sur un socle de logiciels open source (OSS). Si l’OSS est un formidable accélérateur d’innovation, il présente des défis uniques en matière de sécurité et de conformité au CRA. Contrairement aux logiciels commerciaux, les composants OSS ne sont généralement pas accompagnés de garanties contractuelles ou d’un support technique formel. La responsabilité de leur sécurité incombe entièrement à l’organisation qui les utilise.

L’audit de la chaîne d’approvisionnement doit donc inclure une évaluation de la « santé » des projets open source utilisés. Plusieurs métriques peuvent être prises en compte : la fréquence des mises à jour et des commits, la taille et la réactivité de la communauté de développeurs, l’existence d’une politique de sécurité claire pour le projet, et la rapidité avec laquelle les vulnérabilités signalées sont corrigées. Ignorer ces facteurs revient à construire son produit sur des fondations potentiellement instables.

Étape 2 – Méthodologie d’évaluation des risques : Au-delà du score CVSS

Une fois la cartographie complète des dépendances établie, l’étape suivante consiste à évaluer les risques associés. L’approche traditionnelle, qui consiste à se fier uniquement au score de sévérité CVSS (Common Vulnerability Scoring System), est aujourd’hui largement insuffisante et inefficace. Le CRA impose une vision du risque qui va au-delà de la simple gravité technique d’une faille pour intégrer son impact métier réel. Le véritable risque d’une vulnérabilité n’est pas son score absolu, mais la combinaison de sa sévérité, de sa probabilité d’exploitation et de son contexte d’utilisation au sein de votre produit.

Priorisation des vulnérabilités : Intégrer le contexte métier

Une vulnérabilité avec un score CVSS de 9.8 dans un composant utilisé pour une tâche de fond sur un système interne non exposé à Internet représente un risque réel bien inférieur à une faille de 6.5 dans une bibliothèque de traitement des paiements directement exposée sur votre site web. Le CRA pousse les organisations à adopter des modèles de priorisation plus intelligents qui tiennent compte de ce contexte.

Deux cadres complémentaires sont particulièrement utiles à cet effet :

1. L’EPSS (Exploit Prediction Scoring System) : Ce système fournit un score de probabilité (entre 0 et 1) qu’une vulnérabilité soit exploitée dans les 30 prochains jours. En croisant le score CVSS (gravité) avec le score EPSS (probabilité), les équipes de sécurité peuvent concentrer leurs efforts sur les failles qui sont à la fois graves et activement ciblées par les attaquants.
2. Le VEX (Vulnerability Exploitability eXchange) : Un document VEX est une assertion de sécurité qui accompagne un SBOM. Il permet à un fabricant d’indiquer si un produit est réellement affecté par une vulnérabilité présente dans l’un de ses composants. Par exemple, même si une bibliothèque contient une faille, le code vulnérable peut ne pas être exécutable dans le contexte de votre application. Le VEX permet de « désactiver » les faux positifs et de concentrer les efforts de remédiation là où le risque est avéré.

La mise en place d’une matrice de risque combinant le CVSS, l’EPSS, le VEX et la criticité métier de l’actif concerné est la pierre angulaire d’une gestion des vulnérabilités mature et conforme à l’esprit du CRA.

Évaluer la posture de sécurité de vos fournisseurs

Le CRA stipule que la responsabilité du fabricant couvre l’ensemble des composants intégrés dans son produit. Il est donc impératif d’étendre l’évaluation des risques à vos fournisseurs de logiciels commerciaux. Un DSI doit mettre en place un processus de due diligence pour évaluer la maturité de ses fournisseurs en matière de sécurité.

Cette évaluation devrait prendre la forme d’un questionnaire d’audit couvrant des points essentiels :

• Le fournisseur est-il lui-même en conformité avec le CRA?
• Dispose-t-il d’un cycle de développement sécurisé (Secure Development Lifecycle – SDL) documenté?
• Fournit-il des SBOM pour ses propres produits?
• Quel est son processus de gestion et de communication des vulnérabilités (SLA de correction, canal de communication sécurisé)?

Intégrer ces exigences de sécurité dans les contrats avec les fournisseurs devient une nécessité légale et opérationnelle pour maîtriser le risque de sa chaîne d’approvisionnement de bout en bout.

Étape 3 – Mettre en place le processus de notification et de remédiation

La dernière étape consiste à opérationnaliser la gestion des vulnérabilités. Le CRA est particulièrement strict sur les obligations de réponse et de communication. Il ne suffit pas d’identifier et de prioriser les failles ; il faut être en mesure de les traiter et de communiquer de manière transparente et rapide.

Structurer votre équipe PSIRT (Product Security Incident Response Team)

Toute organisation concernée par le CRA doit mettre en place une équipe ou une fonction dédiée à la sécurité de ses produits. Cette entité, souvent appelée PSIRT (Product Security Incident Response Team), se distingue d’une équipe de réponse aux incidents de sécurité traditionnelle (CSIRT). Alors qu’un CSIRT se concentre sur la protection de l’infrastructure interne de l’entreprise, un PSIRT est tourné vers l’extérieur : il est le point de contact unique pour les chercheurs en sécurité, les clients et les partenaires qui découvrent des vulnérabilités dans les produits de l’entreprise.

Les missions d’un PSIRT incluent :

• La gestion d’un canal de signalement de vulnérabilités clair et sécurisé (Coordinated Vulnerability Disclosure – CVD).
• Le triage et l’analyse des vulnérabilités signalées.
• La coordination de la remédiation avec les équipes de développement.
• La communication externe sur les vulnérabilités et les correctifs disponibles.

Les exigences de notification de 24 heures : Se préparer à l’inévitable

L’une des dispositions les plus contraignantes du CRA est l’obligation de notifier l’ENISA (l’Agence de l’Union européenne pour la cybersécurité) dans les 24 heures suivant la prise de connaissance d’une vulnérabilité activement exploitée dans un produit. Ce délai extrêmement court ne laisse aucune place à l’improvisation.

Pour s’y préparer, les entreprises doivent impérativement :

1. Définir un plan de réponse aux incidents spécifique à ce scénario : Ce plan doit identifier clairement les rôles (qui décide? qui communique? qui valide techniquement?), les canaux de communication internes et les procédures d’escalade.
2. Préparer des modèles de communication : Avoir des modèles de notification pré-rédigés pour l’ENISA et potentiellement pour les clients permet de gagner un temps précieux en cas de crise.
3. Simuler le plan de réponse : Mener des exercices de simulation réguliers (war games) est le seul moyen de s’assurer que le plan est fonctionnel et que chaque membre de l’équipe connaît son rôle.

L’incapacité à respecter cette obligation de notification de 24 heures sera considérée comme une infraction grave au règlement.

Étape	Actions Clés	Objectif CRA
1. Cartographie	Générer des SBOM (SPDX, CycloneDX) via des outils SCA. Identifier les dépendances transitives. Évaluer la santé des projets open source.	Article 5 (Exigences de conception), Annexe I (Informations requises)
2. Évaluation des Risques	Contextualiser le score CVSS avec l’EPSS et le VEX. Auditer la posture de sécurité des fournisseurs commerciaux.	Article 10 (Gestion des vulnérabilités par les fabricants)
3. Processus de Réponse	Mettre en place un PSIRT et un processus de CVD. Simuler et opérationnaliser le plan de notification de 24 heures à l’ENISA.	Article 11 (Obligations de notification)

De l’audit ponctuel à la gouvernance continue de la sécurité logicielle

Le Cyber Resilience Act marque la fin de l’ère où la sécurité de la chaîne d’approvisionnement logicielle pouvait être traitée comme un projet ponctuel ou une simple vérification avant la mise en production. La méthodologie en trois étapes — cartographier, évaluer, et répondre — ne doit pas être vue comme un exercice unique, mais comme la fondation d’un processus de gouvernance continu et dynamique.

La conformité au CRA est, en substance, une matérialisation réglementaire des principes du DevSecOps. Elle exige d’intégrer la sécurité à chaque étape du cycle de vie du logiciel, de « décaler la sécurité vers la gauche » (shift left) en identifiant les vulnérabilités dès la phase de conception, et d’automatiser les contrôles pour suivre le rythme des développements agiles. Pour les DSI et les RSSI, l’échéance de 2026 n’est pas une ligne d’arrivée, mais le début d’une nouvelle ère où la résilience logicielle n’est plus une option, mais une obligation légale et un impératif stratégique pour opérer sur le marché européen.