Le 7 septembre 2026, la CNCF a publié une fiche pratique intitulée « Gérer les signalements de vulnérabilités » (Handling vulnerability reports: Recipe card), destinée aux petits et moyens projets open source qui ne mettent pas principalement l’accent sur la sécurité. Le document a été préparé par Marina Moore d’Edera, coprésidente de TAG Security, et par Sherine Khoury de Red Hat, responsable de TAG Security.
L’idée centrale du guide est de réduire le travail supplémentaire imposé aux responsables et aux utilisateurs, tout en empêchant qu’un signalement de sécurité ne devienne une discussion publique avant que le correctif soit prêt. La CNCF explique qu’une vulnérabilité de sécurité est une faille pouvant être exploitée pour affecter la confidentialité, l’intégrité ou la disponibilité d’un système, mais que toute anomalie logicielle n’est pas nécessairement exploitable ni classée comme une vulnérabilité.
Commencer par un canal de signalement clair et privé
Les lignes directrices recommandent que le fichier README.md contienne une section de sécurité claire et facile à trouver, avec des instructions directement dans le fichier ou un renvoi vers un fichier SECURITY.md à la racine du dépôt. L’objectif est d’orienter les chercheurs vers une voie privée plutôt que de publier les détails du problème dans une issue publique lisible par tous.
Les instructions de signalement devraient préciser plusieurs éléments, notamment le modèle de menace ou le seuil minimal permettant de considérer le signalement comme une vulnérabilité, le lieu d’envoi, le format du signalement, le délai prévu avant son examen et le délai approximatif avant sa divulgation. Il est possible d’utiliser le mécanisme de signalement privé des vulnérabilités de GitHub ou une liste de diffusion privée. En revanche, un programme de récompenses n’est pas obligatoire pour les petits et moyens projets s’ils ne disposent pas des capacités nécessaires pour l’exploiter.
Vérifier la nature du signalement avant de le traiter comme une vulnérabilité
Après réception du signalement, il convient d’abord de déterminer s’il fait réellement état d’une vulnérabilité exploitable, ou plutôt d’un défaut non exploitable, d’une mauvaise compréhension du comportement attendu ou d’une erreur de documentation. La CNCF propose d’examiner le signalement avec son auteur et les experts appropriés du projet, en limitant le nombre de participants et en veillant à ce que tous respectent la confidentialité jusqu’à ce que le signalement devienne public.
Parmi les questions pratiques à poser : existe-t-il une mesure d’atténuation accessible aux utilisateurs ? Le défaut peut-il entraîner une compromission, une fuite de données ou une autre activité malveillante ? Le problème concerne-t-il uniquement la documentation ? S’il s’avère que le signalement ne constitue pas une vulnérabilité, son auteur peut être orienté vers la création d’une issue publique, en appliquant les procédures de publication appropriées pour informer les utilisateurs si nécessaire.
En cas d’incertitude, les lignes directrices indiquent qu’il est possible de demander conseil à TAG Security and Compliance ou au personnel de la CNCF, tout en maintenant les détails du signalement en dehors des canaux publics. Il convient également de choisir soigneusement les participants pendant la période de confidentialité et de n’impliquer que les personnes ayant réellement besoin de contribuer à la résolution, afin d’éviter que l’information ne parvienne à des attaquants avant la mise à disposition du correctif.
Développer et tester le correctif à l’abri du public
La CNCF met en garde contre la publication du correctif ou sa discussion dans une pull request publique, car cela pourrait révéler la nature de la vulnérabilité avant que les utilisateurs aient eu la possibilité d’effectuer la mise à jour. Si le mécanisme de signalement privé de GitHub est utilisé, une branche privée peut être créée à partir du signalement. Dans les autres cas, le correctif peut être développé et révisé au moyen d’un canal privé.
Le correctif doit être testé, même si l’environnement habituel d’intégration continue ne fonctionne pas avec les branches privées. Dans ce cas, les tests peuvent être effectués localement, selon l’appréciation des responsables et l’ampleur de la modification. Après avoir vérifié que le correctif traite le problème et que les tests sont suffisants, les lignes directrices recommandent de l’intégrer rapidement et d’impliquer un nombre suffisant de responsables dans sa création et ses tests. Avant la publication générale, le code devrait être réexaminé et il faudrait vérifier une nouvelle fois que la vulnérabilité a bien été corrigée.
Coordonner la publication avec la divulgation du CVE
Une fois le correctif terminé, la CNCF considère que sa divulgation dans les 90 jours suivant la réception du signalement constitue une pratique courante. Si ses ressources le permettent, le projet peut informer à l’avance une liste privée d’utilisateurs, mais la tenue à jour d’une liste de contacts représente une charge que la plupart des petits projets ne peuvent pas assumer.
La fiche propose donc une approche plus simple : mettre à disposition la version contenant le correctif et annoncer la vulnérabilité au même moment, afin que les utilisateurs disposent du correctif dès l’annonce du problème. Cela nécessite de construire une nouvelle version dès l’intégration du correctif, puis de publier le CVE. Si le mécanisme privé de GitHub est utilisé, cette opération peut être effectuée depuis l’interface de GitHub.
Un numéro CVE doit être attribué par une CNA, c’est-à-dire une autorité de numérotation CVE. GitHub fait partie de ces autorités et peut réaliser cette opération ; le projet et le chercheur peuvent également communiquer directement avec l’une des autorités CNA répertoriées. Le niveau de gravité du CVE est déterminé au moyen d’un ensemble de questions, et le projet devrait travailler avec le chercheur pour vérifier l’exactitude des réponses et convenir du niveau attribué.
Pourquoi ces lignes directrices sont-elles importantes ?
En pratique, la fiche transforme la gestion d’une vulnérabilité, qui relevait auparavant d’une réaction improvisée, en un processus applicable : canal privé, vérification limitée, correctif non divulgué, puis publication et divulgation coordonnées. Après la publication du CVE, les informations apparaissent dans OSV et dans d’autres bases de données de vulnérabilités, ce qui aide les outils d’analyse des utilisateurs à détecter la nécessité d’effectuer une mise à jour.
La portée de la recette est toutefois clairement limitée : elle s’adresse aux petits et moyens projets non spécialisés dans la sécurité et ne remplace pas un programme plus complexe pour les projets à haut risque ou sensibles du point de vue de la sécurité. La CNCF propose également d’envisager la publication d’une preuve de concept après un certain délai suivant la mise à disposition du correctif, afin d’accorder aux utilisateurs une possibilité supplémentaire d’effectuer la mise à jour, tout en reconnaissant que sa mise en œuvre peut être difficile lorsque le signalement privé est utilisé.