Le Cyber Resilience Act (reglement (UE) 2024/2847) ne se contente pas d’imposer un niveau minimum de securite au moment de la mise sur le marche. Son annexe I, partie II, exige des fabricants qu’ils mettent en place un processus structure de gestion des vulnerabilites couvrant l’integralite du cycle de vie du produit. Cette obligation est sans doute l’une des plus exigeantes du texte sur le plan operationnel : elle suppose de batir un programme complet, depuis l’identification des failles jusqu’a leur correction et leur divulgation coordonnee.

Voici comment construire, etape par etape, un programme de gestion des vulnerabilites conforme aux exigences du CRA.

Ce que l’annexe I impose concretement

L’annexe I, partie II du CRA enumere les exigences en matiere de traitement des vulnerabilites. Le fabricant doit notamment :

• identifier et documenter les vulnerabilites et les composants contenus dans le produit, y compris en etablissant un SBOM (Software Bill of Materials) ;
• traiter et corriger les vulnerabilites sans delai, y compris par la fourniture de mises a jour de securite ;
• appliquer des tests de securite reguliers et efficaces au produit ;
• divulguer publiquement les informations relatives aux vulnerabilites corrigees, y compris une description de la vulnerabilite, les informations permettant aux utilisateurs d’identifier le produit concerne et les impacts de la vulnerabilite ;
• mettre en place une politique de divulgation coordonnee des vulnerabilites ;
• faciliter le partage d’informations sur les vulnerabilites, y compris en fournissant un mecanisme de contact permettant aux chercheurs en securite de signaler des failles.

Ces exigences dessinent un programme complet de gestion des vulnerabilites. Voyons comment le structurer en pratique.

Etape 1 : Etablir le SBOM comme socle du programme

Tout programme de gestion des vulnerabilites repose sur une question prealable : de quoi est compose votre produit ? Impossible de gerer des vulnerabilites 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, dependances 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 generation du SBOM doit etre automatisee et integree a votre pipeline de build. Des outils comme Syft, Trivy ou CycloneDX CLI permettent de generer un SBOM a chaque compilation, au format CycloneDX ou SPDX. Le SBOM n’est pas un document statique : il doit etre regenere a chaque nouvelle version du produit et conserve pour assurer la tracabilite.

Etape 2 : Structurer le processus d’identification et de triage

Une fois le SBOM en place, l’etape suivante consiste a mettre en oeuvre un processus continu d’identification des vulnerabilites. Ce processus comporte trois volets.

Surveillance proactive des vulnerabilites connues

Votre equipe securite doit surveiller en permanence les bases de donnees publiques de vulnerabilites – principalement la base CVE (Common Vulnerabilities and Exposures) geree par le MITRE et la NVD (National Vulnerability Database) du NIST – pour detecter toute nouvelle vulnerabilite affectant un composant present dans votre SBOM.

Cette surveillance doit etre automatisee. Des outils comme Dependency-Track, Grype ou Snyk permettent de croiser automatiquement votre SBOM avec les bases CVE, une demarche que l’ANSSI recommande dans ses guides de bonnes pratiques, et de generer des alertes en temps reel lorsqu’une nouvelle vulnerabilite est publiee pour l’un de vos composants.

Reception des signalements externes

Le CRA exige que le fabricant fournisse un mecanisme de contact permettant aux chercheurs en securite, aux utilisateurs et aux tiers de signaler des vulnerabilites. Concretement, cela implique de mettre en place :

• une adresse de contact dediee (de type security@votreentreprise.com) ;
• un fichier security.txt conforme a la RFC 9116, place a la racine de votre site web ;
• un processus de reception et d’accuse de reception des signalements dans un delai raisonnable.

Triage et evaluation de la severite

Chaque vulnerabilite identifiee – qu’elle provienne de la surveillance automatisee ou d’un signalement externe – doit faire l’objet d’un triage structure. Le standard de reference pour evaluer la severite est le CVSS (Common Vulnerability Scoring System), actuellement en version 4.0. Cette approche structuree rejoint les exigences de la directive NIS2 en matiere de gestion des vulnerabilites.

Le triage doit permettre de determiner :

• la severite technique de la vulnerabilite (score CVSS) ;
• son exploitabilite dans le contexte specifique de votre produit ;
• l’impact potentiel sur les utilisateurs ;
• la priorite de remediation.

Toutes les vulnerabilites ne se valent pas. Une faille critique (CVSS >= 9.0) activement exploitee dans un composant directement expose n’appelle pas la meme reponse qu’une vulnerabilite basse dans une dependance transitive non accessible depuis une interface reseau.

Etape 3 : Remediation et deploiement des correctifs

Le CRA impose que les vulnerabilites soient corrigees sans delai (“without delay”). En pratique, votre programme doit definir des SLA internes de remediation en fonction de la severite :

Severite (CVSS)	Delai de remediation 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 vulnerabilites affectant des composants tiers, la situation est plus complexe. Si le correctif depend d’un fournisseur ou d’un projet open source, vous devez neanmoins evaluer 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 exonere pas.

Les mises a jour de securite doivent etre gratuites pour les utilisateurs et deployees de maniere automatique lorsque cela est techniquement possible. Le CRA est explicite sur ce point.

Etape 4 : Mettre en place la divulgation coordonnee des vulnerabilites

La politique de divulgation coordonnee des vulnerabilites (Coordinated Vulnerability Disclosure – CVD) est une obligation explicite du CRA. Cette politique doit definir :

