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 1er 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). Lire aussi : Dépassé par la « bouillie IA », GitHub restructure son bug bounty 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 ». Lire aussi : Les bug bountys, saturés par les agents IA 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