Au tour de Google de s’avouer dépassé par la « bouillie IA ».

Pour ce motif, l’entreprise a partiellement mis en pause un de ses bug bountys publics. En l’occurrence, l’Open Source Vulnerability Rewards Programs, qui englobe ses projets en source ouverte.

Depuis le 1^er octobre, elle n’accepte plus de soumissions pour des « vulnérabilités produit ». C’est-à-dire des problèmes de conception ou d’implémentation qui « entraînent une vulnérabilité affectant considérablement la confidentialité ou l’intégrité des données utilisateur ».

Elle accepte en revanche toujours celles qui relèvent de la catégorie « compromission de la supply chain » (risques pour l’intégrité d’une source ou d’un build). Des exceptions pourront par ailleurs être faites pour les projets qui alimentent l’écosystème Google Cloud, dans le cadre du bug bounty qui lui est dédié (Cloud Vulnerability Reward Program).

Google se donne jusqu’au premier trimestre 2027 pour faire évoluer la partie « vulnérabilités produit ». En attendant, il invite à se tourner vers son Patch Rewards Program. Celui-ci couvre les projets open source externe pour lesquels Google a signalé des vulnérabilités, ainsi que ceux intégrés dans OSS-Fuzz… et une centaine d’autres parmi lesquels :

• Serveurs web et mai (Apache httpd, nginx, Postfix, Sendmail…)
• CMS (Drupal, Joomla, Mangenta, PrestaShop, WordPress…)
• Frameworks web (Angular, Dart, Go, jQuery, Struts…)
• Gestionnaires de paquets (apt, npm, pip, yum)
• Services réseau (BIND, OpenSSH, OpenVPN…)
• Bibliothèques de décompression (7z, bzip2, gzip, tar…)

De premières mesures prises au printemps

Google avait déjà serré la vis au printemps, pour le même motif : nette augmentation de rapports faits par l’IA et truffés d’éléments incorrects ou non significatifs au regard du modèle de sécurité des projets concernés. Il avait entériné un système à quatre niveaux de priorité :

• Flagship (projets les plus critiques : Angular, Bazel, Golang…)
• Important (projets à forte empreinte communautaire)
• Standard (projets actifs, stables, disponibles dans les principaux gestionnaires de paquets)
• Faible (projets expérimentaux et/ou à petit périmètre)

Aux deux premiers niveaux, Google avait imposé, pour les vulnérabilités de corruption mémoire, une reproduction OSS-Fuzz ou un fix fusionné dans le dépôt cible. Aux deux autres niveaux, il avait supprimé les récompenses pour les « vulnérabilités produit » et les « autres problèmes de sécurité », ne laissant que celles pour le volet supply chain.

Curl a fait volte-face ; pas GitHub

À l’heure où Google serrait la vis, Curl la desserrait.

Fin janvier, le projet avait annoncé la fermeture de son bug bounty public sur HackerOne. Le pourquoi tenait en un chiffre : en 2025, le taux de rapports reçus traitant effectivement de « vraies » vulnérabilités était passé sous les 5 %. Alors qu’il était plutôt autour de 15 % les années précédentes.

Curl avait alors basculé sur le système de signalement privé de vulnérabilités de GitHub – tout en supprimant les récompenses financières. Il en est revenu en mars, pas satisfait par la qualité du service… mais aussi rassuré par une hausse de la qualité des « contributions IA » (à tel point que le ratio des 15 % était à nouveau d’actualité). D’autres projets (Django, Firefox, Git, Python, Ruby…) faisaient alors un constat similaire. Pas GitHub.

Ce dernier avait d’abord annoncé, au printemps, la fin des récompenses financières pour les rapports qui permettaient de corriger du code ou de la documentation sans toutefois démontrer d’impact significatif. Puis, cet été, il a diminué le plafond indicatif de récompense pour les vulnérabilités de faible sévérité. Et conditionné les montants les plus élevés à l’obtention du statut VIP. Il a par ailleurs commencé à utiliser l’indice de réputation HackerOne.

arXiv plafonne les soumissions d’articles pour tous

Le phénomène n’épargne pas arXiV. L’archive ouverte d’articles de recherche s’en voit soumettre de plus en plus. Mais beaucoup ne respectent pas les critères de fond et de forme. Cela s’accompagne d’une tendance à « saucissonner » la restitution des travaux en plusieurs articles. Autant d’éléments qui « consomme une part disproportionnée du temps des modérateurs ».

Dans ce contexte, arXiv a imposé, sans durée déterminée, une limite de 2 soumissions par mois pour chaque utilisateur.

Du côté d’Apple, on projette des mesures contre un autre effet indésirable : les erreurs de l’IA agentique. Dans le collimateur, une autorisation de macOS pensée pour les outils de sauvegarde : l’accès complet au disque interne. Apple n’explique pas précisément comment elle va évoluer, mais laisse entendre qu’il compte la rendre encore plus explicite qu’elle n’est (à l’heure actuelle, il faut ajouter manuellement, dans les paramètres système, les applications concernées).

Illustration générée par IA

The post Face à l’IA, les bug bountys se remettent diversement en question appeared first on Silicon.fr.

Malgré l’aide précieuse qu’apporte l’IA, merci de ne pas confondre vitesse et précipitation.

Mi-mai, GitHub avait fait passer le message aux participants à son bug bounty public. En toile de fond, la saturation de ce programme par des soumissions de faible qualité. Essentiellement à deux titres. D’une part, parce que hors périmètre. De l’autre, par l’absence de preuve d’impact réel.

