Vos étoiles GitHub attirent les bots IA. 5 choses à faire avant qu'ils n'arrivent.

11 min read

Il y a une notification GitHub que vous allez détester.

Un nouveau ticket, bien rédigé. Il cite des numéros de ligne précis dans votre code, décrit une vulnérabilité de sécurité avec un vocabulaire technique convaincant, structure l'argumentation en 3 points clairs. Le genre de rapport qui semble sérieux à première vue.

Entièrement généré par une IA. Soumis par quelqu'un qui chasse les bug bounties ou quelques PRs sur son profil GitHub avant son prochain entretien d'embauche.

Daniel Stenberg maintient curl depuis 1998. Installé sur des milliards d'appareils, le vôtre inclus. En janvier 2026, il a fermé son bug bounty HackerOne après avoir reçu 7 faux rapports de sécurité en 16 heures. 20 soumissions en 21 jours, aucune n'identifiant une vraie vulnérabilité. Il estime chaque rapport à 150$ de temps bénévole pour le triage. Il a appelé ça du "terror reporting" et a tué le programme.

L'asymétrie au cœur du problème : soumettre coûte quelques centimes en tokens d'IA. Trier coûte 150$ en temps humain. Cette asymétrie se fiche de la taille de votre projet. Elle ne se soucie que d'une chose : si vos issues sont ouvertes.

Illustration de couverture – Une scène de bureau en écran partagé montrant deux développeurs à des bureaux adjacents gérant les notifications d'issues GitHub
Illustration de couverture – Une scène de bureau en écran partagé montrant deux développeurs à des bureaux adjacents gérant les notifications d'issues GitHub

Le Ticket Qui Semblait Réel

Ce à quoi ressemblent ces rapports en pratique mérite d'être décrit, parce que le premier que vous recevrez vous trompera probablement pendant 30 secondes. Ces 30 secondes sont tout le mécanisme.

Le schéma est cohérent dans les fils de discussion des mainteneurs des derniers mois. Le ticket arrive avec une structure propre : il nomme une version spécifique de votre bibliothèque, référence des chemins de fichiers qui existent dans votre repo, et décrit un vecteur d'attaque avec le bon vocabulaire. Quelque chose comme "validation d'entrée incorrecte dans le handler pourrait permettre à un attaquant de contourner..." suivi de 3 étapes plausibles. Parfois un snippet de proof-of-concept. Grammaire parfaite, ton professionnel.

Puis vous allez regarder le code.

La vulnérabilité n'existe pas. Les numéros de ligne ne correspondent à rien de pertinent. Le vecteur d'attaque ne fonctionne que si votre bibliothèque fait quelque chose qu'elle ne fait pas. Le tout est une hallucination avec le formatage d'un rapport de sécurité légitime, soumise par quelqu'un qui a pointé un scanner sur votre repo, dépensé quelques centimes de tokens d'API, et attendu 3 minutes.

Vous ne pouvez pas ignorer ces rapports en toute sécurité. Chaque rapport de sécurité ignoré qui s'avère réel est un désastre. Donc vous les triez tous. C'est basiquement une alerte DEFCON 1 sur votre serveur Minecraft : le risque est nul, mais la réponse reste obligatoire. (Je sais. Profondément injuste.)

Stenberg a décrit l'expérience comme du "terror reporting". Le mot est exact. Pas parce que les rapports sont dangereux. Parce que chacun exige une attention immédiate qui s'avère entièrement gaspillée.

1 Mainteneur. 18 Mois. 150$ par Rapport.

TITLE "The curl Bug Bounty Collapse" + subtitle "18 months from signal to noise". Metaphor: engineer blueprint timeline left to right with annotated inflection points at key dates. Style: technical blueprint on dark navy background, white annotation lines, measurement brackets, hand-drawn grid, technical marker feel. Palette: navy #0A1628, cyan #00D4FF, white #FFFFFF, amber #FFB347, charcoal #2A3548. Content: Left zone (2024) "1 report/week, 1 in 6 real". Center zone (Late 2025) "1 in 30 real, volume x5". Right zone (Jan 2026) "7 in 16 hours, 20 in 21 days, 0 real". Far right (Jun 2026) "1 every 18h, duplicates". Each zone annotated "$150 triage cost per report". Highlight: Jan 2026 zone stamped diagonal "PROGRAM CLOSED" in amber with border. Footer: copyright rentierdigital.xyz. NOT flat corporate vector, NOT minimalist tech startup aesthetic, NOT stock infographic.
Chronologie du déclin du programme bug bounty de curl

