Gestion des vulnérabilités CRA 2026 : guide et checklist

L’essentiel. Le Cyber Resilience Act (règlement (UE) 2024/2847) impose aux fabricants de produits comportant des éléments numériques un processus structuré de gestion des vulnérabilités couvrant tout le cycle de vie du produit (annexe I, partie II). Concrètement, il faut : établir un SBOM, surveiller en continu les vulnérabilités connues, offrir un point de contact aux chercheurs, corriger sans délai via des mises à jour gratuites, publier des avis de sécurité et coordonner la divulgation. Les obligations de signalement s’appliquent à partir du 11 septembre 2026 ; l’ensemble des exigences à partir du 11 décembre 2027. Ci-dessous : les 7 étapes pour construire le programme, une checklist et les SLA de correction recommandés.

Le Cyber Resilience Act (règlement (UE) 2024/2847) ne se contente pas d’imposer un niveau minimum de sécurité au moment de la mise sur le marché. Son annexe I, partie II, exige des fabricants qu’ils mettent en place un processus structuré de gestion des vulnérabilités couvrant l’intégralité du cycle de vie du produit. C’est sans doute l’une des obligations les plus exigeantes du texte sur le plan opérationnel : elle suppose de bâtir un programme complet, depuis l’identification des failles jusqu’à leur correction et leur divulgation coordonnée.

Voici comment construire, étape par étape, un programme de gestion des vulnérabilités conforme au CRA — et comment le documenter pour en faire un dossier de conformité opposable en cas de contrôle.

Qui est concerné et à partir de quand ?

Le CRA vise les produits comportant des éléments numériques (matériels et logiciels) mis sur le marché de l’Union. Les obligations ne pèsent pas uniformément sur tous les acteurs de la chaîne.

Acteur	Obligations principales en matière de vulnérabilités
Fabricant	Construire et opérer le processus complet (SBOM, correction, divulgation, signalement)
Importateur	Vérifier que le fabricant respecte ses obligations ; relayer les vulnérabilités
Distributeur	Agir avec diligence ; coopérer et transmettre l’information sur les vulnérabilités

Les importateurs et distributeurs ont un rôle de vigilance et de relais, mais c’est bien le fabricant qui porte le cœur du dispositif.

Le calendrier d’application est échelonné. Les obligations de signalement des vulnérabilités activement exploitées et des incidents graves s’appliquent à partir du 11 septembre 2026. L’ensemble des exigences du règlement, y compris le processus complet de gestion des vulnérabilités et les exigences essentielles de cybersécurité, devient applicable à partir du 11 décembre 2027. Les équipes qui structurent leur programme dès maintenant disposeront d’un avantage déterminant.

Ce que l’annexe I impose concrètement

L’annexe I, partie II du CRA énumère les exigences en matière de traitement des vulnérabilités. Le fabricant doit notamment :

• identifier et documenter les vulnérabilités et les composants du produit, y compris en établissant un SBOM (Software Bill of Materials) ;
• traiter et corriger les vulnérabilités sans délai, y compris par la fourniture de mises à jour de sécurité ;
• appliquer des tests de sécurité réguliers et efficaces au produit ;
• divulguer publiquement les informations relatives aux vulnérabilités corrigées : description, identification du produit concerné, impacts ;
• mettre en place une politique de divulgation coordonnée des vulnérabilités ;
• faciliter le partage d’informations sur les vulnérabilités, notamment via un mécanisme de contact permettant aux chercheurs en sécurité de signaler des failles.

Ces exigences dessinent un programme complet. Voyons comment le structurer en pratique, en sept étapes.

Étape 1 : Établir le SBOM comme socle du programme

Tout programme de gestion des vulnérabilités repose sur une question préalable : de quoi est composé votre produit ? Impossible de gérer des vulnérabilités dans des composants dont on ignore l’existence.

Le SBOM constitue la fondation du dispositif. Il doit recenser l’ensemble des composants logiciels — bibliothèques tierces, frameworks, dépendances directes et transitives — avec, pour chacun : le nom, la version exacte, le fournisseur, la licence et un identifiant unique (CPE ou Package URL).

