Divulgation coordonnée des vulnérabilités : comment gérer un programme

Qu'est-ce que la divulgation coordonnée des vulnérabilités ?

La divulgation coordonnée des vulnérabilités (CVD) consiste à traiter une vulnérabilité nouvellement découverte en privé entre la personne qui l'a trouvée et l'éditeur jusqu'à ce qu'un correctif ou une atténuation soit disponible, puis à la publier. Le CERT Guide to Coordinated Vulnerability Disclosure la décrit comme le fait de recueillir les informations auprès de ceux qui trouvent les vulnérabilités, de coordonner le partage de ces informations entre les parties prenantes concernées et de divulguer la vulnérabilité et ses atténuations, y compris au public.

Pour un éditeur de produits, la CVD comporte deux volets. Le volet externe, recevoir les signalements et publier les avis de sécurité, est celui que couvre cette page. Le volet interne, vérifier, corriger et publier, est le cycle de vie de la gestion des vulnérabilités. Les deux sont généralement pilotés par un PSIRT.

CVD, divulgation complète ou bug bounty

	Divulgation coordonnée	Divulgation complète	Bug bounty
Ce que c'est	Signalement privé, correctif, puis publication à une date convenue	La personne qui a trouvé la faille en publie les détails immédiatement, en prévenant l'éditeur ou non	Un programme qui rémunère les découvertes valides
Qui contrôle le calendrier	L'éditeur et la personne qui a trouvé la faille, parfois avec un coordinateur	La personne qui a trouvé la faille	Les conditions du programme, qui suivent généralement la CVD
Risque pour les utilisateurs	Le plus faible : les détails sont publics une fois qu'un correctif existe ou qu'une date limite est dépassée	Le plus élevé : les attaquants l'apprennent en même temps que les défenseurs	Comme pour la CVD
Coût	Le temps du personnel pour trier et répondre	Un travail d'urgence non planifié	Le temps du personnel, plus les récompenses et souvent les frais de plateforme

Un bug bounty n'est pas une alternative à un programme de divulgation des vulnérabilités (VDP). C'est une incitation qui vient s'y ajouter. Tout éditeur a besoin d'un moyen permettant à n'importe qui de signaler une vulnérabilité ; un bounty décide seulement si certains signalements sont rémunérés.

Le contenu d'une politique de divulgation des vulnérabilités

Une politique de divulgation des vulnérabilités est le document public qui fixe les conditions de votre programme. ISO/IEC 29147, la norme internationale sur la divulgation des vulnérabilités, rend un élément obligatoire, un moyen de contact privilégié, et en recommande plusieurs autres. Une politique complète couvre :

• Comment signaler. Une adresse dédiée ou un formulaire web, et un moyen d'envoyer des détails sensibles en toute sécurité, comme une clé de chiffrement publiée.
• Quoi inclure. Le produit et la version concernés, les étapes de reproduction, l'impact et le moyen de joindre l'auteur du signalement.
• Le périmètre. Les produits, versions et services couverts, et les méthodes de test interdites, comme le déni de service ou l'accès aux données d'autres utilisateurs.
• Le safe harbor. Un engagement à ne pas intenter de poursuites contre les recherches de bonne foi qui respectent la politique.
• Ce que les auteurs de signalements peuvent attendre. Quand vous accuserez réception, comment vous les tiendrez informés et votre délai cible de correction.
• Le calendrier de divulgation. Quand les détails deviennent publics, et ce qui se passe si un correctif prend plus de temps.
• La publication. Où paraissent les avis et si vous attribuez des identifiants CVE.
• La reconnaissance. Si et comment vous mentionnez les auteurs de signalements, et si vous versez des primes.

Gardez une politique courte et précise. Les auteurs de signalements la lisent pour décider s'il est sûr et utile de vous signaler quelque chose.

security.txt : rendez votre contact facile à trouver

Une politique ne fonctionne que si les chercheurs peuvent la trouver. La RFC 9116, publiée en avril 2022, définit security.txt, un petit fichier texte servi à l'adresse /.well-known/security.txt en HTTPS.

Contact: mailto:[email protected]
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• Obligatoires : Contact et Expires. La RFC 9116 recommande une expiration à moins d'un an, pour que le fichier ne devienne pas obsolète.
• Facultatifs : Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical et Hiring.
• Signature : la RFC recommande une signature OpenPGP en clair, avec Canonical renseigné.

