Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Coordinated Vulnerability Disclosure (CVD)

general

Définition

La Divulgation Coordonnée de Vulnérabilité (CVD — Coordinated Vulnerability Disclosure) est la version formalisée et standardisée de la divulgation responsable. Elle est définie par les normes ISO/IEC 29147 (processus de divulgation pour les fournisseurs) et ISO/IEC 30111 (processus de traitement des vulnérabilités), et promue par des organisations comme FIRST, l'ENISA, et la CISA. La CVD se distingue de la divulgation responsable par son cadre multipartite et sa coordination explicite. Alors que la divulgation responsable implique généralement un chercheur individuel et un éditeur, la CVD peut impliquer plusieurs acteurs : un chercheur ou une équipe, un coordinateur (CERT national ou organisme spécialisé), plusieurs fournisseurs affectés simultanément (cas des vulnérabilités dans des composants partagés comme OpenSSL ou Log4j), et les médias spécialisés. Le rôle du coordinateur est central dans la CVD complexe. Lorsqu'une vulnérabilité affecte simultanément des dizaines de produits (cas typique avec les bibliothèques open-source), un coordinateur comme le CERT/CC, l'ANSSI ou le CERT-EU coordonne la notification simultanée de tous les éditeurs affectés, synchronise les dates de publication des correctifs, et gère la communication publique. Sans coordination, certains éditeurs pourraient publier avant d'autres, avantageant les attaquants. La directive NIS 2 (transposée en droit européen en 2024) impose aux États membres d'établir des politiques nationales de CVD et de désigner une autorité nationale compétente pour la coordination. En France, l'ANSSI joue ce rôle coordonnateur pour les vulnérabilités affectant les systèmes d'information des OIV (Opérateurs d'Importance Vitale) et OSE (Opérateurs de Services Essentiels). Les cas emblématiques de CVD complexe illustrent son importance : la vulnérabilité Heartbleed (CVE-2014-0160) dans OpenSSL, Log4Shell (CVE-2021-44228) dans Apache Log4j, et KRACK (vulnérabilités WPA2) ont nécessité une coordination mondiale impliquant des centaines d'éditeurs, des CERTs nationaux, et des opérateurs d'infrastructure critique.

ISO/IEC 29147 et 30111 — le cadre normatif

ISO/IEC 29147:2018 définit les exigences pour les fournisseurs qui reçoivent des reports de vulnérabilités : disposer d'un canal de réception sécurisé, accuser réception rapidement, évaluer et reproduire la vulnérabilité, développer un correctif, coordonner la publication, et maintenir un advisory de sécurité. ISO/IEC 30111:2019 complète avec le processus de traitement interne : politiques de priorisation, workflows de développement de correctifs, et communication interne. Ces deux normes constituent le référentiel pour les certifications et les audits de maturité des processus PSIRT.

CVRF/CSAF — formats standardisés pour les advisories

Le CSAF (Common Security Advisory Framework) est le format standard pour la publication d'advisories de sécurité lisibles par machine. Développé par OASIS, il succède au CVRF et permet aux outils de vulnerability management d'automatiser l'ingestion des advisories publiées par les éditeurs. Les grands fournisseurs (Microsoft, Red Hat, Cisco, VMware) publient leurs advisories en CSAF, permettant aux clients d'automatiser la mise à jour de leur registre de vulnérabilités. Le VEX (Vulnerability Exploitability eXchange), composant du CSAF, permet aux fournisseurs de préciser si leurs produits sont affectés par une CVE spécifique, même si la bibliothèque vulnérable est présente dans leur SBOM.

CVD et vulnérabilités dans les composants open-source

Les vulnérabilités dans les composants open-source présentent des défis particuliers pour la CVD : il n'y a pas toujours de PSIRT désigné, les mainteneurs peuvent être des individus bénévoles débordés, et l'impact touche des milliers de produits downstream. Des initiatives comme GitHub Private Security Advisories, l'OSS-Fuzz de Google, et l'OpenSSF (Open Source Security Foundation) améliorent la situation. Pour Log4Shell, la coordination impliquait plus de 500 fournisseurs affectés simultanément — un cas extrême qui a conduit à des réflexions sur la nécessité d'organismes de coordination mondiaux permanents pour les composants critiques.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis