La pression : les équipes sécurité de l'open source face au déluge de vulnérabilités assistées par IA

De quoi parle-t-on ?

Le 26 mai 2026, Daniel Stenberg, développeur principal de curl, publie The pressure — un texte court et personnel sur ce que la recherche de vulnérabilités assistée par IA est en train de faire au pipeline sécurité de l’un des logiciels libres les plus omniprésents au monde. Les chiffres sont nets : un débit de rapports de sécurité quatre à cinq fois supérieur à 2024 et deux fois supérieur à 2025, plus d’un rapport par jour en moyenne, et douze CVE déjà confirmées avec la moitié du cycle de release restant à courir, ce qui place curl sur la trajectoire d’au moins trente CVE publiées en 2026 avant la mi-année.

Ce n’est pas un advisory de vulnérabilité. Si nous traitons le sujet, c’est précisément parce que le phénomène décrit par Stenberg n’est plus isolé à curl. Simon Willison l’a résumé le jour même. Help Net Security avait documenté la tendance huit jours plus tôt, avec Linus Torvalds qualifiant la liste sécurité du noyau Linux d’« à peu près ingérable », et l’équipe sécurité produit de GitHub publiant de nouvelles exigences de soumission pour filtrer les rapports gonflés par l’IA. Le sujet est ce glissement opérationnel, pas le compteur de bugs.

Comment cela fonctionne

Pas d’exploit ici. Le mécanisme est opérationnel, et il est passé par deux phases distinctes ces dix-huit derniers mois.

Phase                Période          Signal dominant               Réponse des mainteneurs
-------------------- ---------------- ----------------------------- -------------------------------
1. AI slop           mi-2024 → 2026   Rapports hallucinés,          Bug bounties durcissent ou
                                      faible qualité                ferment
2. Chaos de haute    mars 2026 →      Rapports détaillés,           « Pression inédite » ;
   qualité           en cours         crédibles, souvent            re-calibrage des SLA, de la
                                      dupliqués, IA-assistés        capacité, du flux d'advisories

Phase 1 — l’AI slop. Tout au long de 2025 et début 2026, les projets dotés d’un bug bounty public se noyaient sous des rapports apparemment plausibles qui ne survivaient pas à la vérification. Le billet de Stenberg de janvier 2026, The end of the curl bug-bounty, documente la trajectoire de curl : taux de vulnérabilités confirmées passant de plus de 15 % en 2024 à moins de 5 % en 2025, puis fermeture du programme le 31 janvier 2026. Apache Log4j, Nextcloud et d’autres ont pris le même chemin. Help Net Security cite la propre comptabilité de Stenberg, qui chiffre le slop IA à environ 20 % des soumissions de 2025, avec seulement 5 % de soumissions correspondant à de vraies vulnérabilités.

Phase 2 — le chaos de haute qualité. Le billet du 22 avril 2026, High-Quality Chaos, documente l’inflexion. Après que curl a déplacé la réception des rapports vers GitHub puis vers HackerOne sans bounty, le slop a chuté et le taux de vulnérabilités confirmées « est revenu, voire dépasse, le niveau pré-IA de 2024, autour de 15-16 % » — pendant que le volume absolu de rapports continuait de monter. Quasi tous les rapports portent désormais les empreintes d’une assistance IA, y compris « des doublons très détaillés impossibles à produire par un humain ». Le billet du 26 mai est la même personne, six semaines plus tard, décrivant ce qui arrive à une équipe de mainteneurs quand le débit de bons rapports passe lui aussi au-delà d’un par jour sur un projet qui compte une trentaine de milliards d’installations dans le monde.

Liste non exhaustive de projets dont les mainteneurs ont confirmé publiquement à Stenberg observer la même tendance : Apache httpd, BIND, Django, Elasticsearch Python client, Firefox, git, glibc, GnuTLS, GStreamer, Haproxy, Immich, libssh, libtiff, noyau Linux, OpenLDAP, PowerDNS, Python, Prometheus, Ruby, Sequoia PGP, strongSwan, Temporal, Unbound, urllib3, Vikunja, Wireshark, wolfSSL.

Pourquoi cela compte

Trois bascules font de ce sujet un sujet sécurité, pas un sujet de gestion communautaire.

D’abord, le goulot d’étranglement n’est plus la découverte des bugs mais le pipeline de divulgation. Help Net Security cite Shubham Shah (Assetnote) : les organisations mettent désormais beaucoup plus de temps à examiner les rapports légitimes — la boucle de retour qui maintient les bons chercheurs engagés se dégrade. Si une équipe de mainteneurs ne peut pas trier au rythme auquel la recherche assistée par IA peut soumettre, le temps effectif de correction du projet s’allonge quelle que soit la qualité des outils en amont. Le même modèle qui trouve un bug pour un défenseur peut le trouver pour un attaquant ; plus la file d’attente est longue, plus la fenêtre l’est aussi.

Ensuite, le coût est absorbé par une population réduite et sans filet. Le billet de Stenberg est inhabituellement franc : semaines de 50 heures, « tous les jours », et son épouse qui lui demande de ralentir. Le projet curl n’appartient à aucune entreprise, n’est rattaché à aucune fondation parapluie et compte à peu près le même effectif qu’il y a cinq ans. Le PMC d’Apache Log4j, d’après Piotr P. Karwasz dans les commentaires du billet de janvier, se débat avec la même contrainte. C’est un point de défaillance unique pour des bibliothèques qui sous-tendent une fraction substantielle des logiciels mondiaux.

Enfin, la variable dominante est désormais la gouvernance, pas la détection. La note publique de Mozilla sur le tri Firefox assisté par Mythos décrit 271 défauts latents corrigés avant Firefox 150, avec l’idée que « les défauts sont finis ». À supposer cela exact, cette queue finie doit encore passer par revue humaine, divulgation, correction, release, packaging aval et mise à jour utilisateur. Ces étapes ne sont pas compressibles à vitesse IA aujourd’hui.