En pratique, la génération du SBOM doit être automatisée et intégrée au pipeline de build. Des outils comme Syft, Trivy ou CycloneDX CLI génèrent un SBOM à chaque compilation, au format CycloneDX ou SPDX (selon la documentation de ces outils consultée en juillet 2026). Le SBOM n’est pas un document statique : il doit être régénéré à chaque nouvelle version et conservé pour assurer la traçabilité.

Étape 2 : Structurer l’identification et le triage

Une fois le SBOM en place, il faut mettre en œuvre un processus continu d’identification des vulnérabilités. Il comporte trois volets.

Surveillance proactive des vulnérabilités connues

L’équipe sécurité doit surveiller en permanence les bases publiques de vulnérabilités — principalement la base CVE (Common Vulnerabilities and Exposures) gérée par le MITRE et la NVD (National Vulnerability Database) du NIST — pour détecter toute nouvelle vulnérabilité affectant un composant présent dans le SBOM.

Cette surveillance doit être automatisée. Des outils comme Dependency-Track, Grype ou Snyk permettent de croiser automatiquement le SBOM avec les bases CVE — une démarche que l’ANSSI recommande dans ses guides de bonnes pratiques — et de générer des alertes en temps réel.

Réception des signalements externes

Le CRA exige que le fabricant fournisse un mécanisme de contact permettant aux chercheurs, utilisateurs et tiers de signaler des vulnérabilités. Concrètement :

• une adresse de contact dédiée (de type security@votreentreprise.com) ;
• un fichier security.txt conforme à la RFC 9116, placé à la racine du site web ;
• un processus de réception et d’accusé de réception dans un délai raisonnable.

Triage et évaluation de la sévérité

Chaque vulnérabilité identifiée — issue de la surveillance automatisée ou d’un signalement externe — doit faire l’objet d’un triage structuré. Le standard de référence est le CVSS (Common Vulnerability Scoring System), en version 4.0. Cette approche rejoint les exigences de la directive NIS2 en matière de gestion des vulnérabilités.

Le triage détermine :

• la sévérité technique (score CVSS) ;
• l’exploitabilité dans le contexte spécifique du produit ;
• l’impact potentiel sur les utilisateurs ;
• la priorité de remédiation.

Toutes les vulnérabilités ne se valent pas. Une faille critique (CVSS ≥ 9,0) activement exploitée dans un composant directement exposé n’appelle pas la même réponse qu’une vulnérabilité basse dans une dépendance transitive non accessible depuis le réseau.

Étape 3 : Remédiation et déploiement des correctifs

Le CRA impose que les vulnérabilités soient corrigées sans délai (without undue delay). Le programme doit définir des SLA internes de remédiation en fonction de la sévérité.

Sévérité (CVSS)	Délai de remédiation recommandé
Critique (9,0-10,0)	7 jours
Haute (7,0-8,9)	30 jours
Moyenne (4,0-6,9)	90 jours
Basse (0,1-3,9)	Prochaine version planifiée

Ces délais sont des cibles internes indicatives : le CRA n’impose pas de chiffres précis mais exige une correction sans délai indu, à apprécier au regard de la sévérité et de l’exploitation.

Pour les vulnérabilités affectant des composants tiers, la situation est plus complexe. Si le correctif dépend d’un fournisseur ou d’un projet open source, le fabricant doit néanmoins évaluer s’il peut appliquer des mesures d’atténuation en attendant le correctif officiel. Le fait qu’un composant tiers soit en cause n’exonère pas le fabricant. Les importateurs et distributeurs doivent quant à eux relayer l’information et coopérer à la diffusion des correctifs.

Les mises à jour de sécurité doivent être gratuites pour les utilisateurs et, lorsque c’est techniquement possible, déployées automatiquement. Le CRA est explicite sur ce point.

Étape 4 : Mettre en place la divulgation coordonnée

La politique de divulgation coordonnée des vulnérabilités (Coordinated Vulnerability Disclosure — CVD) est une obligation explicite du CRA. Elle doit définir :

• le processus de réception et de traitement des signalements (voir étape 2) ;
• les délais de traitement et de communication avec le chercheur ;
• les conditions de publication de l’avis de sécurité ;
• les modalités de coordination avec les CSIRT nationaux et l’ENISA, conformément aux obligations de signalement du CRA.