Avant 2025, Stenberg recevait environ 1 rapport de sécurité par semaine. Environ 1 sur 6 était réel. Il avait un processus de triage documenté, une équipe de 7 bénévoles, et le genre de réputation qui attirait les chercheurs sérieux.

Puis les ratios ont changé.

Fin 2025 : 1 rapport sur 20 à 30 était réel. Le volume avait été multiplié par 5. Janvier 2026 : 7 soumissions en 16 heures. 20 en 21 jours, aucune n'identifiant une vraie vulnérabilité. Stenberg a fermé le programme HackerOne et mis à jour le security.txt de curl pour rendre les conséquences des soumissions de mauvaise foi explicites et publiques.

Il a estimé le coût : 150$ par rapport en temps de triage bénévole. Sur 20 rapports en 21 jours, ça fait 3 000$ en heures bénévoles avec 0 valeur sécuritaire en retour.

Je suis les talks FOSDEM de Stenberg depuis quelques années. curl a toujours semblé être l'idéal platonicien de la durabilité open source : un seul mainteneur, des décennies d'engagement, un projet tournant sur des milliards d'appareils. Le chapitre slopageddon ressemble à un twist particulièrement cruel pour quelqu'un qui a construit la plomberie d'internet à la main.

Une nuance à garder, parce que Stenberg la garde : certaines recherches assistées par IA sont légitimes. Joshua Rogers a trouvé environ 50 vraies vulnérabilités dans curl en utilisant ZeroPath, combinant l'outil avec sa propre expertise pour filtrer le signal du bruit. Stenberg l'a décrit comme "une personne intelligente utilisant un outil puissant". En 6 ans de suivi des soumissions de sécurité générées par IA, 0 vulnérabilité n'a été trouvée par l'IA seule, sans humain dans la boucle.

Stenberg a rouvert le bounty en mars 2026. Pas parce que le flot s'était arrêté, mais parce que la qualité s'était suffisamment améliorée pour que certains rapports soient maintenant techniquement cohérents, juste massivement dupliqués. Plusieurs chercheurs ont indépendamment pointé le même scanner sur le même repo, obtenu le même résultat, et soumis la même non-découverte. "C'était littéralement comme 2 personnes trouvant des aiguilles dans la même botte de foin", a-t-il dit. "Et ça n'était jamais arrivé." En juin 2026 : 1 rapport toutes les 18 heures.

Ce Qui Est Arrivé à curl Arrive Partout

2 populations distinctes génèrent ce bruit, et elles ont des incitations différentes. Comprendre la différence compte parce que la solution pour l'une ne résout pas l'autre.

Les chasseurs de bounty sont la foule des scanners automatisés. Ils ciblent les projets avec des récompenses monétaires actives. curl était une cible de choix spécifiquement à cause du bounty HackerOne. Supprimez l'incitation financière et vous disparaissez largement de leur file d'attente. Jazzband, un collectif Python, a complètement fermé après avoir été submergé par ce groupe. Le développeur solo sans bounty monétaire a 1 avantage structurel : les chasseurs de bounty passent généralement à autre chose.

Les chasseurs de CV se fichent du bounty. Un profil GitHub montrant 50 contributions, des PRs soumises et des issues ouvertes, même toutes rejetées, se lit mieux pour un recruteur qu'un profil vide. L'IA a fait chuter le coût de génération d'une PR plausible à environ 0. Donc cette population cible tout projet avec des issues ouvertes et une visibilité indexable. 200 étoiles ou 2 millions, la différence d'attractivité est plus petite que la plupart des développeurs ne l'imaginent.

J'ai écrit sur le coût de passer en closed-source en 2026 quand Cal.com a fait ce choix. Cet article est l'autre côté : rester ouvert ne signifie pas rester passif.

