La communauté de recherche en sécurité est l’un des plus grands atouts de GitHub. Chaque année, des chercheurs du monde entier nous aident à trouver et à corriger les vulnérabilités, rendant ainsi la plateforme plus sûre pour plus de 180 millions de développeurs. Notre programme de bug bounty existe parce que nous pensons que la collaboration avec des chercheurs externes est l’un des moyens les plus efficaces d’améliorer la sécurité, et nous y restons profondément attachés.
Mais comme tout programme de bug bounty, nous nous adaptons à un paysage changeant. Nous souhaitons partager ce que nous constatons, ce que nous faisons à ce sujet et notre vision des limites de sécurité d’une plateforme comme GitHub.
Le problème du volume
Au cours de l’année écoulée, le volume de soumissions dans l’ensemble du secteur a considérablement augmenté. De nouveaux outils, notamment l’IA, ont abaissé les barrières à l’entrée de la recherche en matière de sécurité, ce qui constitue à bien des égards une évolution positive. Plus de personnes explorant les surfaces d’attaque signifie plus d’opportunités de trouver de vrais problèmes.
Cependant, parallèlement à l’augmentation du nombre de rapports légitimes, nous avons constaté une forte augmentation des soumissions qui ne démontrent pas d’impact réel sur la sécurité. Il s’agit notamment de rapports sans preuve de concept, de scénarios d’attaque théoriques qui ne résistent pas à un examen minutieux et de conclusions déjà couvertes par notre liste d’inéligibles publiée. Ce n’est pas unique à GitHub. Les programmes de l’ensemble du secteur sont aux prises avec le même défi, et certains ont été complètement fermés.
Nous ne voulons pas aller dans cette direction. Au lieu de cela, nous souhaitons investir dans l’amélioration de notre programme.
Qu’est-ce qui fait une soumission solide
Nous élevons la barre en ce qui concerne ce que nous considérons comme une soumission complète. À l’avenir, les rapports seront évalués plus strictement en fonction des critères suivants :
- Une preuve de concept fonctionnelle avec un impact démontré sur la sécurité. Montrez-nous l’impact, ne vous contentez pas de le décrire. Que pourrait réellement réaliser un attaquant ? Nous avons besoin d’une preuve de concept fonctionnelle qui démontre une exploitation réelle et un impact concret sur la sécurité. Montrez-nous la frontière qui peut être franchie, et pas seulement celle qui existe théoriquement. Si votre rapport indique “cela pourrait conduire à…” mais n’indique pas que c’est le cas c’est le cas, il est incomplet.
- Conscience de la portée et des résultats non éligibles. Avant de soumettre, consultez notre portée et liste des résultats non éligibles. Les rapports couvrant des catégories connues non éligibles (configuration DMARC/SPF/DKIM, énumération des utilisateurs, en-têtes de sécurité manquants sans chemin d’attaque démontré, et autres) seront fermés comme non applicables, ce qui peut avoir un impact sur votre signal HackerOne et votre réputation.
- Validation avant soumission. Quels que soient les outils que vous utilisez (scanners, analyse statique, assistants IA), vous devez valider le résultat avant de soumettre. Un faux positif examiné manuellement est détecté avant qu’il ne fasse perdre du temps à quiconque. Celui qui n’en a pas, c’est juste le bruit.
Nous accueillons l’IA dans la recherche sur la sécurité
Nous voulons être explicites à ce sujet : nous n’avons aucun problème avec le fait que les chercheurs utilisent des outils d’IA. L’IA est un multiplicateur de force et nous nous attendons à ce qu’elle joue un rôle croissant dans la recherche sur la sécurité. Nous utilisons l’IA dans nos propres programmes de sécurité interne, et nous constatons que les meilleurs chercheurs externes font de même. Nous nous en réjouissons.
Ce dont nous avons besoin, c’est de la même norme à laquelle nous nous sommes toujours attendus : la validation. Une découverte assistée par l’IA qui a été vérifiée, reproduite et soumise avec une preuve de concept fonctionnelle est une excellente soumission. Un résultat non validé soumis tel quel sans reproduction ni impact démontré ne l’est pas. Ce n’est pas une nouvelle norme. C’est la même norme que nous appliquons à la sortie du scanner, à l’analyse statique ou à tout autre outil. Le chercheur humain est responsable de l’exactitude de la soumission.
Nous demandons également aux chercheurs de maintenir des rapports concis et structurés. Un rapport solide comporte trois éléments : un bref résumé du problème, des étapes claires à reproduire avec des preuves à l’appui (captures d’écran, requêtes HTTP, sortie du terminal) et une déclaration d’impact expliquant ce qu’un attaquant peut réellement réaliser. C’est ça. Les rapports verbeux tels que les récits théoriques de plusieurs pages, le contexte d’arrière-plan reposé ou les éléments de remplissage générés par l’IA ralentissent le tri car les découvertes réelles sont enterrées. Plus votre rapport est clair et direct, plus vite nous pouvons y donner suite.
Les outils n’ont pas d’importance. La qualité du travail oui.
Comprendre le modèle de sécurité de GitHub : responsabilité partagée
Un modèle que nous observons fréquemment mérite sa propre discussion. De nombreux rapports décrivent des scénarios dans lesquels un utilisateur interagit avec du contenu contrôlé par un attaquant (un référentiel malveillant, un problème contrefait, un code non fiable) et subit un résultat indésirable. Ces rapports sont souvent bien rédigés et leurs observations sont techniquement précises, mais ils ne comprennent pas où se situe la limite de sécurité.
Nous investissons massivement dans des systèmes et des équipes dédiés à la détection et au traitement des contenus malveillants sur l’ensemble de la plate-forme, de l’analyse automatisée à l’examen manuel. Cela dit, GitHub fonctionne sur un modèle de responsabilité partagée. Les utilisateurs sont responsables de :
- Choisir les référentiels, les problèmes et le code auxquels ils font confiance. GitHub héberge plus de 600 millions de référentiels. Tous ne sont pas bénins. Les utilisateurs sont censés faire preuve de jugement sur les objets avec lesquels ils interagissent.
- Examiner le contenu avant de l’exécuter ou d’interagir avec celui-ci. Cela s’applique au code, aux scripts, aux flux de travail et à tout autre contenu exécutable.
- Comprendre que cloner un référentiel signifie choisir de faire confiance à ce code. Les hooks Git, les scripts de build et autres automatisations au niveau du référentiel s’exécutent parce que l’utilisateur a choisi d’extraire ce référentiel.
- Configurer son propre environnement en toute sécurité. La gestion des jetons, le stockage des identifiants et les paramètres de sécurité locaux relèvent de la responsabilité de l’utilisateur.
Lorsqu’une « attaque » oblige la victime à rechercher activement et à interagir avec un contenu contrôlé par l’attaquant (clonage d’un dépôt malveillant, demande à un outil d’IA d’analyser du code non fiable, ouverture d’un fichier contrefait), la limite de sécurité est la décision de l’utilisateur de faire confiance à ce contenu. Ces scénarios ne représentent généralement pas un contournement des contrôles de sécurité de GitHub.
Exemples courants
Pour aider les chercheurs à calibrer, voici les modèles que nous observons régulièrement et qui relèvent d’une responsabilité partagée :
| Scénario | Pourquoi c’est une responsabilité partagée |
|---|---|
| Injection rapide via le contenu que l’utilisateur a choisi de transmettre à un outil d’IA | L’utilisateur a décidé de lui faire confiance content |
| Git hooke ou filtre l’exécution de code dans un dépôt que l’utilisateur a extrait | Voici comment Git fonctionne par conception |
| Contenu malveillant dans un référentiel cloné par l’utilisateur | Le clonage est un acte de confiance |
| LLM produit une sortie inattendue lors du traitement d’entrées non fiables | L’utilisateur a choisi pour fournir cette contribution |
La recherche dans ces domaines reste extrêmement précieuse. Si vous pensez avoir trouvé un angle mort dans nos défenses (un moyen de contourner un contrôle de sécurité réel qui affecte les utilisateurs sans les obliger à faire activement confiance à un contenu malveillant), c’est exactement ce dont nous voulons entendre parler. Ces conclusions font partie des soumissions les plus marquantes que nous recevons. Et si vous rencontrez du contenu qui enfreint nos conditions d’utilisation, veuillez signalez-le.
Ce que cela signifie pour les chercheurs
Si vous soumettez déjà des recherches de qualité, merci. Rien ne change pour vous, sauf des temps de réponse plus rapides grâce à la réduction du bruit de la file d’attente.
Si vous débutez avec le bug bounty, bienvenue ! Prenez quelques minutes pour lire notre portée, examiner la liste des éléments non éligibles et investir dans une preuve de concept fonctionnelle avant de soumettre. Les soumissions de qualité des nouveaux chercheurs sont toujours appréciées.
Si vous avez donné la priorité au volume, nous vous encourageons à privilégier la profondeur. Une découverte bien documentée et validée vaut plus de 10 découvertes spéculatives, tant en termes de primes que de réputation. Les chercheurs qui gagnent le plus grâce à notre programme sont ceux qui vont en profondeur.
Modifications dans la façon dont nous récompensons les découvertes à faible risque
Toutes les soumissions valides ne représentent pas un risque de sécurité significatif. Certains rapports identifient des opportunités de renforcement ou des lacunes dans la documentation qui, bien que non exploitables, conduisent néanmoins à des améliorations que nous choisissons d’apporter. Nous apprécions ce travail.
À l’avenir, nous mettrons à jour la façon dont nous traitons ces cas. Les soumissions qui ne démontrent pas d’impact significatif sur la sécurité mais qui aboutissent à un correctif de code ou de documentation seront reconnues avec un cadeau GitHub plutôt qu’avec une prime. Cela nous permet de reconnaître la contribution tout en concentrant nos ressources Bounty sur les résultats qui ont le plus grand impact sur la sécurité de la plateforme.
Nous préférons voir les chercheurs investir leur temps dans des recherches plus approfondies et à fort impact et être rémunérés en conséquence plutôt que d’optimiser le volume de résultats à faible risque.
Regard vers l’avenir
Nous nous engageons à faire du programme de bug bounty de GitHub l’un des meilleurs du secteur, pour les chercheurs et pour la sécurité de la plateforme. Cela signifie un tri plus rapide, une communication plus claire et la garantie que les résultats valides reçoivent l’attention et la compensation qu’ils méritent. L’augmentation des normes de qualité fait partie de cet investissement.
Les chercheurs en sécurité rendent GitHub plus sûr pour tous les développeurs qui en dépendent. Ce travail est important et nous ne le tenons pas pour acquis.
Bon piratage ! 🚀
Le message Relever la barre : qualité, responsabilité partagée et avenir du programme de primes aux bogues de GitHub est apparu en premier sur Le GitHub Blog.
Bir yanıt yazın