Coordinated vulnerability disclosure
← Politiques

GitLab : Politique de divulgation responsable

Veuillez envoyer un courriel à security@gitlab.com pour signaler toute vulnérabilité de sécurité. Nous accuserons réception de votre rapport de vulnérabilité le jour ouvrable suivant et nous nous efforcerons de vous envoyer régulièrement des nouvelles de nos progrès. Si vous souhaitez connaître l'état de votre divulgation, n'hésitez pas à nous écrire à nouveau. Si vous souhaitez chiffrer votre courriel de divulgation, écrivez-nous pour demander notre clé PGP.

Vous pouvez aussi nous envoyer votre rapport via HackerOne.

Veuillez ne pas demander de rémunération pour le signalement de vulnérabilités. Si vous le souhaitez, nous reconnaîtrons publiquement votre divulgation responsable. Nous essayons également de rendre public le ticket confidentiel après l'annonce de la vulnérabilité ; pour un exemple, voyez notre ticket sur la fonction d'usurpation d'identité. HackerOne rend aussi les rapports de bogues publics après 30 jours si aucune des parties ne s'y oppose ; pour un exemple, voyez le rapport d'un XSS persistant sur la page d'un projet public.

Vous n'êtes pas autorisé à rechercher des vulnérabilités sur GitLab.com lui-même. GitLab est un logiciel libre ; vous pouvez en installer une copie vous-même et tester dessus. Vous pouvez télécharger CE, EE ou le GitLab Development Kit. Si vous souhaitez tester sans installer GitLab vous-même, contactez-nous pour organiser l'accès à un serveur de préproduction (staging).

Vous trouverez plus de détails sur la façon dont nous traitons les versions de sécurité ici.

Sur notre site web, vous pouvez en savoir plus sur la disponibilité et la sécurité de GitLab.com. Les problèmes de sécurité qui ne sont pas des vulnérabilités sont visibles sur notre suivi de tickets public.

Tickets confidentiels

Lorsqu'une vulnérabilité est découverte, nous créons un ticket confidentiel pour la suivre en interne. Les correctifs de sécurité sont poussés vers dev.gitlab.org, qui n'est pas accessible au public, et fusionnés dans la branche security. Ils ne doivent pas apparaître sur GitLab.com avant que la version de sécurité ait été annoncée et que des paquets mis à jour soient disponibles.

Les détails figurent dans notre processus de publication critique.