GitHub a profondément revu son programme de bug bounty pour les rapports soumis depuis le 27 juillet 2026. La plateforme distingue désormais un programme public, accessible sous conditions de réputation, et un niveau VIP sur invitation qui concentre les récompenses les plus élevées. Le changement ne porte pas seulement sur les montants. Il répond à un problème devenu opérationnel : l'afflux de rapports faibles, verbeux ou produits avec une assistance IA sans validation suffisante.
Dans une publication précédente, GitHub expliquait qu'un bon signalement doit contenir un résumé court, des étapes de reproduction accompagnées de preuves et une analyse concrète de l'impact. À l'inverse, les longues descriptions théoriques et le remplissage généré par IA ralentissent le triage lorsque la vulnérabilité réelle reste introuvable. La nouvelle organisation cherche donc à déplacer l'incitation du nombre de tickets vers leur qualité.
Cette décision dépasse GitHub. Elle montre comment l'IA générative modifie l'économie de la divulgation de vulnérabilités, pour les chercheurs comme pour les équipes produit.
Deux niveaux pour deux relations de confiance
Le programme public conserve une porte d'entrée, mais avec une grille fixe. GitHub annonce 250 dollars pour une vulnérabilité faible, 2 000 dollars pour une gravité moyenne, 5 000 dollars pour une gravité élevée et 10 000 dollars pour un niveau critique. Les chercheurs invités au programme VIP peuvent recevoir des montants environ trois à quatre fois supérieurs selon la sévérité.
Cette différence rémunère davantage qu'une vulnérabilité. Elle rémunère une relation de confiance établie : capacité à vérifier un résultat, à communiquer clairement, à respecter les règles et à travailler avec l'équipe pendant la correction. Le niveau public sert à découvrir de nouveaux profils, tandis que le niveau VIP offre à GitHub un groupe plus réduit de chercheurs dont le signal est déjà connu.
Pour les nouveaux participants, l'accès public exige aussi un niveau minimal de réputation sur HackerOne. GitHub prévoit un nombre limité d'occasions pour établir cette crédibilité. Ce filtre peut réduire le bruit, mais il augmente également la difficulté d'entrée pour un chercheur compétent qui n'a pas encore d'historique sur la plateforme.
L'IA réduit le coût d'un rapport, pas celui d'une preuve
Un modèle de langage peut transformer quelques notes en texte structuré, expliquer une classe de faille ou proposer des étapes de reproduction. Utilisé correctement, il aide à produire un rapport plus clair, notamment pour un chercheur qui écrit dans une langue étrangère. Il peut aussi générer un script initial ou résumer des journaux volumineux.
Le problème apparaît lorsque la génération remplace la vérification. Un modèle peut inventer une fonction, déduire un impact impossible ou présenter comme exploitable un comportement simplement inhabituel. Le texte obtenu est souvent convaincant : vocabulaire précis, sections bien ordonnées et recommandations familières. Le triage doit pourtant reprendre toute l'analyse depuis le début si aucune requête, trace ou démonstration reproductible ne confirme la conclusion.
L'IA fait donc baisser le coût de production d'un ticket, mais pas le coût de la preuve. Elle peut même transférer ce coût du déclarant vers l'équipe de sécurité. Quand des milliers de personnes peuvent soumettre rapidement des hypothèses, le système de récompense doit distinguer plus fortement l'exploration automatisée d'une découverte validée.
Ce qu'un rapport de qualité doit montrer
La première exigence reste la reproductibilité. Le rapport doit préciser le prérequis, le compte utilisé, la configuration, les requêtes envoyées et le résultat observé. Une capture d'écran seule montre un symptôme, pas toujours sa cause. Un script minimal, des échanges HTTP nettoyés et un environnement de test permettent au triage de confirmer plus rapidement le comportement.
La deuxième est l'impact. Une erreur qui révèle une information déjà publique n'a pas la même portée qu'une lecture entre comptes. Le chercheur doit décrire ce qu'un attaquant réaliste peut obtenir, les permissions nécessaires et les limites rencontrées. Exagérer la sévérité réduit la confiance, même lorsque le bug existe.
La troisième est la concision. Le contexte utile doit rester, mais une explication générique de dix paragraphes sur les injections SQL ne renforce pas un rapport si le produit n'utilise pas SQL à cet endroit. L'assistance IA devrait servir à retirer les ambiguïtés et non à gonfler le volume.
Enfin, les affirmations doivent être séparées des hypothèses. Une phrase telle que "ce comportement pourrait permettre" demande une expérience supplémentaire. Le dire explicitement aide l'équipe à décider si elle doit poursuivre l'analyse sans confondre possibilité et exploitation démontrée.
Les équipes de triage doivent aussi évoluer
Le filtrage par réputation ne suffira pas. Une équipe moderne doit pouvoir regrouper les duplicatas, détecter les descriptions presque identiques et extraire rapidement les éléments vérifiables d'un long rapport. L'IA peut aider de ce côté également, à condition qu'elle assiste un analyste au lieu de fermer automatiquement un ticket.
Les formulaires de soumission peuvent imposer des champs structurés : actif concerné, prérequis, résultat attendu, résultat réel, preuve et impact. Un validateur peut vérifier qu'une pièce jointe existe ou qu'un scénario contient des étapes, sans prétendre déterminer si la faille est réelle. Les réponses rapides sont importantes, car un chercheur sérieux abandonné plusieurs semaines dans une file saturée peut choisir un autre programme.
GitHub promet justement d'investir dans des délais plus courts, des raisonnements de sévérité plus clairs et davantage d'échanges avec la communauté. La grille financière n'est qu'une partie de la réponse. La qualité d'un bug bounty dépend aussi de la manière dont les rapports valides sont accueillis et suivis.
Le risque d'un programme trop fermé
Un niveau VIP améliore le signal moyen, mais il crée un risque de concentration. Les chercheurs réguliers connaissent les méthodes appréciées par l'entreprise et peuvent explorer des zones similaires. Un nouvel arrivant, un universitaire ou un spécialiste d'une technologie marginale peut apporter une approche différente précisément parce qu'il ne fait pas partie du cercle habituel.
Si les récompenses publiques deviennent trop faibles par rapport au temps nécessaire, certaines vulnérabilités peuvent être vendues à des intermédiaires, divulguées ailleurs ou simplement abandonnées. GitHub doit donc conserver une progression lisible vers le niveau VIP et expliquer les décisions de refus. Le programme public ne peut pas être seulement un filtre coûteux supporté par les chercheurs.
Il faut également éviter de confondre utilisation de l'IA et mauvaise recherche. Un rapport assisté par un modèle peut être excellent s'il contient une preuve reproductible et si son auteur comprend chaque affirmation. À l'inverse, un rapport entièrement humain peut rester imprécis. Le critère pertinent est la qualité du résultat, pas l'outil employé.
Une nouvelle discipline pour les chercheurs
Pour les chasseurs de bugs, la stratégie du volume devient moins viable. Avant de soumettre, il faut reproduire sur un compte propre, réduire le scénario au minimum, vérifier le périmètre et conserver les traces. Toute sortie produite par IA doit être relue comme du code venant d'une source non fiable.
La bonne utilisation d'un modèle se situe autour de la recherche : préparer une checklist, reformuler une explication, comparer le comportement à une spécification ou chercher des cas limites. La décision d'affirmer qu'une vulnérabilité existe doit rester fondée sur l'observation.
La refonte de GitHub ne signe pas la fin des bug bounties ouverts. Elle indique que leur ressource rare n'est plus la capacité à recevoir des idées, mais le temps humain nécessaire pour séparer une faille réelle d'un texte plausible. Dans ce nouvel équilibre, la preuve devient plus précieuse que jamais.
