Contexte et motivations
GitHub a constaté une hausse importante du nombre de rapports de sécurité soumis via le canal Private Vulnerability Reporting. Les mainteneurs d’open source signalent que les soumissions massives, souvent générées par des bots d’IA, « enterrent les rapports qui comptent ». Cette surcharge réduit la capacité des équipes à examiner rapidement les véritables failles, créant un goulot d’étranglement dans le processus de divulgation.
Mécanisme des limites de rapports
Pour contrer ce phénomène, GitHub a introduit des limites de taux quotidiennes sur les nouveaux rapports privés. La restriction s’applique à la fois par dépôt et globalement sur la plateforme. Les seuils exacts ne sont pas publiés ; l’unique moyen de les connaître est de dépasser la limite et de recevoir le message d’erreur correspondant. Une fois la limite atteinte, l’utilisateur doit attendre jusqu’au jour suivant avant de pouvoir soumettre un nouveau rapport.
Ces limites n’affectent pas les rapports déjà créés : les commentaires et les échanges en cours restent accessibles, ce qui préserve la continuité de l’investigation même si l’expéditeur a atteint le plafond quotidien.
Options de personnalisation et formulaires structurés
Les administrateurs de dépôts peuvent ajuster le plafond quotidien global via les paramètres Settings → Advanced Security → Private vulnerability reporting. Ils disposent également d’une liste blanche permettant d’exempter des chercheurs de confiance, du personnel de sécurité interne ou des participants à des programmes de bug bounty. Cette flexibilité vise à réduire le bruit tout en maintenant l’ouverture aux contributions de haute qualité.
Le même jour, GitHub a déployé des formulaires structurés pour les rapports privés. Au lieu d’un champ texte libre, les mainteneurs peuvent exiger des informations précises, telles qu’une preuve de concept reproductible, facilitant ainsi l’évaluation initiale de la vulnérabilité.
Impacts et limites
Les limites de taux offrent un moyen immédiat de diminuer le volume de soumissions automatisées, mais elles introduisent plusieurs contraintes. Un seuil trop bas risque de bloquer des chercheurs légitimes qui travaillent sur plusieurs projets simultanément, augmentant la friction et potentiellement décourageant la collaboration. À l’inverse, un seuil élevé pourrait ne pas atténuer le problème initial de surcharge.
En outre, l’absence de transparence sur les valeurs exactes empêche les équipes de planifier leurs flux de travail de manière prévisible. La solution repose sur la capacité des mainteneurs à calibrer leurs propres limites et à gérer la liste blanche, ce qui demande une compréhension fine du profil de leurs contributeurs.
Enfin, les formulaires structurés améliorent la qualité des données d’entrée, mais n’abordent pas les désaccords sur la gravité ou la portée des vulnérabilités. La mesure reste donc centrée sur le contrôle du volume, laissant les aspects de validation technique et de négociation aux processus humains existants.