• le processus de reception et de traitement des signalements (voir etape 2) ;
• les delais de traitement et de communication avec le chercheur ayant signale la vulnerabilite ;
• les conditions de publication de l’avis de securite ;
• les modalites de coordination avec les CSIRT nationaux et l’ENISA, conformement aux obligations de signalement du CRA.

Le format recommande pour la publication des avis de securite est le CSAF (Common Security Advisory Framework), qui permet une exploitation automatisee des avis par les outils de gestion des vulnerabilites. Le format VEX (Vulnerability Exploitability eXchange), qui est un profil de CSAF, permet en complement d’indiquer si une vulnerabilite connue affecte effectivement votre produit dans une version donnee – information particulierement utile pour vos clients.

Etape 5 : Integrer les tests de securite au cycle de developpement

L’annexe I exige des tests de securite reguliers et efficaces. En pratique, cela suppose d’integrer plusieurs types de tests dans votre pipeline CI/CD :

Analyse statique du code (SAST). Des outils comme SonarQube, Semgrep ou CodeQL doivent etre executes automatiquement a chaque pull request ou merge request. L’objectif est de detecter les patterns de code vulnerables avant qu’ils n’atteignent la branche principale.

Analyse de composition logicielle (SCA). L’analyse SCA – qui exploite directement le SBOM – verifie que les dependances utilisees ne contiennent pas de vulnerabilites connues. Elle doit bloquer le build en cas de vulnerabilite critique non resolue.

Tests dynamiques et fuzzing. Le fuzzing consiste a soumettre votre application a des entrees aleatoires ou malformees pour detecter des comportements inattendus, des crashes ou des failles de securite. Des outils comme AFL++, libFuzzer ou Jazzer permettent d’automatiser cette approche. Le CRA ne prescrit pas de technique specifique, mais l’emploi du fuzzing est considere comme une bonne pratique par les organismes de normalisation.

Tests d’intrusion (penetration testing). Des tests d’intrusion doivent etre conduits periodiquement – au minimum avant chaque version majeure – par des auditeurs internes ou externes qualifies. Ces tests simulent le comportement d’un attaquant reel et permettent de valider l’efficacite des mesures de securite en conditions reelles.

Revue de code securite. Pour les composants critiques, une revue de code manuelle orientee securite reste indispensable pour detecter des vulnerabilites logiques que les outils automatises ne peuvent identifier.

Etape 6 : Surveiller en continu les composants tiers

La gestion des vulnerabilites ne s’arrete pas au deploiement. Le CRA impose un suivi pendant toute la duree de support du produit, qui doit etre d’au minimum cinq ans (sauf si la duree de vie attendue du produit est inferieure).

Concretement, cela signifie que votre equipe doit :

• maintenir a jour le SBOM pour chaque version supportee du produit ;
• surveiller quotidiennement les flux de vulnerabilites (CVE, advisories des fournisseurs, alertes CERT) pour chaque composant present dans le SBOM ;
• evaluer l’impact de chaque nouvelle vulnerabilite sur les versions supportees ;
• declencher le processus de remediation lorsque necessaire.

Dependency-Track permet de gerer cette surveillance de maniere centralisee pour l’ensemble de vos produits et versions.

Etape 7 : Documenter et conserver les preuves

Le CRA exige la conservation de la documentation technique pendant dix ans apres la mise sur le marche du produit. La documentation a conserver comprend :

• le SBOM de chaque version du produit mise sur le marche ;
• le registre de toutes les vulnerabilites identifiees, avec pour chacune : la date d’identification, le score de severite, les mesures de remediation appliquees et les dates correspondantes ;
• les rapports de tests de securite (SAST, SCA, fuzzing, penetration testing) ;
• les avis de securite publies ;
• les echanges relatifs aux signalements de vulnerabilites recus et traites ;
• les preuves de notification aux autorites conformement aux obligations de signalement.

Cette documentation constitue votre dossier de conformite. En cas de controle par une autorite de surveillance du marche, c’est sur cette base que sera evaluee la conformite de votre processus.

Synthese : le programme de gestion des vulnerabilites en un schema

SBOM (fondation)
|
|-- Identification continue
|   |-- Surveillance CVE automatisee (Dependency-Track, Grype)
|   |-- Reception signalements externes (security.txt, email)
|   |-- Detection par tests (SAST, SCA, fuzzing, pentest)
|
|-- Triage (CVSS 4.0)
|   |-- Evaluation severite + exploitabilite
|   |-- Priorisation
|
|-- Remediation
|   |-- Correction code / mise a jour composant
|   |-- Deploiement mise a jour securite (gratuite)
|   |-- Mesures d'attenuation si correctif indisponible
|
|-- Divulgation coordonnee
|   |-- Notification CSIRT + ENISA (si exploitation active)
|   |-- Publication avis securite (CSAF/VEX)
|   |-- Communication utilisateurs
|
|-- Documentation
    |-- Registre vulnerabilites
    |-- Rapports de tests
    |-- Conservation 10 ans

La gestion des vulnerabilites conforme au CRA n’est pas un exercice ponctuel. C’est un processus continu, integre au cycle de vie du produit, qui mobilise des outils, des competences et une organisation dediee. Les equipes qui mettent en place ce programme des maintenant – avant l’entree en application des obligations en septembre 2026 pour le signalement et en decembre 2027 pour l’ensemble des exigences – disposeront d’un avantage determinant.