Remi Verschelde, qui maintient Godot, a décrit le travail de triage comme "épuisant et démoralisant". Mitchell Hashimoto, qui a construit Vagrant et Terraform et maintient maintenant Ghostty, a écrit en janvier : "C'est une putain de zone de guerre ici mec. Le moral des mainteneurs au plus bas." Il a banni purement et simplement les contributions IA non attribuées. tldraw ferme automatiquement toutes les PRs externes. GitHub construit activement des contrôles de modération d'urgence pour les pull requests. Quand une plateforme livre des contrôles d'urgence, c'est un signal, pas une plainte de niche.

1 PR générée par IA sur 10 atteint le standard de qualité requis pour l'ouvrir, selon une discussion communautaire GitHub de juin 2026. Les 9 autres atterrissent dans la file de triage de quelqu'un.

Kate Holterhoff l'a nommé "AI Slopageddon" début 2025. Le mot-valise s'est répandu immédiatement. Quand un label est adopté si vite, l'expérience sous-jacente était déjà répandue et avait juste besoin d'un nom.

Vous Avez Livré un Side Project. Vous Venez de Devenir Mainteneur

Voici la partie qui ne vient avec aucune documentation.

Quand vous avez poussé votre projet, activé les issues (le réglage par défaut, la plupart des gens le laissent), et commencé à accumuler des étoiles, vous avez aussi accepté quelque chose sans doc d'onboarding : la maintenance. Avec elle vient une responsabilité que personne n'assigne formellement, une qui consomme quand même votre temps réel : trier tout ce qui atterrit dans l'onglet issues.

Stenberg a eu 6 ans pour construire son infrastructure de modération. Il avait 7 triageurs bénévoles, une politique de triage documentée avec des conséquences énoncées pour les soumissions de mauvaise foi, une réputation publique qui fonctionne comme dissuasion, et un fichier security.txt qui avertit explicitement les mauvais acteurs de ce qui leur arrive. Il a construit tout ça délibérément, sur des années, en réponse à un volume de bruit pré-IA qui était déjà significatif et croissant. Et c'est pour curl, un projet tournant sur des milliards d'appareils dans le monde. L'échelle de la cible, la taille de l'infrastructure, et les années de construction délibérée sont proportionnelles d'une manière qui ne se transfère pas à un side project poussé un jeudi après-midi.

Vous avez un README.

L'écart entre ces 2 situations mérite d'être nommé sans catastrophiser. Livrer vite avec l'IA fait tourner une démo, fait fonctionner un prototype, quelque chose qui gagne des étoiles GitHub. C'est la première boucle que Vibe Coding, For Real couvre pour les développeurs qui ont heurté le mur démo-vers-production. Mais livrer vite ne livre pas la couche de modération. La couche de modération est le DLC qui n'était pas inclus, et elle devient obligatoire une fois le projet visible.

Je pense que le seuil de visibilité compte plus que le nombre d'étoiles, en fait. Un projet avec 150 étoiles et des issues ouvertes est indexable par les mêmes scanners automatisés qu'un avec 15 000. Peut-être que je me trompe, mais l'implication pratique semble la même de toute façon : une fois que vous êtes trouvable, vous êtes une cible potentielle.

La surface d'attaque de la supply chain et la surface d'attaque du slop IA partagent la même logique : toutes deux sont passives, toutes deux croissent avec la visibilité, et le coût atterrit entièrement sur vous. J'ai rencontré la première directement et l'ai documentée dans mon analyse supply chain LiteLLM. Les deux attaques n'ont pas besoin d'une vulnérabilité dans votre code. Elles ont besoin que vous n'ayez pas de politique.

Le coût de contribution vient de toucher zéro. Le coût de modération, non.

5 Choses à Faire Avant Que les Bots Vous Trouvent

Aucune n'est compliquée. Toutes sont plus faciles à mettre en place avant que le bruit commence qu'après.

1. Ne lancez pas de bug bounty monétaire sauf si vous pouvez vraiment le défendre

Un bounty monétaire est le signal de ciblage principal pour la population de chasseurs de bounty. HackerOne, Bugcrowd, tout programme de récompense structuré : en avoir un équivaut à peu près à poster "paiement par rapport accepté" dans l'annuaire open source. Sans un, les scanners automatisés priorisent généralement d'autres cibles. Ce n'est pas un argument contre les bug bounties en tant que concept. C'est un argument contre l'ajout d'un comme case "semble sérieux" sans l'infrastructure de triage pour le supporter. Stenberg avait 6 ans d'infrastructure avant que le déluge frappe. Lancer un bounty sans cette infrastructure, c'est payer pour être ciblé.

