À propos de la divulgation coordonnée des vulnérabilités de sécurité

À propos de la divulgation des vulnérabilités dans le secteur d’activité

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.

Le signalement initial d’une vulnérabilité est réalisé en privé et les détails complets ne sont publiés qu’une fois que le chargé de maintenance a reconnu le problème et, dans l’idéal, mis à disposition des corrections ou un correctif, parfois avec un délai afin d’accorder plus de temps pour l’installation des correctifs. Pour en savoir plus, consultez la série d’aide-mémoire OWASP sur la divulgation des vulnérabilités sur le site web OWASP Cheat Sheet Series.

Bonnes pratiques pour les rapporteurs de vulnérabilité

Il est recommandé de signaler les vulnérabilités en privé aux chargés de maintenance. Dans la mesure du possible, en tant que rapporteur de vulnérabilité, nous vous recommandons d’éviter :

• De divulguer publiquement la vulnérabilité sans donner aux chargés de maintenance l’occasion d’apporter une correction
• De contourner les chargés de maintenance
• De divulguer la vulnérabilité avant qu’une version corrigée du code soit disponible
• D’espérer une compensation en échange du signalement d’un problème, alors qu’aucun programme de primes publiques n’existe

Il est acceptable que les rapporteurs de vulnérabilité divulguent publiquement une vulnérabilité après une certaine période, s’ils ont essayé de contacter les chargés de maintenance et qu’ils n’ont pas reçu de réponse, ou s’ils les ont contactés et qu’ils ont été invités à attendre trop longtemps.

Nous recommandons aux rapporteurs de vulnérabilité d’indiquer clairement les conditions de leur politique de divulgation dans le cadre de leur processus de signalement. Même si le rapporteur de vulnérabilité n’adhère pas à une politique stricte, il est judicieux de définir des attentes claires pour les chargés de maintenance en termes de chronologies sur les divulgations de vulnérabilité prévues. Pour obtenir un exemple de stratégie de divulgation, consultez la stratégie de divulgation de Security Lab sur le site web GitHub Security Lab.

Bonnes pratiques pour les chargés de maintenance

En tant que chargé de maintenance, il est recommandé d’indiquer clairement comment et où vous souhaitez recevoir les rapports des vulnérabilités. Si ces informations ne sont pas clairement disponibles, les rapporteurs de vulnérabilité ne savent pas comment vous contacter et peuvent recourir à l’extraction d’adresses e-mail de développeur à partir d’historiques de commit Git pour essayer de trouver un contact de sécurité approprié. Cela peut entraîner des frictions, des pertes de rapports ou la publication de rapports non résolus.

Les chargés de maintenance doivent divulguer les vulnérabilités en temps opportun. S’il existe une vulnérabilité de sécurité dans votre dépôt, nous vous recommandons  :

• De traiter la vulnérabilité comme un problème de sécurité plutôt que comme un bogue simple, à la fois dans votre réponse et dans votre divulgation. Par exemple, vous devez mentionner explicitement que le problème est une vulnérabilité de sécurité dans les notes de publication.
• D’accuser réception du rapport de vulnérabilité le plus rapidement possible, même si aucune ressource immédiate n’est disponible à des fins d’investigation. Cette action envoie le message selon lequel vous êtes rapide à répondre et à agir et il définit une tonalité positive pour le reste de l’interaction entre vous et le rapporteur de vulnérabilité.
• D’impliquer le rapporteur de vulnérabilité quand vous vérifiez l’impact et la véracité du rapport. Il est probable que le rapporteur de vulnérabilité ait déjà passé du temps à envisager la vulnérabilité dans divers scénarios, dont certains ont pu vous échapper.
• De corriger le problème d’une manière qui vous semble adaptée, en prenant en compte les préoccupations et les avis communiqués par le rapporteur de vulnérabilité. Souvent, le rapporteur de vulnérabilité a connaissance de certains cas particuliers et contournements de correction qui sont faciles à rater sans expérience de recherche en matière de sécurité.
• De reconnaître toujours le rapporteur de vulnérabilité quand vous créditez la découverte.
• D’essayer de publier un correctif dès que possible.
• De veiller à mettre l’écosystème plus large au courant du problème et de sa correction quand vous divulguez la vulnérabilité. Il n’est pas rare qu’un problème de sécurité reconnu soit résolu dans la branche de développement actuelle d’un projet, mais que le commit ou la version ultérieure ne soit pas explicitement marqué comme correctif de sécurité ou version. Cela peut entraîner des problèmes avec les consommateurs en aval.

La publication des détails d’une vulnérabilité de sécurité n’a pas lieu d’être embarrassante pour les chargés de maintenance. Les vulnérabilités de sécurité sont présentes partout dans les logiciels, et les utilisateurs font confiance aux chargés de maintenance qui ont un processus clair et établi pour divulguer les vulnérabilités de sécurité dans leur code.

À propos du signalement et de la divulgation de vulnérabilités dans les projets hébergés sur GitHub

Il existe deux processus disponibles sur GitHub :

• Processus standard : les rapporteurs de vulnérabilité entrent en contact avec les chargés de maintenance de dépôt, en utilisant les informations de contact situées dans la stratégie de sécurité du dépôt. Les chargés de maintenance de dépôt créent ensuite un brouillon d’avis de dépôt si nécessaire.
• Signalement privé des vulnérabilités : les rapporteurs de vulnérabilité divulguent les détails des vulnérabilités directement et en privé aux chargés de maintenance de dépôt en proposant un brouillon d’avis de dépôt et en fournissant des détails sur leurs résultats.