Mettez un rappel dans le calendrier avant la date Expires. Un fichier expiré indique aux chercheurs que personne ne le lit.

Embargos et calendriers de divulgation

L'embargo est la période entre le signalement et la publication. La norme la plus citée est la politique de Google Project Zero : les éditeurs ont 90 jours pour mettre un correctif à disposition, et les détails sont publiés 30 jours après la sortie du correctif. Un éditeur qui a besoin d'un peu plus de temps peut demander un délai de grâce, jusqu'à 104 jours au total. Lorsqu'une vulnérabilité est déjà exploitée en conditions réelles, le délai tombe à 7 jours.

Votre propre politique peut fixer d'autres conditions, et de nombreux auteurs de signalements les acceptent. L'essentiel est que le calendrier soit écrit, que vous teniez les auteurs de signalements informés et que vous demandiez une prolongation avant la date limite plutôt qu'après. Un avis publié dans les temps avec une atténuation vaut mieux que le silence.

Identifiants CVE et CNA

La plupart des avis portent un identifiant CVE, pour que les clients et les outils puissent les faire correspondre. Les identifiants sont attribués par des CVE Numbering Authorities (CNA), des organisations autorisées à attribuer des identifiants dans un périmètre convenu. De nombreux éditeurs de logiciels sont CNA pour leurs propres produits, ce qui leur permet d'attribuer l'identifiant et de publier l'enregistrement selon leur propre calendrier. Si ce n'est pas votre cas, une CNA dont le périmètre couvre votre produit, ou une CNA of Last Resort, l'attribue.

La coordination multipartite

Certaines vulnérabilités touchent de nombreux éditeurs à la fois : une faille dans une bibliothèque largement utilisée, un protocole ou une puce. Un coordinateur aide alors à joindre tous les éditeurs concernés et à convenir d'une seule date de publication.

• Le CERT/CC, au Software Engineering Institute de l'université Carnegie Mellon, coordonne les cas multi-éditeurs et publie le guide CERT sur la CVD.
• Les CSIRT nationaux dans l'UE. En vertu de NIS2, chaque État membre désigne un CSIRT comme coordinateur de la CVD. Celui-ci agit comme intermédiaire de confiance entre les auteurs de signalements et les éditeurs, négocie les calendriers de divulgation, traite les vulnérabilités qui touchent plusieurs entités et accepte les signalements anonymes.
• La European Vulnerability Database (EUVD) de l'ENISA, créée en vertu de NIS2, est opérationnelle depuis mai 2025 et publie des informations sur les vulnérabilités connues du public, y compris celles coordonnées dans l'UE.

ISO/IEC 29147 couvre aussi le cas où vous êtes les deux à la fois : un éditeur dont le produit contient le composant vulnérable d'un autre éditeur, et qui doit signaler en amont et informer ses propres clients.

Après la réception d'un signalement

1. Accusez réception dans le délai promis par votre politique et donnez à l'auteur du signalement un identifiant de suivi.
2. Vérifiez le signalement et évaluez sa sévérité.
3. Trouvez ce qui est touché : chaque produit, release et branche prise en charge qui contient le code ou le composant vulnérable.
4. Corrigez et publiez pour chaque branche concernée, en tenant l'auteur du signalement informé.
5. Publiez l'avis de sécurité, avec un identifiant CVE, les versions concernées, la remédiation et la mention de l'auteur. Les avis lisibles par machine utilisent CSAF, et VEX indique aux clients quels produits ne sont pas concernés.

Le processus complet, avec les rôles, les délais et les indicateurs, se trouve dans le cycle de vie de la gestion des vulnérabilités.

La réglementation rend les politiques de CVD obligatoires

Le Cyber Resilience Act de l'UE impose aux fabricants de mettre en place et d'appliquer une politique de divulgation coordonnée des vulnérabilités et de fournir une adresse de contact pour signaler les vulnérabilités, y compris celles des composants tiers (annexe I, partie II). Ces obligations s'appliquent à partir du 11 décembre 2027 ; voir ce qu'exige le CRA. L'article 21, paragraphe 2, point e), de NIS2 cite le traitement et la divulgation des vulnérabilités parmi les mesures de sécurité que doivent prendre les entités essentielles et importantes. Aux États-Unis, l'Executive Order 14028 a commandé des recommandations sur la chaîne d'approvisionnement logicielle qui incluent la participation à un programme de divulgation des vulnérabilités.