Défenses

Le playbook défensif ici est opérationnel plutôt que technique, et s’applique que votre équipe maintienne une bibliothèque open source, opère un programme de bug bounty ou consomme des advisories en amont. Aucune des recommandations ci-dessous ne nécessite un accès à un modèle de pointe.

1. Calibrer les exigences de soumission sur la nouvelle réalité. Les règles révisées de bug bounty de GitHub, publiées en mai 2026, offrent un modèle utilisable : proof-of-concept fonctionnel démontrant un impact sécurité concret, validation des trouvailles IA-assistées avant envoi, rapports concis et non gonflés, fermeture explicite des rapports tombant dans les catégories publiquement inéligibles. Les recommandations responsables du noyau Linux sur l’usage de l’IA constituent une seconde référence. Les deux sont courtes et transposables aux projets plus petits.

2. Découpler la réception des rapports de la récompense monétaire quand le slop domine. La décision de curl en janvier 2026 — garder le canal de divulgation ouvert tout en supprimant les bounties — est l’expérience naturelle la plus propre disponible : après le changement, le taux de vulnérabilités confirmées est revenu aux niveaux pré-IA. La leçon n’est pas « abolissez les bounties » — les gros éditeurs en tirent encore parti — mais « l’incitatif bounty doit être redessiné spécifiquement pour les soumissions de l’ère IA ». HackerOne et Bugcrowd superposent du tri assisté par IA à la revue humaine ; demandez à votre plateforme ce qui est filtré, avec quel taux de faux négatifs, avant d’investir des effectifs.

3. Re-calibrer SLA de correctif et SLA de divulgation ensemble. Si votre cible interne pour les CVE de moteurs de navigateur, de noyau et de bibliothèques ubiquitaires reste « 30 jours après divulgation », ce chiffre a été fixé quand le débit de trouvailles crédibles était plus bas. Côté divulgation — délai entre rapport acceptée et CVE publiée — la contrainte vient désormais de la capacité de tri des mainteneurs, pas du rythme du chercheur. Suivez les deux nombres et remontez-les à la direction comme une seule courbe.

4. Financer les bibliothèques que vous embarquez. La seule demande explicite de Stenberg dans le billet du 26 mai concerne les entreprises qui dépendent de curl ou libcurl dans du logiciel commercial : financer l’équipe. La même chose vaut pour les projets listés plus haut. Un contrat de support ou un mainteneur sponsorisé coûte matériellement moins cher que le risque baissier d’un pipeline sécurité d’une bibliothèque critique qui s’éteint. Pour les équipes sécurité et conformité, c’est une ligne budgétaire, pas une ligne RSE.

5. Refléter le workflow IA côté défense. Le schéma qui produit le flot entrant — un modèle qui fait remonter des classes de bugs candidates depuis du code source public — est reproductible sur du code interne sans accès Mythos. Triez votre propre base pour les analogues non corrigés des CVE publiées sur la version de bibliothèque que vous embarquez. Générez des reproducteurs minimaux à partir des advisories avant que le PoC officiel arrive. L’asymétrie ne favorise les défenseurs que si les défenseurs utilisent les mêmes outils.

6. Tracer l’attrition des mainteneurs comme un risque chaîne d’approvisionnement. Un mainteneur principal qui réduit ses heures, quitte un projet ou s’épuise est un événement supply chain pour tout ce qui est en aval. Ajoutez la question « qui maintient ce projet, et avec quelle capacité ? » à votre checklist de due diligence pour toute bibliothèque au-dessus d’un seuil de criticité défini. La liste de projets ci-dessus est un point de départ raisonnable.

7. Contribuer au groupe de travail OSSF. Le Vulnerability Disclosures Working Group de l’Open Source Security Foundation collecte du feedback sur les bonnes pratiques en matière de soumissions IA-assistées. Si votre organisation dépose des rapports, opère un programme de bounty ou consomme des advisories à l’échelle, vos données opérationnelles sont utiles à ce travail et les modèles de politique qui en sortiront sont réutilisables dans votre propre programme.

État des lieux

Élément	Référence	Date	Notes
Stenberg, The pressure	daniel.haxx.se	2026-05-26	>1 rapport/jour ; 12 CVE confirmées à mi-cycle
Brève link blog Willison	simonwillison.net	2026-05-26	Amplification le jour même, tags security/AI
Stenberg, High-Quality Chaos	daniel.haxx.se	2026-04-22	Taux de vulnérabilités confirmées revenu à 15-16 %
Stenberg, End of the curl bug-bounty	daniel.haxx.se	2026-01-26	Programme bounty fermé le 31-01-2026
Help Net Security, AI is drowning maintainers	helpnetsecurity.com	2026-05-18	Cite Torvalds, GitHub, HackerOne
Update bug-bounty GitHub Security	github.blog	2026-05	Nouvelles exigences, PoC obligatoire
OSSF Vulnerability Disclosures WG #178	github.com/ossf	2026	Appel ouvert sur les pratiques anti-slop

Le bon cadrage ici n’est pas « l’IA produit trop de bugs » — c’est « le pipeline de divulgation passé par revue humaine dont dépend tout l’écosystème logiciel a été dimensionné pour un monde où trouver des bugs était plus lent que les corriger, et cette hypothèse n’est plus vraie pour tous les projets ». Les mainteneurs qui tiennent la baraque le signalent explicitement. Le coût d’agir sur ce signal — financement, politique, outillage — est faible devant le coût d’agir après que l’équipe sécurité d’une bibliothèque critique a cessé d’exister.