Les propriétaires et les administrateurs de dépôts publics peuvent activer les rapports de vulnérabilités privés sur leurs dépôts. Pour plus d’informations, consultez « Configuration de rapports de vulnérabilité privés pour un dépôt ».
Note
- Si vous disposez d’autorisations d’administration ou de sécurité pour un dépôt public, vous n’avez pas besoin de soumettre un rapport de vulnérabilité. Au lieu de cela, vous pouvez créer directement un brouillon d’avis de sécurité. Pour plus d’informations, consultez « Création d’un avis de sécurité de dépôt ».
- La possibilité de signaler en privé une vulnérabilité dans un dépôt n’est pas liée à la présence d’un fichier
SECURITY.md
dans la racine ou le répertoiredocs
de ce dépôt.- Le fichier
SECURITY.md
contient la stratégie de sécurité pour le dépôt. Les administrateurs du dépôt peuvent ajouter et utiliser ce fichier pour fournir des instructions publiques sur la façon de signaler une vulnérabilité de sécurité dans leur dépôt. Pour plus d’informations, consultez « Ajout d’une stratégie de sécurité à votre dépôt ». - Vous pouvez uniquement signaler une vulnérabilité en privé pour les dépôts où la création de rapports de vulnérabilités privées est activée, et vous n’avez pas besoin de suivre les instructions du fichier
SECURITY.md
. Ce processus de création de rapports est entièrement privé et GitHub avertit directement les administrateurs du dépôt de l’envoi de votre rapport.
- Le fichier
À propos du signalement privé d’une vulnérabilité de sécurité
Les chercheurs en sécurité se sentent souvent responsables d’alerter les utilisateurs sur une vulnérabilité qui pourrait être exploitée. S’il n’y a pas d’instructions claires sur la façon de contacter les chargés de maintenance du référentiel contenant la vulnérabilité, les chercheurs en sécurité risquent de ne pas avoir d’autre choix que de publier le rapport sur la vulnérabilité sur les réseaux sociaux, d’envoyer des messages directement au chargé de maintenance ou même de créer des problèmes publics. Cette situation peut potentiellement conduire à une divulgation publique des détails de la vulnérabilité.
Les rapports de vulnérabilités privés permettent aux chercheurs en sécurité de signaler les vulnérabilités au chargé de maintenance de dépôt directement au moyen d’un simple formulaire.
Pour les chercheurs en sécurité, les avantages de l’utilisation des rapports de vulnérabilité privés sont les suivants :
- Moins de frustration et moins de temps passé à essayer de trouver comment contacter le chargé de maintenance.
- Un processus plus fluide pour la divulgation et la discussion des détails de la vulnérabilité.
- La possibilité de discuter des détails des vulnérabilités en privé avec le chargé de maintenance de dépôt.
Note
Si le rapport de vulnérabilité privé n'est pas activé dans le référentiel, vous devez lancer le processus de rapport en suivant les instructions de la politique de sécurité du référentiel, ou créer un problème en demandant aux responsables d'indiquer un contact de sécurité privilégié. Pour plus d’informations, consultez « À propos de la divulgation coordonnée des vulnérabilités de sécurité ».
Signalement privé d’une vulnérabilité de sécurité
Si un référentiel public a un rapport privé de vulnérabilité activé, n'importe qui peut signaler en privé une vulnérabilité de sécurité aux chargés de maintenance du référentiel. Les utilisateurs peuvent également évaluer la sécurité générale d’un dépôt public et suggérer une stratégie de sécurité. Pour plus d’informations, consultez « Évaluation des paramètres de sécurité d’un dépôt ».
-
Sur GitHub, accédez à la page principale du référentiel.
-
Sous le nom du dépôt, cliquez sur Sécurité. Si vous ne voyez pas l’onglet « Sécurité », sélectionnez le menu déroulant et cliquez sur Sécurité.
-
Cliquez sur Signaler une vulnérabilité pour ouvrir le formulaire d’avis.
-
Remplissez le formulaire de détails de l’avis.
Tip
Dans ce formulaire, seuls le titre et la description sont obligatoires. (Dans le formulaire général de brouillon d’avis de sécurité, qui est lancé par le chargé de maintenance de dépôt, la spécification de l’écosystème est également requise.) Toutefois, nous recommandons que les chercheurs en sécurité fournissent autant d’informations que possible dans le formulaire afin que les chargés de maintenance puissent prendre une décision éclairée au sujet du rapport soumis. Vous pouvez adopter le modèle utilisé par nos chercheurs en sécurité depuis le GitHub Security Lab, qui est disponible dans le « référentiel
github/securitylab
. »Pour plus d’informations sur les champs disponibles et des conseils sur le remplissage du formulaire, consultez « Création d’un avis de sécurité de dépôt » et « Meilleures pratiques pour l’écriture des avis de sécurité de référentiels ».
-
En bas du formulaire, cliquez sur Envoyer le rapport. GitHub affiche un message vous informant que les chargés de maintenance ont été avertis et que vous avez un crédit en attente pour cet avis de sécurité.
Tip
Quand le rapport est soumis, GitHub ajoute automatiquement le rapporteur de la vulnérabilité en tant que collaborateur et utilisateur crédité sur l’avis proposé.
-
Si vous souhaitez commencer à résoudre le problème, cliquez sur Démarrer une duplication privée temporaire. Notez que seul le chargé de maintenance du dépôt peut fusionner les modifications de cette duplication privée dans le dépôt parent.
Les étapes suivantes dépendent de l’action effectuée par le chargé de maintenance de dépôt. Pour plus d’informations, consultez « Gestion des vulnérabilités de sécurité signalées en privé ».