Un signalement ne vaut que ce que vaut votre enregistrement de ce que vous avez livré

Chaque signalement soulève la même première question : lesquelles de nos releases contiennent cela ? CRACI exécute vos builds GitHub Actions sur ses propres runners et enregistre les paquets que chaque job a réellement récupérés, y compris les dépendances transitives, les paquets restaurés depuis les caches CI et les dépendances qu'aucun lockfile ne liste. L'historique des builds montre quels builds passés contenaient une dépendance vulnérable : vous connaissez ainsi la période pendant laquelle vous avez été touché, et la vue d'inventaire montre quelles versions du logiciel sont déployées sur quels produits.

CRACI agrège les SBOM sur l'ensemble des builds et des dépôts et réévalue en continu les SBOM surveillées : une fois qu'une vulnérabilité d'un composant open source est publiée, vous voyez donc tous les endroits où elle apparaît. Les équipes sécurité trient les résultats et les envoient aux équipes chargées de la correction, CRACI prend en charge VEX, et les policy gates peuvent bloquer les builds qui contiennent une CVE précise une fois celle-ci corrigée. Voir le suivi des vulnérabilités.

Divulgation coordonnée des vulnérabilités : questions fréquentes

Qu'est-ce que la divulgation coordonnée des vulnérabilités ?

La divulgation coordonnée des vulnérabilités (CVD) est le processus par lequel la personne qui trouve une vulnérabilité la signale en privé à l'éditeur, l'éditeur la corrige, et les détails sont publiés une fois que les utilisateurs peuvent se protéger, généralement à une date convenue entre les parties. Des coordinateurs tels que le CERT/CC ou un CSIRT national interviennent lorsqu'un éditeur est injoignable ou que plusieurs éditeurs sont concernés.

Quelle est la différence entre un VDP et un bug bounty ?

Un programme de divulgation des vulnérabilités (VDP) indique à chacun comment signaler une vulnérabilité et à quoi s'attendre, sans rémunérer les découvertes. Un bug bounty rémunère les chercheurs pour les découvertes valides, généralement dans un périmètre défini et souvent via une plateforme de bounty. La plupart des organisations commencent par un VDP ; un bounty est un ajout facultatif, pas un remplacement.

Que doit contenir une politique de divulgation des vulnérabilités ?

Au minimum, la façon de signaler : une adresse de contact ou un formulaire. ISO/IEC 29147 recommande aussi d'indiquer ce qu'un signalement doit contenir, comment communiquer en toute sécurité, ce que les auteurs de signalements peuvent attendre et quand, ce qui est dans le périmètre, comment vous publiez les avis et comment vous mentionnez les auteurs. La plupart des politiques ajoutent une clause de safe harbor et un calendrier de divulgation.

Qu'est-ce que security.txt ?

security.txt est un fichier texte brut défini dans la RFC 9116 et servi à l'adresse /.well-known/security.txt. Il indique aux chercheurs où signaler les vulnérabilités. Il doit contenir un champ Contact et un champ Expires et peut renvoyer vers votre politique, votre clé de chiffrement et votre page de remerciements.

Quelle est la durée habituelle d'un délai de divulgation ?

Le délai de 90 jours est la norme la plus citée. Google Project Zero donne aux éditeurs 90 jours pour mettre un correctif à disposition et publie les détails 30 jours après le correctif, avec un délai de 7 jours lorsqu'une vulnérabilité est déjà exploitée en conditions réelles. Votre propre politique peut fixer d'autres conditions, et les coordinateurs négocient au cas par cas.

Une politique de divulgation coordonnée des vulnérabilités est-elle obligatoire ?

De plus en plus, oui. Le Cyber Resilience Act de l'UE impose aux fabricants de produits comportant des éléments numériques de mettre en place et d'appliquer une politique de CVD et de fournir une adresse de contact pour les signalements, et NIS2 cite le traitement et la divulgation des vulnérabilités parmi les mesures de sécurité requises. Ailleurs, les clients et les règles d'achat en demandent souvent une.

Faut-il être CNA pour obtenir un identifiant CVE ?

Non. Une CVE Numbering Authority (CNA) attribue des identifiants CVE dans son propre périmètre, et de nombreux éditeurs deviennent CNA pour leurs propres produits. Si ce n'est pas votre cas, une CNA dont le périmètre couvre votre produit, ou une CNA of Last Resort, peut attribuer l'identifiant.