Guardian360
Démarrer l’essai gratuitDevenir partenaire
← Tous les articles

Opinion

Le mythe de la bonne foi : pourquoi l'IA brise la divulgation des vulnérabilités, et pourquoi c'était inévitable

Par Jan Martijn Broekhof ·

Un collègue m’a transféré un ticket de support la semaine dernière. À première vue, cela ressemblait à un rapport authentique : un rapport détaillé et techniquement fluide concernant un enregistrement MTA-STS manquant, accompagné d’une explication du risque et d’un résumé soigné des mesures correctives. Complet. Professionnel. Le genre de rapport que l’on a envie de prendre au sérieux.

Sauf qu’il ne mentionnait jamais le domaine auquel il s’appliquait. Pas une seule fois. Et l’enregistrement qu’il prétendait manquant était, dans notre cas, déjà configuré.

Cette seule omission vous en dit presque tout. Le rapport n’a pas été écrit pour nous. Il a été écrit pour tout le monde, pulvérisé vers des centaines d’organisations à la fois, formulé de manière suffisamment convaincante pour qu’un certain pourcentage le lise, paniquent légèrement, et répondent. L’expéditeur n’a pas besoin que nous ayons le problème. L’expéditeur a seulement besoin qu’un nombre suffisant de destinataires croient qu’ils pourraient l’avoir.

Un rapport qui ne coûte rien à envoyer

Mon collègue a observé une forte hausse de ce type précis de ticket ces derniers temps. Des rapports de « chercheurs en bug bounty de sécurité » qui semblent légitimes et rigoureux, et qui se dissolvent en rien dès qu’on les confronte à la réalité. Des constats génériques, un périmètre absent, des enregistrements qui ne manquent pas réellement, le tout présenté avec le vernis assuré d’un résumé assisté par l’IA. Répondez à l’un d’eux et vous invitez une vague de relances, du même expéditeur et d’autres, chacune agitant une nouvelle découverte d’apparence plausible.

La stratégie n’est pas subtile une fois qu’on la voit. Envoyer autant de rapports peu coûteux que possible vers autant d’organisations que possible, viser les éléments que de nombreuses organisations n’ont effectivement pas configurés (MTA-STS, en-têtes de sécurité, enregistrements DNS agréables à avoir mais rarement urgents), et attendre qu’une fraction morde à l’hameçon et paie. Cela exploite une lacune précise : l’organisation qui manque de l’expertise interne pour distinguer un constat réel d’un constat bien habillé.

Voici la partie qui mérite qu’on s’y attarde. Envoyer ce rapport n’a essentiellement rien coûté à l’expéditeur. Le lire, le trier, vérifier notre propre configuration, et conclure qu’il s’agissait de bruit nous a coûté du temps réel et une attention réelle. L’économie s’est discrètement inversée, et presque personne ne l’a dit à voix haute.

Nous nous sommes raconté une histoire confortable

Pendant des années, la communauté de la sécurité a décrit la divulgation coordonnée des vulnérabilités comme une relation fondée sur la confiance et la bonne foi. Un chercheur trouve quelque chose, le divulgue de manière responsable, laisse à l’éditeur le temps de le corriger, et tout le monde se comporte en adulte. C’est une belle histoire. C’est aussi, je pense, une histoire que nous nous sommes racontée parce que l’alternative était moins flatteuse.

La divulgation coordonnée des vulnérabilités n’a jamais réellement reposé sur la bonne foi. Elle reposait sur le coût. Produire un rapport de vulnérabilité crédible exigeait auparavant du temps, des compétences, et la volonté d’engager son nom et sa réputation. Cet effort constituait le véritable filtre. Il ne garantissait pas la sincérité, mais il y était suffisamment corrélé pour que nous puissions traiter l’effort comme un indicateur de bonne intention, puis requalifier discrètement tout l’arrangement en confiance, parce que confiance sonne mieux que « nous comptons sur le fait que nous spammer demande trop de travail ».

La friction était le mécanisme. Retirez la friction et la confiance n’a plus rien sur quoi s’appuyer.

La divulgation coordonnée des vulnérabilités a-t-elle jamais reposé sur la confiance ?

Je ne le pense pas, et la preuve la plus claire est ce qui se passe maintenant que la friction a disparu.

Regardez curl. Daniel Stenberg, son fondateur et développeur principal, a fait fonctionner pendant des années un programme de bug bounty sur HackerOne, et selon la plupart des mesures, cela fonctionnait ; le projet a versé plus de 100 000 dollars pour environ quatre-vingts vulnérabilités confirmées sur six ans. Puis le ratio s’est effondré. Jusqu’au début de 2025, environ un rapport sur six envoyé à curl était réel ; à la fin de 2025, le taux de précision était tombé à quelque chose de plus proche d’un sur vingt ou un sur trente. Non pas parce que les chercheurs sont devenus moins bons, mais parce que le volume de rapports assurés, au ton technique, et finalement vides a explosé.

Stenberg a mis le doigt exactement sur ce que je décris ici. Autrefois, a-t-il dit, quelqu’un investissait réellement beaucoup de temps dans un rapport de sécurité ; il y avait une friction intégrée, et maintenant il n’y a plus aucun effort du tout, donc les vannes sont ouvertes. C’est tout l’argument en une phrase, venant de quelqu’un qui l’a vécu. La friction faisait tout le travail depuis le début. L’IA n’a pas corrompu la bonne foi ; elle a révélé que la bonne foi était garantie par l’effort, puis elle a rendu l’effort optionnel.

