Pourquoi les rapports de vulnérabilité ne sont plus « spéciaux » : le problème des fausses alertes dans l'écosystème du bug bounty

Filippo Valsorda, ancien responsable de la sécurité du langage de programmation Go et désormais chercheur indépendant en sécurité, a résumé lundi dans un billet de blog un problème fondamental de l'écosystème moderne du bug bounty : les rapports de vulnérabilités ne sont plus « spéciaux », et la situation est devenue un défi sérieux pour les mainteneurs de logiciels open source. Le billet a été débattu en tête de Hacker News tout au long de la journée.

L'argument de Valsorda est simple : dans les années 2010, un rapport de vulnérabilité était un événement relativement rare et marquant pour l'équipe d'un projet. Il s'agissait généralement d'un courriel d'un chercheur expérimenté, rempli de preuves détaillées et de recommandations. En 2026, dans un environnement de scanners automatisés et de rapports générés par IA, cette structure a changé.

La principale thèse du billet est qu'à mesure que le volume de rapports a augmenté, le rapport signal/bruit a baissé. Valsorda affirme qu'un mainteneur open source peut recevoir des dizaines de rapports « j'ai trouvé quelque chose » par semaine, mais que l'écrasante majorité sont soit des faux positifs (pas de problème), soit mal décrits (preuves manquantes), soit des doublons de problèmes connus.

Le billet résume un point que Valsorda souligne particulièrement : « Les programmes de bug bounty ont été conçus comme un outil de réduction de la surface d'attaque ; mais, pour les mainteneurs, ils sont devenus un système de gestion du spam. » Le texte suggère que cela accélère l'épuisement des mainteneurs bénévoles de l'open source.

Valsorda explique que le problème a plusieurs sources. La première : les rapports générés par IA. Les grands modèles de langage (LLM) comme les outils automatisés d'analyse statique produisent des rapports de découvertes qui ne sont pas réelles ou qui sont exagérées. La seconde : les incitations à la récompense sur les plateformes de bug bounty (HackerOne, Bugcrowd) tendent à récompenser le nombre de rapports.

Le billet souligne que l'écosystème open source (projets comme le noyau Linux, OpenSSL, FFmpeg) est le segment le plus touché par cette dynamique. Les mainteneurs de ces projets n'ont pas les ressources humaines pour suivre les évolutions de l'écosystème des rapports. Les processus d'attribution des CVE, dépendant de la capacité limitée de MITRE, sont déjà en retard.

L'équipe Project Zero de Google a tenu un message similaire dans un billet de blog l'an dernier : « les scans automatisés ne sont pas un signal significatif pour nous, et la plupart du temps ne sont que du bruit ». Project Zero n'accepte que les découvertes vérifiées par un travail manuel dans ses propres recherches.

Au centre des solutions proposées par Valsorda figure une refonte du processus de signalement. Ses suggestions incluent : (1) une couche de vérification automatisée fixant l'ordre de priorité, (2) une distribution plus large du pouvoir d'attribution des CVE, (3) la restructuration des systèmes de récompense des bug bounties pour favoriser les contributeurs récurrents de preuves de qualité au lieu de rapports ponctuels, et (4) une classification distincte des rapports générés par IA.

Bas Alberts, directeur de GitHub Security Lab, a participé à la discussion sur Hacker News : « L'argument de Valsorda correspond à ce que nous observons sur GitHub. Les rapports générés par IA nécessitent une validation beaucoup plus stricte pour atteindre un seuil de qualité acceptable. » Alberts a ajouté que GitHub renouvellera sa structure de validation des rapports plus tard cette année.

Le billet de Valsorda s'inscrit dans un débat sectoriel plus large : comment rééquilibrer les incitations économiques de la recherche en sécurité ? Si les récompenses encouragent la quantité de rapports, le secteur générera naturellement du bruit. Une refonte est nécessaire, ou, comme le note aussi Valsorda, un nouveau cadre financier pour la protection de l'écosystème open source.