L'IA a rendu la découverte de failles bon marché. Les corriger est désormais le goulot d'étranglement

Le coût de la découverte s'est effondré

Trouver une vulnérabilité plausible exigeait autrefois de la compétence, du temps et une bonne compréhension du code. Les grands modèles de langage ont supprimé l'essentiel de ce coût. Chercheurs et outils automatisés peuvent aujourd'hui produire en quelques heures de gros volumes de rapports candidats contre des projets populaires de logiciels libres. Le problème, c'est que le travail ne s'arrête pas à la découverte. Quelqu'un doit encore reproduire le problème, évaluer sa gravité, écrire le correctif, le relire et le livrer aux utilisateurs. Aucune de ces étapes n'est devenue moins chère.

Cette asymétrie oblige les programmes de primes à changer leurs règles. curl a suspendu son programme de primes en janvier 2026. Google a durci son programme de récompenses pour les logiciels libres en mars 2026, en exigeant des preuves de meilleure qualité, comme une reproduction OSS-Fuzz ou un correctif fusionné, pour certains paliers de paiement. Google a déclaré que de nombreux rapports générés par l'IA comportent des conditions de déclenchement inventées ou signalent des bogues à faible impact réel. En avril, HackerOne a suspendu les paiements du programme Internet Bug Bounty. Celui-ci avait versé plus de 1,5 million de dollars depuis 2012 et réservait historiquement environ 80 % des récompenses aux nouvelles découvertes et 20 % au soutien à la correction.

L'explication de HackerOne est la formulation la plus nette du problème à ce jour. L'entreprise a déclaré que la recherche assistée par l'IA élargit la découverte de vulnérabilités à l'échelle de l'écosystème, en augmentant la couverture et la vitesse, et que l'équilibre entre les découvertes et la capacité de correction dans les logiciels libres a été sensiblement modifié. Node.js, parmi les premiers projets touchés, continue d'accepter des rapports via HackerOne, mais ne verse plus de récompenses pour eux.

Pourquoi les mauvais rapports coûtent cher

Un rapport erroné n'est pas gratuit pour celui qui le reçoit. Le mainteneur doit le lire, le reproduire et expliquer pourquoi il ne fonctionne pas, souvent dans un fil rempli d'échanges polis mais peu utiles. Si le rapport décrit un chemin de déclenchement qui n'existe pas, le mainteneur peut passer des heures à examiner du code qui n'est jamais exécuté. Multipliez cela par des dizaines de soumissions et une équipe de bénévoles peut perdre toute une semaine au seul tri. Les rapports qui semblent crédibles mais sont faux coûtent plus cher que les rapports manifestement mauvais, car on ne peut pas les écarter d'un coup d'œil.

La réponse des programmes a été de renvoyer la charge de la preuve vers le déclarant. Demander une reproduction avec un fuzzer, une preuve de concept qui fonctionne sur la version actuelle ou un correctif oblige le déclarant à faire une partie du travail qui incomberait sinon au mainteneur. Cela filtre aussi les soumissions dont l'auteur n'a pas réellement exécuté le code.

Pourquoi cela dépasse les logiciels libres

Les enjeux ne sont pas théoriques. Le rapport Verizon 2026 sur les violations de données indique qu'environ 31 % des violations proviennent désormais de l'exploitation de vulnérabilités logicielles, contre environ 20 % l'année précédente. Dans ce jeu de données, l'exploitation de vulnérabilités a dépassé le vol d'identifiants comme première voie d'accès initial. La plupart des logiciels d'entreprise reposent sur des composants libres, si bien qu'un retard de correction en amont devient un retard dans chaque produit en aval.

La couverture du déficit de financement a aussi mis en lumière l'ampleur du problème. Selon des informations de presse, la Linux Foundation a sollicité une aide financière auprès d'entreprises d'IA, et Google, Anthropic, AWS, Microsoft et OpenAI ont engagé ensemble 12,5 millions de dollars pour le travail de sécurité des logiciels libres. C'est une somme significative, mais il s'agit d'une contribution ponctuelle face au travail continu de maintenance des bibliothèques très utilisées.

Ce qui devrait changer

La bonne décision est de payer pour la partie coûteuse du travail. La découverte est désormais bon marché ; un correctif confirmé et livré ne l'est pas. Plusieurs changements en découlent.

• Les mainteneurs devraient inscrire un critère de preuve explicite dans leur politique de sécurité. Les rapports sans reproduction, sans test en échec ni preuve de concept peuvent être fermés automatiquement, avec un modèle court expliquant ce qui est nécessaire. La mise en place prend quelques minutes et fait gagner des heures.
• Les mainteneurs devraient traiter la relecture des correctifs comme une activité budgétée. Si un projet repose sur des bénévoles, le financement doit couvrir le temps de relecture, et pas seulement les primes pour les rapports.
• Les entreprises qui dépendent de logiciels libres devraient mesurer le délai de correction, et non le délai de signalement. Une équipe sécurité qui compte les cas qu'elle a triés optimisera le volume. Une équipe qui suit combien de temps une vulnérabilité reste non corrigée dans ses dépendances financera le travail qui compte.
• Les plateformes de primes devraient payer davantage pour les correctifs fusionnés que pour les rapports, et envisager de rémunérer les artefacts de reproduction avant le début du tri.
• Les chercheurs qui trouvent de vrais bogues devraient joindre un correctif à leur rapport. Un patch qui passe la suite de tests est ce qu'un déclarant peut offrir de plus utile à un mainteneur.

Ce que cela signifie pour votre équipe

Si vous gérez un produit qui dépend de composants libres, commencez par inventorier les projets amont dont vous dépendez et vérifiez s'ils disposent d'un processus actif de réponse aux incidents de sécurité. Demandez à vos fournisseurs des niveaux de service pour les correctifs, et pas seulement leurs résultats de scan. Quand une vulnérabilité est signalée en amont, le délai avant une version corrigée détermine votre exposition, et ce délai dépend d'une capacité de mainteneurs que vous pouvez aider à financer.

Le problème de la découverte ne va pas disparaître, et il ne devrait sans doute pas le faire. Trouver davantage de bogues n'est pas un échec en soi. L'échec serait de continuer à récompenser l'étape bon marché pendant que l'étape coûteuse retombe sur quelques bénévoles épuisés. Les programmes qui changent leurs règles aujourd'hui tentent de corriger cela, et les équipes qui dépendent de ce logiciel devraient aussi y prêter attention.