La pression est devenue suffisamment sévère pour que curl cesse d’accepter les soumissions via HackerOne et redirige brièvement les rapporteurs vers GitHub, son fichier security.txt précisant que le projet n’offre aucune compensation monétaire. Lorsqu’un projet aussi bien doté en ressources et aussi respecté que curl doit changer son modèle de divulgation pour survivre au bruit, le cadre de la « confiance » n’est pas seulement inexact. Il est activement contre-productif, parce qu’il nous empêche de concevoir pour le monde dans lequel nous vivons réellement.

Il ne s’agit pas de blâmer les chercheurs

Je veux être prudent ici, car la version facile de cet argument est cynique, et elle est erronée.

Il existe de bons chercheurs indépendants, compétents et honnêtes, et ils valent leur pesant d’or. Stenberg lui-même formule ce point mieux que je ne le pourrais : en septembre 2025, un chercheur a envoyé à curl une longue liste de problèmes authentiques trouvés à l’aide d’outils assistés par l’IA, et Stenberg a ouvertement salué cela comme un excellent travail. L’IA entre les mains de quelqu’un qui comprend ce qu’il regarde constitue un véritable atout. Le problème n’est pas l’outil, et ce n’est pas non plus le chercheur qui soumet un rapport unique, soigné, reproductible et spécifique au domaine.

Les plateformes ne sont pas non plus le méchant de l’histoire. Les plateformes de bug bounty imposent une structure : règles de périmètre, scores de réputation, détection des doublons, une piste d’audit. Ces mécanismes constituent un remplacement moderne de l’ancienne friction, ce qui explique précisément pourquoi ils fonctionnent encore. Fait révélateur, l’expérience de curl limitée à GitHub ne convenait pas aux besoins du projet, et dès mars 2026, il a ramené le signalement de sécurité vers HackerOne, toujours sans prime associée. La structure valait la peine d’être conservée. Le chèque en blanc, non.

L’acteur qui mérite d’être nommé est le soumetteur de masse à faible effort : la personne qui pointe un outil d’IA vers une liste d’organisations, génère des rapports plausibles à grande échelle, et les tire directement vers n’importe quel canal ouvert existant, sans plateforme, sans réputation, sans coût. C’est ce que mon collègue a vu. Cela n’est pas arrivé via un pipeline filtré avec un score de réputation associé. Cela a atterri dans notre file d’attente de support.

La porte non gardée qu’on nous demande désormais tous d’ouvrir

Voici pourquoi ce n’est pas seulement un problème de l’open source, et pourquoi cela devrait inquiéter les organisations de taille moyenne et les PME auxquelles je consacre la majeure partie de mon temps.

La divulgation coordonnée des vulnérabilités devient une gouvernance standard, par voie réglementaire. Le point de vue de l’ENISA elle-même, exprimé par sa responsable des services d’incidents et de vulnérabilités, est que NIS2 et le CRA normalisent la divulgation coordonnée des vulnérabilités : les organisations sont de plus en plus censées disposer de processus structurés pour recevoir des rapports de vulnérabilité, et bien les gérer devient un avantage concurrentiel. En principe, c’est une bonne chose. Les organisations devraient disposer d’une porte d’entrée pour les rapports de sécurité.

Mais chaque organisation qui ouvre cette porte hérite exactement du problème de curl, généralement avec bien moins d’expertise pour la défendre. Un projet bénévole doté d’une équipe de sécurité dédiée et d’années de processus a peiné. Un fabricant régional ou une entreprise de services de taille moyenne, à qui l’on vient de dire qu’il lui faut un canal de divulgation, ne dispose d’aucune couche de réputation, d’aucun muscle de triage, et d’aucun moyen simple de distinguer un chantage déguisé d’une découverte authentique. La réglementation fait apparaître des milliers de nouvelles portes, ouvertes et non gardées, précisément au moment où l’IA a rendu gratuit le fait de les inonder. C’est la tenaille, et les organisations les moins bien équipées pour y faire face y marchent tout droit.

Alors par quoi remplaçons-nous le mythe ?

Je n’ai pas de plan en dix points bien ficelé, et je me méfie de quiconque prétend en avoir un. Cela dépasse la file d’attente d’une seule entreprise, et je préfère y réfléchir ouvertement plutôt que de prétendre que c’est résolu.

Ce dont je suis raisonnablement sûr, c’est ceci : l’ancien filtre par le coût a disparu, et il ne reviendra pas. Le geste honnête consiste donc à cesser de qualifier la divulgation coordonnée des vulnérabilités de question de confiance et à commencer à concevoir pour un monde où la confiance ne peut pas être présumée à la porte. Cela pourrait signifier réintroduire délibérément du coût ou de la friction du côté de l’expéditeur. Cela pourrait signifier des couches de réputation et d’identité pour les canaux ouverts, pas seulement pour ceux hébergés par des plateformes. Cela pourrait signifier une capacité de triage partagée pour les organisations plus petites qui ne peuvent pas la construire seules. Je ne sais honnêtement pas laquelle de ces options se révélera viable.

Je terminerai donc par des questions plutôt que des réponses. Si l’effort était le véritable filtre et que l’effort est désormais gratuit, que mettons-nous à sa place qui n’exclue pas également le chercheur honnête qui en est à son premier rapport ? Et comment donnons-nous aux plus petites organisations, celles désormais légalement tenues d’ouvrir un canal de divulgation, un moyen de survivre à un flot que même curl a eu du mal à gérer ?

J’aimerais savoir comment vous y réfléchissez. Pas de manière rhétorique. Je le pense vraiment.

Sources