Le format recommandé pour les avis de sécurité est le CSAF (Common Security Advisory Framework), qui permet une exploitation automatisée par les outils de gestion des vulnérabilités. Le format VEX (Vulnerability Exploitability eXchange), profil de CSAF, indique en complément si une vulnérabilité connue affecte effectivement le produit dans une version donnée — une information précieuse pour les clients.

Étape 5 : Intégrer les tests de sécurité au cycle de développement

L’annexe I exige des tests de sécurité réguliers et efficaces. En pratique, cela suppose d’intégrer plusieurs types de tests au pipeline CI/CD.

Analyse statique du code (SAST). SonarQube, Semgrep ou CodeQL sont exécutés automatiquement à chaque pull request, pour détecter les patterns vulnérables avant qu’ils n’atteignent la branche principale.

Analyse de composition logicielle (SCA). Elle exploite directement le SBOM pour vérifier que les dépendances ne contiennent pas de vulnérabilités connues, et bloque le build en cas de faille critique non résolue.

Tests dynamiques et fuzzing. Le fuzzing soumet l’application à des entrées aléatoires ou malformées pour détecter crashes et failles. AFL++, libFuzzer ou Jazzer automatisent cette approche. Le CRA ne prescrit pas de technique, mais le fuzzing est considéré comme une bonne pratique.

Tests d’intrusion. Conduits périodiquement — au minimum avant chaque version majeure — par des auditeurs qualifiés internes ou externes, ils valident l’efficacité des mesures en conditions réelles.

Revue de code sécurité. Pour les composants critiques, une revue manuelle orientée sécurité reste indispensable pour détecter des vulnérabilités logiques que les outils automatisés ne voient pas.

Étape 6 : Surveiller en continu les composants tiers

La gestion des vulnérabilités ne s’arrête pas au déploiement. Le CRA impose un suivi pendant toute la durée de support du produit, qui doit être d’au minimum cinq ans (sauf si la durée de vie attendue du produit est inférieure).

Concrètement, l’équipe doit :

• maintenir à jour le SBOM pour chaque version supportée ;
• surveiller quotidiennement les flux de vulnérabilités (CVE, avis des fournisseurs, alertes CERT) pour chaque composant ;
• évaluer l’impact de chaque nouvelle vulnérabilité sur les versions supportées ;
• déclencher la remédiation lorsque nécessaire.

Un outil comme Dependency-Track centralise cette surveillance pour l’ensemble des produits et versions.

Étape 7 : Documenter et conserver les preuves

Le CRA exige la conservation de la documentation technique pendant dix ans après la mise sur le marché (ou la durée de support si elle est plus longue). La documentation à conserver comprend :

• le SBOM de chaque version mise sur le marché ;
• le registre de toutes les vulnérabilités identifiées, avec pour chacune : date d’identification, score de sévérité, mesures de remédiation et dates correspondantes ;
• les rapports de tests de sécurité (SAST, SCA, fuzzing, tests d’intrusion) ;
• les avis de sécurité publiés ;
• les échanges relatifs aux signalements reçus et traités ;
• les preuves de notification aux autorités, conformément aux obligations de signalement.

Cette documentation constitue votre dossier de conformité. En cas de contrôle par une autorité de surveillance du marché, c’est sur cette base que sera évaluée la conformité de votre processus.

Lorsque le produit traite des données personnelles, une vulnérabilité exploitée peut aussi constituer une violation au sens du RGPD, déclenchant la notification à la CNIL sous 72 heures. Les deux régimes se recouvrent partiellement : un logiciel RGPD permet d’industrialiser la documentation de conformité et le registre des violations, en articulant le volet produit (CRA) et le volet données personnelles.

Checklist de conformité

À passer en revue pour vérifier la maturité de votre programme :

