Gestion des vulnérabilités : cadrer le processus NIS2

Construire un processus de décision

La gestion des vulnérabilités doit relier une information de sécurité à des systèmes réellement utilisés et à une décision. L’article 21 de la directive inclut la sécurité de l’acquisition, du développement et de la maintenance, ainsi que le traitement des vulnérabilités. ReCyF peut soutenir la préparation du processus. Une liste de failles exportée par un outil ne démontre pas, à elle seule, que les risques sont maîtrisés.

Commencez par identifier les actifs, leurs propriétaires et les services supportés. Les versions et les dépendances doivent être suffisamment connues pour qualifier une alerte. Une cartographie incomplète peut empêcher de savoir si un composant est présent. Le rapport doit rendre cette limite visible plutôt que déclarer une absence d’exposition sur la base d’un inventaire partiel.

Organiser la veille et la qualification

Définissez les sources d’information pertinentes : bulletins officiels, avis éditeurs et observations internes autorisées. Le CERT-FR publie des avis et alertes utiles à la veille. Chaque information doit être confrontée à votre périmètre. Une gravité technique ne décrit pas toute la priorité métier. L’exposition, les privilèges et les dépendances peuvent modifier le traitement.

La qualification doit préciser si le composant est présent, si les conditions d’exploitation sont réunies et quels services pourraient être affectés. Les données inconnues sont conservées comme réserves. Un contrôle peut être nécessaire pour confirmer une version ou une configuration. Les méthodes de vérification doivent être autorisées et compatibles avec les contraintes de production.

Prioriser avec les responsables de service

Un délai de correction doit être défini selon le risque et le cadre pertinent. Ce guide n’invente pas un délai réglementaire unique pour toutes les vulnérabilités. La direction doit comprendre les conséquences d’une correction immédiate, d’une mesure intermédiaire ou d’un report. Les environnements opérationnels et les contrats de support peuvent imposer des prérequis.

Une mesure intermédiaire peut réduire l’exposition pendant la préparation d’une correction, mais son efficacité doit être examinée. Un simple statut « accepté » sans responsable ni justification ne clôt pas le problème. La décision conserve les informations connues, les mesures et la condition de réexamen. Les actifs sans support nécessitent une analyse propre, avec un projet de traitement explicite.

Étape	Trace utile
Réception	Source, date et information de sécurité
Qualification	Actifs concernés, exposition et incertitudes
Décision	Priorité, responsable et justification
Correction	Intervention, périmètre et dépendances
Vérification	Observation après action et limites

Exemple pédagogique : un composant partagé

Dans un exemple pédagogique, une vulnérabilité concerne une bibliothèque utilisée par plusieurs applications. L’organisation doit identifier les applications affectées et les équipes responsables. Une correction sur un serveur ne règle pas automatiquement tous les usages. Le registre doit suivre chaque périmètre et les dépendances à un éditeur ou à une équipe de développement.

La réception d’une mission peut observer le parcours complet d’une alerte jusqu’à sa clôture. Le prestataire examine la source, la qualification, la décision et la vérification. Si une application reste inconnue, le rapport conserve cette réserve. Cet exemple ne représente aucun client et ne suppose aucune vulnérabilité présente dans votre organisation.

Vérifier la clôture et conserver les exceptions

La clôture doit s’appuyer sur une preuve adaptée : version corrigée, configuration observée ou autre mesure vérifiée. Un ticket marqué terminé peut être insuffisant si l’action n’a pas été confirmée. La preuve doit indiquer la date et le périmètre. Les erreurs ou les difficultés rencontrées doivent pouvoir être reprises dans le retour d’expérience.

Les reports ont un propriétaire et une date interne de réexamen. Ils sont visibles dans la synthèse de risque. Un changement d’exposition ou une nouvelle information peut justifier une décision plus urgente. Le processus doit fonctionner dans la durée et rester relié aux achats, au support et aux changements de systèmes. Les observations sensibles ne doivent pas être publiées dans des documents destinés à un large public.

Cahier de mission et critères de réception

Le devis doit préciser si la mission couvre la conception du processus, l’analyse de l’existant ou une campagne technique de recherche. Demandez les actifs et les méthodes inclus, les autorisations nécessaires et les limites des outils. Un scan automatisé n’équivaut pas à une revue de gestion des vulnérabilités, et un rapport de processus ne remplace pas une observation technique.

Les livrables peuvent comprendre une procédure, une matrice de priorisation et un registre des exceptions. Exigez des critères de clôture explicites. Le prestataire doit expliquer comment il traite les faux positifs, les actifs inconnus et les contraintes de support. La mission ne doit pas produire des délais de correction présentés comme légaux sans référence applicable.

À la réception, suivez un échantillon d’alertes et vérifiez la traçabilité des décisions. Le propriétaire du service doit être identifiable. Les reports sont motivés et les corrections ont une preuve. Les données de scanner doivent être protégées, car elles peuvent révéler des expositions. Le formulaire commercial n’est pas un canal pour transmettre les résultats détaillés. Prévoyez enfin le maintien du processus et les personnes chargées de la veille après la livraison.

Le processus doit aussi intégrer les applications développées en interne. Identifiez les équipes et les composants maintenus, puis les conditions de diffusion des corrections. Une dépendance mise à jour dans un dépôt peut rester présente dans une version en production. La preuve de clôture doit donc vérifier le déploiement sur les services concernés, avec une trace des versions et des limites de l’observation.

Sources et portée réglementaire

Sources vérifiées les 30 septembre et 1 octobre 2026. Les méthodes proposées ici sont des conseils de préparation et d’achat. La directive fixe le cadre européen ; le droit national et, selon l’activité, les règlements sectoriels déterminent les exigences applicables. L’ANSSI décrit ReCyF comme un document de travail. Un écart à une recommandation ne suffit pas, à lui seul, à constater une infraction.

Poursuivre le cadrage

Questions sur ce dossier

Un scanner suffit-il à démontrer la maîtrise ?

Non. Il faut relier les résultats aux actifs, aux décisions et aux preuves de correction. La couverture et les limites du scanner doivent être explicites.

Existe-t-il un délai unique à annoncer pour toutes les failles ?

Aucun délai universel n’est annoncé ici. Le traitement dépend du risque et des règles pertinentes, avec une justification et une décision traçables.

Un ticket fermé constitue-t-il une preuve suffisante ?

Cela dépend de son contenu. La clôture doit établir l’action réalisée et sa vérification sur le périmètre concerné.