Après l'arrivée d'un signalement de vulnérabilité : accuser réception, évaluer, corriger en privé, divulguer

Objectif

Transformer un signalement privé en une version corrigée et un avis public sans que les détails ne fuitent avant que les utilisateurs puissent mettre à jour, et sans que la personne à l'origine du signalement ne perde patience et ne publie la première.

Prérequis

Un canal de signalement déjà publié (security.txt ou un fichier SECURITY, avec un lien) ; un endroit privé pour développer un correctif (un fork privé temporaire ou un brouillon d'avis privé) ; la liste des personnes pouvant publier une version ; et, idéalement, un contact d'autorité de numérotation CVE identifié à l'avance, comme le recommande le guide de l'OpenSSF. Ce guide indique que, dans un petit projet d'un à cinq mainteneurs, les mainteneurs eux-mêmes peuvent constituer l'équipe de gestion des vulnérabilités.

Étapes

1. Accuser réception avant d'évaluer quoi que ce soit. Le guide de l'OpenSSF recommande de le faire rapidement, sous un à deux jours ; les recommandations de GitHub disent la même chose et ajoutent que cela donne le ton pour la suite des échanges.
2. Évaluer avec les étapes et les versions fournies par la personne qui signale. La classification du guide : fonctionne comme prévu, bug ordinaire, demande de fonctionnalité, ou vulnérabilité, une vulnérabilité compromettant la confidentialité, l'intégrité ou la disponibilité. Communiquer le résultat et sa raison ; une suggestion de durcissement n'est pas une vulnérabilité et peut devenir un ticket ordinaire.
3. Convenir d'une période d'embargo. Le guide note que la personne qui signale en propose généralement une, que 90 jours est le maximum par défaut envisagé par les groupes qu'il cite, et que c'est une communication continue qui maintient sa volonté de la prolonger.
4. Développer et tester le correctif en privé ; identifier chaque version concernée et quelles lignes prises en charge recevront le correctif. Garder le correctif minimal pour que la mise à jour reste facile ; ne pas y mêler de changements d'API.
5. Réserver un identifiant CVE auprès de l'autorité de numérotation (CNA) et rédiger la description. Demander à la personne qui signale si et comment elle souhaite être créditée ; le guide qualifie d'inapproprié le fait d'omettre le crédit, sauf refus explicite.
6. Choisir un jour de publication où les personnes peuvent mettre à jour pendant les heures de travail ; le guide suggère du lundi au mercredi, en évitant les jours fériés largement observés.
7. Publier la version, puis l'avis : versions concernées, versions corrigées, contournement éventuel, crédit. Les recommandations de GitHub insistent sur le fait de marquer explicitement la version comme un correctif de sécurité, afin que les consommateurs en aval le remarquent.
8. Consigner la chronologie (signalement, accusé de réception, correctif, divulgation) pour la prochaine revue du processus.

Résultat attendu

La personne qui signale reçoit des réponses datées à chaque étape ; les utilisateurs apprennent l'existence du problème par l'avis propre du projet et par une version corrigée, au même moment.

Limites et base de vérification

Les étapes et les délais proviennent des guides cités ; aucun incident n'est décrit et aucune durée n'est mesurée. Les projets ayant des distributeurs peuvent avoir besoin d'une liste d'embargo, que le guide de l'OpenSSF considère comme optionnelle et coûteuse.

Publier l'avis en même temps que la version

Une fois le correctif poussé sur une branche publique, le diff divulgue la vulnérabilité à quiconque lit les commits, et pour une bibliothèque, c'est la publication de l'avis qui déclenche les alertes des analyseurs de dépendances dans les projets en aval. Rédiger l'avis en entier pendant la phase de correction privée : versions concernées, versions corrigées, contournement, crédit convenu avec la personne qui signale. Publier ensuite la version et l'avis comme une seule étape, à quelques minutes d'écart au plus, de préférence depuis un seul script qui étiquette, téléverse le paquet et publie l'avis. La seule contrainte d'ordre est que l'avis ne doit jamais nommer une version corrigée avant qu'elle ne soit installable.