Processus standard

Le processus de création de rapports et de divulgation de vulnérabilités pour les projets sur GitHub est le suivant :

Si vous êtes un rapporteur de vulnérabilité (par exemple, un chercheur en sécurité) qui souhaite signaler une vulnérabilité, vérifiez d’abord s’il existe une stratégie de sécurité pour le dépôt associé. Pour plus d’informations, consultez « Ajout d’une stratégie de sécurité à votre dépôt ». S’il en existe une, suivez-la pour comprendre le processus avant de contacter l’équipe de sécurité pour ce dépôt.

S’il n’existe pas de stratégie de sécurité en place, la méthode la plus efficace pour établir un moyen privé de communication avec les chargés de maintenance consiste à créer un problème demandant un contact de sécurité préféré. Il est important de noter que le problème est immédiatement visible publiquement. De ce fait, il ne doit pas inclure d’informations sur le bogue. Une fois la communication établie, vous pouvez suggérer aux chargés de maintenance de définir une stratégie de sécurité pour une utilisation ultérieure.

          _Pour npm uniquement_ - Si nous recevons un rapport de programmes malveillants dans un package npm, nous essayons de vous contacter en privé. Si vous ne résolvez pas le problème en temps voulu, nous le divulguons. Pour en savoir plus, consultez [Signalement de programmes malveillants dans un package npm](https://docs.npmjs.com/reporting-malware-in-an-npm-package) sur le site web npm Docs.

Si vous avez trouvé une vulnérabilité de sécurité dans GitHub, signalez la vulnérabilité via notre processus de divulgation coordonné. Pour plus d’informations, consultez le site web GitHub Security Bug Bounty .

Si vous êtes chargé de maintenance, vous pouvez prendre possession du processus au tout début du pipeline en configurant une stratégie de sécurité pour votre dépôt, ou en rendant clairement disponibles les instructions de signalement de vulnérabilités de sécurité, par exemple dans le fichier README de votre projet. Pour en savoir plus sur l’ajout d’une stratégie de sécurité, consultez Ajout d’une stratégie de sécurité à votre dépôt. S’il n’existe aucune stratégie de sécurité, il est probable qu’un rapporteur de vulnérabilité tente de vous envoyer un e-mail ou de vous contacter en privé. Un utilisateur peut également ouvrir un problème (public) avec les détails d’un problème de sécurité.

En tant que mainteneur, pour divulguer une vulnérabilité dans votre code, vous créez d’abord un brouillon d'avis de sécurité dans le référentiel du paquet dans GitHub. 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é. Pour plus d’informations, consultez À propos des avis de sécurité des référentiels.

Pour bien démarrer, consultez Création d’un avis de sécurité de dépôt.

Signalement privé des vulnérabilités

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. Consultez « Configuration de rapports de vulnérabilité privés pour un dépôt ».

Les rapports sur les vulnérabilités privées offrent aux chercheurs de sécurité un moyen sécurisé et structuré de divulguer en privé les risques de sécurité aux responsables de la maintenance des référentiels directement au sein de GitHub. Lorsqu’une vulnérabilité est signalée, les gardiens de référentiel sont immédiatement avertis, ce qui leur permet de passer en revue et de répondre sans risque de divulgation de public prématuré.

Sans conseils clairs sur la façon de contacter les gardiens de la sécurité, les chercheurs en sécurité peuvent se sentir obligés de divulguer publiquement des vulnérabilités, par exemple en publiant sur les médias sociaux, en ouvrant des problèmes publics ou en contactant des mainteneurs par le biais de canaux informels, ce qui peut exposer les utilisateurs à des risques inutiles.

Pour les chercheurs en sécurité, les avantages de l’utilisation des rapports de vulnérabilité privés sont les suivants :

• Un moyen clair et structuré de contacter les gestionnaires de maintenance
• Processus plus fluide pour la divulgation et la discussion des détails des vulnérabilités
• Possibilité de discuter des détails des vulnérabilités en privé avec le maintenance du référentiel
• Réduire le risque que les détails concernant les vulnérabilités soient dévoilés au grand public avant qu'un correctif ne soit disponible.

Pour les responsables de la maintenance, les avantages de l’utilisation de rapports de vulnérabilités privés sont les suivants :

• Réception de rapports dans la même plateforme où ils sont résolus
• Chercheurs en sécurité qui créent ou lancent le rapport consultatif pour le compte des gardiens
• Réduction du risque de vulnérabilités dans l’œil public avant la disponibilité d’un correctif
• L’occasion de discuter des détails des vulnérabilités en privé avec les chercheurs en sécurité et de collaborer sur le correctif

Les chercheurs en sécurité peuvent également utiliser l’API REST pour signaler en privé les failles de sécurité. Consultez « Points de terminaison d’API REST pour les avis de sécurité de référentiels ».

Prochaines étapes

Si vous êtes chercheur en sécurité, consultez Signalement privé d’une vulnérabilité de sécurité pour savoir comment signaler en privé une vulnérabilité à un gestionnaire de maintenance de référentiel.

Si vous êtes un responsable de référentiel, consultez Configuration de rapports de vulnérabilité privés pour un dépôt pour activer la création de rapports de vulnérabilités privées pour votre dépôt, ou Création d’une configuration de sécurité personnalisée pour la gérer au sein de votre organisation.