• [ ] SBOM généré automatiquement à chaque build, au format CycloneDX ou SPDX
• [ ] Surveillance CVE/NVD automatisée croisée avec le SBOM
• [ ] Point de contact sécurité + security.txt (RFC 9116) en ligne
• [ ] Politique de divulgation coordonnée publiée
• [ ] SLA de remédiation définis par niveau de sévérité (CVSS 4.0)
• [ ] Mises à jour de sécurité gratuites, automatiques si possible
• [ ] Tests intégrés au CI/CD (SAST, SCA, fuzzing, pentest)
• [ ] Avis de sécurité publiés au format CSAF/VEX
• [ ] Suivi des composants tiers sur toute la durée de support (≥ 5 ans)
• [ ] Documentation conservée 10 ans (registre, rapports, notifications)
• [ ] Procédure de signalement aux CSIRT/ENISA opérationnelle (dès sept. 2026)

Synthèse : le programme en un schéma

SBOM (fondation)
|
|-- Identification continue
|   |-- Surveillance CVE automatisée (Dependency-Track, Grype)
|   |-- Réception signalements externes (security.txt, email)
|   |-- Détection par tests (SAST, SCA, fuzzing, pentest)
|
|-- Triage (CVSS 4.0)
|   |-- Évaluation sévérité + exploitabilité
|   |-- Priorisation
|
|-- Remédiation
|   |-- Correction code / mise à jour composant
|   |-- Déploiement mise à jour de sécurité (gratuite)
|   |-- Mesures d'atténuation si correctif indisponible
|
|-- Divulgation coordonnée
|   |-- Notification CSIRT + ENISA (si exploitation active)
|   |-- Publication avis de sécurité (CSAF/VEX)
|   |-- Communication utilisateurs
|
|-- Documentation
    |-- Registre des vulnérabilités
    |-- Rapports de tests
    |-- Conservation 10 ans

La gestion des vulnérabilités conforme au CRA n’est pas un exercice ponctuel : c’est un processus continu, intégré au cycle de vie du produit, qui mobilise des outils, des compétences et une organisation dédiée. Un audit RGPD et une revue de sécurité produit menés en parallèle permettent d’aligner les deux régimes plutôt que de les traiter en silos.

FAQ

À partir de quand le CRA impose-t-il la gestion des vulnérabilités ?

Le calendrier est échelonné : les obligations de signalement des vulnérabilités activement exploitées et des incidents graves s’appliquent à partir du 11 septembre 2026 ; l’ensemble des exigences, dont le processus complet de gestion des vulnérabilités, à partir du 11 décembre 2027. Structurer le programme dès 2026 évite de tout devoir mettre en place dans l’urgence.

Le CRA impose-t-il un délai précis de correction des vulnérabilités ?

Non. Le règlement exige une correction « sans délai indu », à apprécier selon la sévérité et l’exploitation de la faille. Il est recommandé de définir des SLA internes indicatifs (par exemple 7 jours pour une faille critique, 30 jours pour une faille haute) afin de rendre l’obligation opérationnelle et auditable.

Qu’est-ce qu’un SBOM et pourquoi est-il obligatoire ?

Le SBOM (Software Bill of Materials) est l’inventaire exhaustif des composants logiciels d’un produit. Il est la fondation de la gestion des vulnérabilités : sans lui, impossible de savoir quels composants sont affectés par une nouvelle CVE. Le CRA impose de l’établir et de le tenir à jour ; en pratique, il doit être généré automatiquement à chaque build.

Le fabricant est-il responsable des vulnérabilités des composants open source qu’il intègre ?

Oui. Le fait qu’une vulnérabilité provienne d’un composant tiers ou open source n’exonère pas le fabricant. Il doit surveiller ces composants, évaluer l’impact des failles et appliquer des correctifs ou des mesures d’atténuation, même lorsque le correctif dépend d’un tiers.

Combien de temps faut-il conserver la documentation ?

La documentation technique doit être conservée dix ans après la mise sur le marché (ou la durée de support si elle est plus longue). Le suivi des vulnérabilités, lui, doit couvrir toute la durée de support, d’au minimum cinq ans. Ces documents constituent le dossier de conformité examiné en cas de contrôle.

Comment le CRA s’articule-t-il avec NIS2 et le RGPD ?

Les trois régimes se recoupent. La directive NIS2 impose une gestion des vulnérabilités et une notification d’incidents au niveau de l’organisation ; le CRA la porte au niveau du produit ; le RGPD s’active lorsque des données personnelles sont compromises, déclenchant la notification de violation à la CNIL. Un programme bien conçu traite ces obligations de manière intégrée plutôt qu’en silos.