Dans ce contexte, GitHub avait affirmé qu’il évaluerait plus strictement la présence de PoC fonctionnels. Il avait plus globalement rappelé qu’IA ou pas, il convenait de valider toute trouvaille avant de la soumettre. Tout en s’assurant que les rapports soient concis et structurés (résumé du problème, étapes pour le reproduire, déclaration d’impact).

Ce rappel s’était accompagné d’un autre, relatif à la notion de responsabilité partagée. GitHub était notamment revenu sur les attaques impliquant un « engagement explicite » de l’utilisateur. Il avait cité, entre autres, le clonage de dépôt malveillant et l’usage d’une IA pour analyser du code non sécurisé. Dans les grandes lignes : ces scénarios ne sont généralement pas assimilables à un contournement de ses contrôles de sécurité.

GitHub avait aussi annoncé la fin des récompenses financières pour les rapports qui ne démontrent pas d’impact significatif mais qui permettent une correction de code ou de documentation. Leurs auteurs peuvent ne peuvent désormais prétendre qu’à des goodies.

Des seuils de récompense globalement maintenus… pour les VIP

Une nouvelle étape dans la restructuration du bug bounty vient d’être franchie. Elle comprend une refonte du programme VIP sur invitation*. Critère d’éligibilité : le nombre de rapports validés. Au choix, au moins :

• 1 pour une vulnérabilité critique
• 2 pour des vulnérabilités importantes
• 4 pour des vulnérabilités de sévérité moyenne
• 7 pour des vulnérabilités de faible sévérité

Au-delà d’une promesse de relation « plus étroite » avec les équipes sécurité de GitHub, les VIP pourront espérer des récompense plus élevées. Les plafonds sont fixés à :

• 1000 $ pour une vulnérabilité de faible sévérité
• 7500 $ en sévérité moyenne
• 20 000 $ en sévérité élevée
• 30 000 $ pour les critiques

Ces plafonds restent indicatifs. GitHub se réserve le droit de moduler les récompenses en fonction des découvertes. Même chose pour les « non-VIP »… qui, sur le papier, perdent au change.

GitHub ne le cache pas : il rogne sur les récompenses du bug bounty public pour pouvoir en octroyer de plus élevées aux VIP.

GitHub utilisera désormais l’indice de réputation HackerOne

Autre nouveauté : l’enclenchement du signal HackerOne. Cet indice de réputation, s’il n’est pas atteint, limite le nombre de soumissions autorisées : 4 par programme pour les nouveaux membres (moins de 5 rapports résolus), 8 pour les anciens (plus de 5 rapports). L’exigence s’appliquera au 27 juillet 2026.

* Il existait déjà un programme VIP sur invitation. Il donnait accès à un canal Slack dédié, à des goodies exclusifs et à des fonctionnalités en accès anticipé. Mais pas à des récompenses plus élevées. Pour y être admissible, il fallait avoir gagné au moins 20 000 $ sur le bug bounty et avoir soumis au moins 2 rapports sur les 2 dernières années.

Illustration générée par IA

The post Dépassé par la « bouillie IA », GitHub restructure son bug bounty appeared first on Silicon.fr.

Qu’importe le montant des récompenses, les agents IA ont saturé les bug bountys publics.

Une expérimentation récemment menée sur la plate-forme Algora en témoigne. Son auteur a utilisé Claude, chargé, avec un budget de 20 $, de sélectionner de « petits » problèmes, d’élaborer des correctifs puis de les soumettre, après révision par l’humain.

Autant soumettre les PR n’a pas posé de problème, autant les faire accepter a été une autre affaire. Systématiquement, même lorsque la récompense n’était que de quelques dizaines de $, ils tombaient en file d’attente, derrière quantité de requêtes émanant d’IA. Les gestionnaires (maintainers), dépassés par le volume, avaient tendance à sélectionner un PR – souvent le premier arrivé – et à rejeter les autres.

Une « victime du slop » arrête son bug bounty

Cette situation a poussé Turso à abandonner son bug bounty. L’entreprise américaine, qui a réécrit SQLite en Rust, avait mis ce programme en place il y a près d’un an. Elle s’engageait à verser 1000 $ pour tout bug susceptible de corrompre des données.

« Depuis quelques jours, nos équipes n’ont pas fait grand-chose d’autre que de clore des PR prétendant avoir trouvé des bugs », a expliqué Turso au moment d’annoncer la fermeture de son bug bounty. Elle donne quelques exemples de soumissions farfelues probablement assistées, si ce n’est produites par des IA :

• Corruption par injection d’octets aléatoires dans l’en-tête de la base
• Corruption par modification du code source pour ajouter manuellement un accès hors limites
• Vulnérabilité permettant l’exécution de requêtes SQL arbitraires (ce qui est le principe même du produit)…

Arrivé à ce stade, il y avait deux solutions, affirme Turso : mettre fin aux incitations financières ou stopper le bug bounty. Automatiser la gestion des PR est une option, mais elle aurait un coût… et les IA ont une capacité « potentiellement infinie » à en produire.

Turso a, pendant un temps, fermé automatiquement les soumissions semblant provenir de bots. Mais les IA se sont vite mises à contester, ouvrant des tickets pour demander des revues manuelles. Quand elles ne réémettaient pas tout simplement un autre PR, similaire.

Illustration générée par IA

The post Les bug bountys, saturés par les agents IA appeared first on Silicon.fr.