Mises à jour des politiques du programme de bug bounty de GitLab

GitLab a lancé son programme de bug bounty HackerOne pour la première fois en 2018. Nous avons depuis travaillé avec la communauté des chercheurs pour sécuriser notre plateforme DevSecOps complète alimentée par l'IA. Nous sommes ravis d'annoncer les mises à jour des politiques du programme, qui reflètent notre engagement envers la transparence, les retours des chercheurs et nos efforts continus en vue de fournir des attentes claires et des processus rationalisés.

Les changements apportés

Conseils améliorés pour les tests

Nous mettons davantage l'accent sur les environnements de test locaux pour protéger à la fois les chercheurs et notre infrastructure de production. Nous recommandons fortement les tests locaux avec le GitLab Development Kit (GDK) pour la plupart des recherches en sécurité. Le GDK vous donne accès à des fonctionnalités de pointe avant leur publication et vous permet d'expérimenter sans devoir vous préoccuper de l'infrastructure de production.

Si vous devez démontrer l'impact d'une attaque par déni de service (DoS), nous vous recommandons de le tester sur une instance GitLab auto-gérée avec des spécifications et des ressources égales ou supérieures aux exigences d'installation des instances GitLab auto-gérées.

Pour les vulnérabilités qui requièrent l'architecture de production de GitLab.com, vous devez utiliser des comptes de test créés avec votre alias de courrier électronique HackerOne : [email protected].

Portée affinée pour une meilleure concentration

Nous avons clarifié plusieurs domaines de portée en fonction des retours de la communauté :

Les attaques par DoS sortent du champ d'application : des exceptions peuvent être envisagées pour les vulnérabilités DoS au niveau de l'application qui entraînent une interruption totale persistante du service et peuvent être exécutées via des points de terminaison non authentifiés (exemples : ReDoS, bombes logiques, etc.).

Injection de prompt : l'injection de prompt autonome sort du champ d'application, mais peut être admise si elle sert de vecteur initial pour causer un préjudice au-delà de sa limite de sécurité.

Métadonnées et énumération : la collecte générale d'informations sort du champ d'application, tandis que les violations de confidentialité exposant des données confidentielles tombent dans le champ d'application. Nous avons fourni de nouveaux exemples détaillés qui distinguent ces deux types de problèmes sur la page des politiques du programme.

Période de transition pour les chercheurs

Nous sommes conscients que les changements de politique peuvent créer de l'incertitude pour les chercheurs qui mènent des enquêtes actives. Pour préserver la confiance pendant cette transition et éviter d'interférer avec les importantes recherches déjà en cours :

• GitLab offre un délai de grâce de 7 jours pour les rapports DoS soumis avant le 22 janvier 2026 à 21 h 00, heure du Pacifique (23 janvier 2026 à 6 h 00, heure française). Les rapports soumis avant cette date seront évalués selon notre politique précédente.

Votre investissement dans la sécurité de GitLab nous tient à cœur, et nous nous engageons à honorer la politique dans le cadre de laquelle vous avez commencé votre recherche.

Notre engagement envers la communauté

Ces changements reflètent notre engagement profond envers la communauté des chercheurs à travers trois principes clés.

1. Nous mettons l'accent sur la transparence en établissant des limites plus claires et des critères objectifs qui réduisent l'ambiguïté et préviennent les différends.

2. Nous renforçons la sécurité grâce à des conseils améliorés sur la plateforme de test qui protègent à la fois les systèmes de production et les chercheurs contre les interruptions accidentelles de service.

3. Nous assurons l'équité grâce à des normes d'évaluation cohérentes et à des dispositions qui garantissent un traitement équitable pour tous les chercheurs, y compris ceux qui participent déjà au programme.

Les ajustements apportés à la portée contribuent également à la durabilité du programme, car ils concentrent les ressources sur les problèmes de sécurité à fort impact et maintiennent une couverture large.

Lancez-vous

Envie de contribuer à la sécurité de GitLab ?

• Nouveaux chercheurs : visitez notre page consacrée au programme HackerOne.
• Configurer des tests locaux : téléchargez le GitLab Development Kit.
• Examiner les politiques : consultez notre documentation complète pour obtenir des directives détaillées.
• Comprendre l'évaluation de la gravité : explorez notre calculateur CVSS.

Nous remercions la communauté des chercheurs dont l'engagement continu aide à maintenir la sécurité de GitLab. Votre expertise et votre dévouement font une réelle différence pour des millions d'utilisateurs dans le monde.

Des questions sur ces changements ? Contactez notre équipe en créant un ticket dans notre projet de questions HackerOne sur GitLab.