Toute personne disposant d’autorisations d’administrateur sur un dépôt public peut créer un avis de sécurité.
Toute personne disposant d’autorisations d’administrateur sur un dépôt public dispose également d’autorisations d’administrateur sur tous les avis de sécurité de ce référentiel. Les utilisateurs disposant d’autorisations d’administrateur sur un avis de sécurité peuvent ajouter des collaborateurs, et les collaborateurs disposent d’autorisations en écriture sur celui-ci.
Remarque : Si vous êtes chercheur en sécurité, vous devez contacter directement les mainteneurs pour leur demander de créer des avis de sécurité ou d’émettre des CVE en votre nom dans les dépôts que vous n’administrez pas. Toutefois, si les rapports de vulnérabilités privés sont activés pour le dépôt, vous pouvez signaler vous-même une vulnérabilité en privé. Pour plus d’informations, consultez « Signalement privé d’une vulnérabilité de sécurité ».
À propos des avis de sécurité des référentiels
La divulgation des vulnérabilités est un domaine où la collaboration entre les rapporteurs de vulnérabilités, par exemple, les chercheurs en sécurité et les chargés de maintenance de projet, est très importante. Les deux parties doivent travailler ensemble à partir du moment où une vulnérabilité de sécurité potentiellement dangereuse est trouvée et jusqu’à ce qu’elle soit divulguée publiquement, idéalement avec un patch disponible. En règle générale, quand quelqu’un indique en privé une vulnérabilité de sécurité à un chargé de maintenance, ce dernier développe un correctif, le valide et avertit les utilisateurs du projet ou du package. Pour plus d’informations, consultez « À propos de la divulgation coordonnée des vulnérabilités de sécurité ».
Les avis de sécurité des référentiels permettent aux gestionnaires de dépôts publics de discuter d’une faille de sécurité dans un projet et de la résoudre en privé. Après avoir collaboré sur un correctif, ils peuvent publier l’avis de sécurité pour rendre publique la vulnérabilité de sécurité auprès de la communauté du projet. En publiant des avis de sécurité, les chargés de maintenance des dépôts facilitent la mise à jour des dépendances de package pour leur communauté et la recherche de l’impact des vulnérabilités de sécurité.
Les avis de sécurité des référentiels permettent les actions suivantes :
- Créer un brouillon d’avis de sécurité et l’utiliser pour discuter en privé de l’impact de la vulnérabilité sur votre projet. Pour plus d’informations, consultez « Création d’un avis de sécurité de dépôt ».
- Collaborer en privé pour corriger la vulnérabilité dans une duplication (fork) privée temporaire.
- Publier l’avis de sécurité pour alerter votre communauté de la vulnérabilité une fois qu’un correctif est publié. Pour plus d’informations, consultez « Publication d’un avis de sécurité de dépôt ».
Vous pouvez également utiliser des avis de sécurité des référentiels pour republier les détails d’une vulnérabilité de sécurité que vous avez déjà divulguée à un autre emplacement en effectuant un copier-coller des détails de la vulnérabilité dans un nouvel avis de sécurité.
Vous pouvez également utiliser l’API REST pour créer, répertorier et mettre à jour les avis de sécurité des référentiels. Pour plus d’informations, consultez « Points de terminaison d’API REST pour les avis de sécurité de référentiels ».
Vous pouvez créditer les personnes qui ont contribué à un avis de sécurité. Pour plus d’informations, consultez « Modification d’un avis de sécurité de dépôt ».
Vous pouvez créer une stratégie de sécurité afin de fournir aux utilisateurs des instructions pour signaler des vulnérabilités de sécurité dans votre projet. Pour plus d’informations, consultez « Ajout d’une stratégie de sécurité à votre dépôt ».
Si vous avez créé un avis de sécurité dans votre dépôt, il est destiné à y demeurer. Nous publions des avis de sécurité pour tous les écosystèmes pris en charge par le graphe de dépendances dans la GitHub Advisory Database sur github.com/advisories. Toute personne peut soumettre une modification pour un avis publié dans la GitHub Advisory Database. Pour plus d’informations, consultez « Modification des avis de sécurité dans la base de données d’avis de GitHub ».
Si un avis de sécurité concerne spécifiquement npm, nous le publions également dans les avis de sécurité npm. Pour plus d’informations, consultez npmjs.com/advisories.
Vous pouvez également rejoindre GitHub Security Lab pour parcourir les rubriques liées à la sécurité et contribuer aux outils et projets de sécurité.
Numéros d’identification CVE
Les GitHub Security Advisories s’appuient sur la liste des CVE (Common Vulnerabilities and Exposures). Le formulaire d’avis de sécurité sur GitHub est un formulaire standardisé qui correspond au format de description d’un CVE.
GitHub est une autorité de numérotation CVE (CNA) et est autorisé à affecter des numéros d’identification CVE. Pour plus d’informations, consultez « À propos de CVE » et « Autorités de numérotation CVE » sur le site web CVE.
Quand vous créez un avis de sécurité pour un dépôt public sur GitHub, vous avez la possibilité de fournir un numéro d’identification CVE existant pour la vulnérabilité de sécurité. Si vous n’avez pas encore de numéro d’identification CVE pour la faille de sécurité de votre projet et que vous souhaitez en obtenir un, vous pouvez effectuer une demande auprès de GitHub. GitHub examine généralement les demandes dans les 72 heures. Une demande de numéro d’identification CVE ne rend pas votre avis de sécurité public. Si votre avis de sécurité est éligible, GitHub lui réserve un numéro d’identification CVE. Nous publierons ensuite les détails CVE une fois que vous aurez rendu public votre avis de sécurité. Toute personne disposant d’autorisations d’administrateur pour un avis de sécurité peut effectuer une demande de numéro d’identification CVE.
Si vous avez déjà un numéro d’identification CVE que vous souhaitez utiliser, par exemple si vous utilisez une autorité de numérotation CVE (CNA) autre que GitHub, ajoutez-le au formulaire d’avis de sécurité. Cela peut se produire, par exemple, si vous souhaitez que l’avis soit cohérent avec d’autres communications que vous prévoyez d’envoyer au moment de la publication. GitHub ne peut pas attribuer de numéro d’identification CVE à votre projet s’il est couvert par une autre CNA.
Une fois que vous avez publié l’avis de sécurité et que GitHub a attribué un numéro d’identification CVE à la vulnérabilité, GitHub publie le CVE dans la base de données MITRE. Pour plus d’informations, consultez « Publication d’un avis de sécurité de dépôt ».
Dependabot alerts pour les avis de sécurité publiés
GitHub examinera chaque avis de sécurité publié, l’ajoutera à la GitHub Advisory Database et pourra utiliser l’avis de sécurité pour envoyer des Dependabot alerts aux référentiels concernés. Si l’avis de sécurité provient d’une duplication, nous n’enverrons une alerte que si la duplication possède un package, publié sous un nom unique, sur un registre de packages public. Ce processus peut prendre jusqu’à 72 heures et GitHub peut vous contacter pour vous demander plus d’informations.
Pour plus d’informations sur Dependabot alerts, consultez « À propos des alertes Dependabot » et « À propos des mises à jour de sécurité Dependabot ». Pour plus d’informations sur la GitHub Advisory Database, consultez Exploration des avis de sécurité dans la base de données GitHub Advisory.