2. Écrivez un CONTRIBUTING.md avec une règle IA explicite et des conséquences énoncées

La règle doit dire ce qui arrive, pas juste ce qui est attendu. Quelque chose comme : "Les issues ou PRs générées par IA soumises sans étapes de reproduction vérifiées seront fermées immédiatement. Les violations répétées résulteront en un blocage." Les conséquences doivent être là parce que la règle existe non pour persuader, elle existe pour rendre les fermetures publiquement défendables. Quand vous fermez une soumission et que quelqu'un pousse, vous pointez vers la règle. Sans elle, chaque fermeture devient un jugement que vous devez re-plaider à partir de zéro.

3. Ajoutez un template d'issue avec un champ de vérification humaine obligatoire

C'est la couche technique pour ce que le CONTRIBUTING.md couvre en politique. Un champ requis qui dit "Étapes que vous avez personnellement reproduites sur votre machine, en séquence :" crée une friction que les soumissions automatisées ne peuvent généralement pas remplir de manière cohérente. Le template crée une trace papier qui rend les soumissions de mauvaise foi plus faciles à identifier et fermer proprement.

4. Déployez un bot stale à 14 jours

Toute issue sans activité pendant 14 jours est auto-fermée avec un message standard. Pensez-y comme le git gc de la gestion d'issues : ça tourne silencieusement et récupère l'espace que vous ne réalisiez pas avoir alloué. Le backlog passif qui s'accumule même avec un triage actif disparaît sans intervention manuelle. Sans bot stale, l'onglet issues se remplit de rapports non résolus qui créent une surcharge cognitive chaque fois que vous regardez le repo.

5. Désactivez complètement les issues si vous n'êtes pas en mode maintenance active

Cette option est sautée parce que les issues ouvertes semblent être un signal de maturité. Mais un projet où les issues ont été ouvertes et non triées pendant 6 mois envoie un pire signal qu'un projet actuellement en pause. Et du point de vue du ciblage, issues désactivées signifie non indexable par les scanners automatisés cherchant des cibles de contribution. Si vous êtes entre cycles de fonctionnalités, si vous avez livré quelque chose et êtes passé à autre chose, éteindre l'onglet issues est un choix valide. Le repo reste public, forkable, utile. Il devient juste silencieux.

Le Même Outil. 2 Directions

Le même outillage IA génère les rapports de sécurité pour les chasseurs de bounty et les PRs pour les chasseurs de CV. Même capacité sous-jacente, incitation différente, défense différente.

Les chasseurs de bounty s'auto-sélectionnent généralement quand il n'y a pas de récompense financière. Le développeur solo sans bounty monétaire est, structurellement, une cible moins attractive pour cette population. C'est à peu près la seule bonne nouvelle structurelle ici.

Les chasseurs de CV ne répondent pas à l'absence de bounty. Le coût d'effort est 0. Le bénéfice pour leur profil est réel. Le coût atterrit entièrement sur le mainteneur. Les PRs générées par IA pour le padding de CV "semblent bien. Les tests passent. Le code pourrait même fonctionner", comme l'a dit Continue Blog en janvier 2026. "Le problème c'est qu'il n'y a personne à la maison." C'est la population que les mesures ci-dessus sont conçues pour filtrer, parce qu'il n'y a pas d'incitation structurelle qui les arrête comme supprimer un bounty arrête les chasseurs.

L'IA a compressé le temps de build. Elle n'a pas compressé le temps de maintenance. La friction qui filtrait les mauvaises contributions, l'effort pour comprendre une codebase, reproduire un bug, écrire quelque chose de cohérent, a disparu côté soumission. Pas côté triage. Stenberg a passé 6 ans à construire sa défense avec 7 triageurs bénévoles.

Il reçoit encore 1 rapport toutes les 18 heures. C'est la vie 🤷‍♂️

Sources

Cet article peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais gagner une petite commission (ça ne vous coûte rien, et ça m'aide à continuer à livrer des articles de qualité chaque jour pour votre plaisir de lecture.)