Gestion des vulnérabilités : construire un processus conforme au CRA

Le Cyber Résilience 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, exigé 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. Cette obligation est sans doute l’une des 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 aux exigences du CRA.

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 contenus dans le 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, y compris une description de la vulnérabilité, les informations permettant aux utilisateurs d’identifier le produit concerné et les impacts de la vulnérabilité ;
• mettre en place une politique de divulgation coordonnée des vulnérabilités ;
• faciliter le partagé d’informations sur les vulnérabilités, y compris en fournissant un mécanisme de contact permettant aux chercheurs en sécurité de signaler des failles.

Ces exigences dessinent un programme complet de gestion des vulnérabilités. Voyons comment le structurer en pratique.

É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 vous ignorez l’existence.

Le SBOM constitue donc la fondation du dispositif. Il doit recenser l’ensemble des composants logiciels de votre produit – bibliotheques 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 à votre pipeline de build. Des outils comme Syft, Trivy ou CycloneDX CLI permettent de générer un SBOM à chaque compilation, au format CycloneDX ou SPDX. Le SBOM n’est pas un document statique : il doit être regenere à chaque nouvelle version du produit et conservé pour assurer la traçabilité.

Étape 2 : Structurer le processus d’identification et de triage

Une fois le SBOM en place, l’étape suivante consiste à mettre en oeuvre un processus continu d’identification des vulnérabilités. Ce processus comporte trois volets.

Surveillance proactive des vulnérabilités connues

Votre équipe sécurité doit surveiller en permanence les bases de données 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 votre SBOM.

Cette surveillance doit être automatisée. Des outils comme Dependency-Track, Grype ou Snyk permettent de croiser automatiquement votre SBOM avec les bases CVE, une démarche que l’ANSSI recommandé dans ses guides de bonnes pratiques, et de générer des alertes en temps réel lorsqu’une nouvelle vulnérabilité est publiée pour l’un de vos composants.

Reception des signalements externes

Le CRA exigé que le fabricant fournisse un mécanisme de contact permettant aux chercheurs en sécurité, aux utilisateurs et aux tiers de signaler des vulnérabilités. Concrètement, cela implique de mettre en place :

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

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

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

Le triage doit permettre de déterminer :

• la sévérité technique de la vulnérabilité (score CVSS) ;
• son exploitabilité dans le contexte spécifique de votre 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 expose n’appelle pas la même réponse qu’une vulnérabilité basse dans une dépendance transitive non accessible depuis une interface réseau.

Étape 3 : Remediation et déploiement des correctifs

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

Severite (CVSS)	Délai de remédiation recommande
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 planifiee

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, vous devez néanmoins évaluer s’il est possible d’appliquer des mesures d’attenuation en attendant le correctif officiel. Le CRA vous tient pour responsable : le fait qu’un composant tiers soit en cause ne vous exonère pas. Les importateurs et distributeurs ont quant à eux l’obligation de relayer l’information au fabricant et de coopérer à la diffusion des correctifs.

Les mises à jour de sécurité doivent être gratuites pour les utilisateurs et déployées de manière automatique lorsque cela est techniquement possible. Le CRA est explicité sur ce point.

Étape 4 : Mettre en place la divulgation coordonnée des vulnérabilités

La politique de divulgation coordonnée des vulnérabilités (Coordinated Vulnerability Disclosure – CVD) est une obligation explicité du CRA. Cette politique 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 ayant signalé la vulnérabilité ;
• 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 la publication des avis de sécurité est le CSAF (Common Security Advisory Framework), qui permet une exploitation automatisée des avis par les outils de gestion des vulnérabilités. Le format VEX (Vulnerability Exploitability eXchange), qui est un profil de CSAF, permet en complément d’indiquer si une vulnérabilité connue affecte effectivement votre produit dans une version donnée – information particulièrement utile pour vos clients.

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

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

Analyse statique du code (SAST). Des outils comme SonarQube, Semgrep ou CodeQL doivent être exécutés automatiquement à chaque pull request ou merge request. L’objectif est de détecter les patterns de code vulnérables avant qu’ils n’atteignent la branche principale.

Analyse de composition logicielle (SCA). L’analyse SCA – qui exploite directement le SBOM – verifie que les dépendances utilisées ne contiennent pas de vulnérabilités connues. Elle doit bloquer le build en cas de vulnérabilité critique non résolue.

Tests dynamiques et fuzzing. Le fuzzing consiste à soumettre votre application à des entrées aleatoires ou malformees pour détecter des comportements inattendus, des crashes ou des failles de sécurité. Des outils comme AFL++, libFuzzer ou Jazzer permettent d’automatiser cette approche. Le CRA ne prescrit pas de technique spécifique, mais l’emploi du fuzzing est considéré comme une bonne pratique par les organismes de normalisation.

Tests d’intrusion (pénétration testing). Des tests d’intrusion doivent être conduits périodiquement – au minimum avant chaque version majeure – par des auditeurs internes ou externes qualifiés. Ces tests simulent le comportement d’un attaquant réel et permettent de valider l’efficacité des mesures de sécurité en conditions réelles.

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

Étape 6 : Surveiller en continu les composants tiers

La gestion des vulnérabilités ne s’arrêté 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, cela signifie que votre équipe doit :

• maintenir à jour le SBOM pour chaque version supportee du produit ;
• surveiller quotidiennement les flux de vulnérabilités (CVE, advisories des fournisseurs, alertes CERT) pour chaque composant présent dans le SBOM ;
• évaluer l’impact de chaque nouvelle vulnérabilité sur les versions supportees ;
• déclencher le processus de remédiation lorsque nécessaire.

Dependency-Track permet de gérer cette surveillance de manière centralisée pour l’ensemble de vos produits et versions.

Étape 7 : Documenter et conserver les preuves

Le CRA exigé la conservation de la documentation technique pendant dix ans après la mise sur le marché du produit. La documentation a conserver comprend :

• le SBOM de chaque version du produit mise sur le marché ;
• le registre de toutes les vulnérabilités identifiées, avec pour chacune : la date d’identification, le score de sévérité, les mesures de remédiation appliquées et les dates correspondantes ;
• les rapports de tests de sécurité (SAST, SCA, fuzzing, pénétration testing) ;
• les avis de sécurité publies ;
• les échanges relatifs aux signalements de vulnérabilités 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.

Synthèse : le programme de gestion des vulnérabilités en un schéma

SBOM (fondation)
|
|-- Identification continue
|   |-- Surveillance CVE automatisee (Dependency-Track, Grype)
|   |-- Reception signalements externes (security.txt, email)
|   |-- Détection par tests (SAST, SCA, fuzzing, pentest)
|
|-- Triage (CVSS 4.0)
|   |-- Evaluation sévérité + exploitabilité
|   |-- Priorisation
|
|-- Remediation
|   |-- Correction code / mise à jour composant
|   |-- Deploiement mise à jour sécurité (gratuite)
|   |-- Mesures d'attenuation si correctif indisponible
|
|-- Divulgation coordonnee
|   |-- Notification CSIRT + ENISA (si exploitation active)
|   |-- Publication avis sécurité (CSAF/VEX)
|   |-- Communication utilisateurs
|
|-- Documentation
    |-- Registre vulnerabilites
    |-- 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ègre au cycle de vie du produit, qui mobilise des outils, des compétences et une organisation dédiée. Les équipes qui mettent en place ce programme des maintenant – avant l’entrée en application des obligations en septembre 2026 pour le signalement et en décembre 2027 pour l’ensemble des exigences – disposeront d’un avantage déterminant.