Les rapports de vulnérabilités ne sont plus exceptionnels

• Dans la maintenance open source, les issues ordinaires et les PR peuvent être traitées de façon optionnelle, mais auparavant les rapports de vulnérabilités constituaient une exception nécessitant une réponse distincte pour protéger les utilisateurs
• Ce caractère exceptionnel apportait des informations rares et de la confidentialité, en donnant aux chercheurs la possibilité de corriger avant les attaquants, et les projets récompensaient cela par des réponses rapides, une enquête, le partage de l’avancement et des crédits
• En 2026, les mainteneurs comme les attaquants peuvent tous deux exécuter des LLM, si bien que le goulot d’étranglement se déplace de la détection des problèmes potentiels vers le tri des véritables vulnérabilités
• Les chercheurs externes sans relation de confiance ont du mal à contribuer de manière significative à ce tri, et le rapport signal/bruit entre l’examen des sorties de LLM et celui de la boîte de réception security@ devient similaire
• Le temps des mainteneurs doit être davantage consacré au classement, aux correctifs rapides et à la prévention qu’au simple traitement des signalements, et il faut aussi trouver comment exécuter l’analyse par LLM dans la CI

---

Pourquoi le signalement de vulnérabilités était une exception

• Les mainteneurs open source qui travaillent en public considèrent les issues, les PR et les retours comme des cadeaux, qu’ils peuvent accepter, ignorer ou utiliser partiellement selon les besoins
• Les anciens rapports de vulnérabilités constituaient un cas particulier qui échappait à ce principe
  • Au lieu de publier immédiatement, les chercheurs en sécurité choisissaient un signalement privé afin de laisser au projet le temps de corriger d’abord
  • On attendait généralement du projet qu’il accuse rapidement réception du rapport, qu’il enquête, qu’il partage son avancement avec l’auteur du signalement et qu’il lui attribue finalement le mérite de la découverte
• Ces attentes reposaient sur l’idée que l’auteur du signalement n’était pas quelqu’un qui exigeait une correction de bug ou l’implémentation d’une fonctionnalité, mais quelqu’un qui rendait service au projet
  • La valeur essentielle résidait dans les informations et la confidentialité permettant de déployer un correctif avant qu’un attaquant ne publie un exploit
  • Ignorer un rapport de vulnérabilité était perçu comme un signal indiquant que le projet ne se souciait pas de la sécurité de ses utilisateurs

Les hypothèses qui se sont effondrées en 2026

• En 2026, les hypothèses qui rendaient les rapports de vulnérabilités spéciaux deviennent difficiles à maintenir
  • Les LLM sont presque aussi bons que la quasi-totalité des chercheurs en sécurité, et tout le monde peut les exécuter
  • Les mainteneurs peuvent utiliser les mêmes outils, tout comme les attaquants
• Ce qui manque n’est pas la capacité à trouver des problèmes potentiels, mais le travail de classement permettant de déterminer lesquels sont de vraies vulnérabilités
• Les chercheurs externes sans relation de confiance préexistante ont du mal à contribuer utilement à ce processus de tri
  • Le rapport signal/bruit entre l’examen des sorties de LLM et le fait de parcourir la boîte de réception security@ est presque identique
• L’importance de la confidentialité, des embargos et de la coordination diminue également par rapport au passé
  • Les attaquants peuvent interroger leur propre LLM sur des vulnérabilités sans attendre une publication complète
  • Cela dit, les attaquants risquent eux aussi de se heurter au même goulot d’étranglement du tri que les défenseurs

Changement de priorités pour les mainteneurs

• L’époque où les rapports de vulnérabilités étaient spéciaux est peut-être terminée
• Ce qui importe davantage aujourd’hui, c’est le classement, les correctifs rapides et la prévention
• Il faut trouver comment exécuter l’analyse par LLM dans la CI
• Cette position n’est pas celle officielle de l’équipe Go Security, mais l’opinion personnelle d’un ancien responsable de l’équipe Go Security
• Quand le traitement des rapports de vulnérabilités entre en conflit avec l’application du Code of Conduct, il n’existe pas de bonne réponse unique
  • Il faut en juger selon la gravité du comportement, le fait qu’il s’agisse d’une affaire privée ou qu’elle affecte la communauté, et les ressources de l’équipe qui traite security@
• Les pratiques de divulgation publique ont une histoire complexe
  • Par le passé, il est arrivé que des chercheurs de bonne foi subissent des menaces juridiques ou des poursuites
  • Dans la réalité open source de 2026, aucun chercheur ne craint d’être poursuivi à cause d’un rapport de vulnérabilité, et les projets ne devraient pas non plus laisser entendre des poursuites comme alternative à une politique de signalement documentée
• L’interruption pendant un mois du canal de signalement des vulnérabilités de curl m’a d’abord semblé excessive, mais il n’est plus évident que répondre aux rapports de vulnérabilités soit la meilleure utilisation du temps pour protéger les utilisateurs

[GN⁺]

Avis sur Lobste.rs

• Je pense toujours que la divulgation précipitée de vulnérabilités aide bien davantage les attaquants que les défenseurs. D’après ce que j’ai vu en pratique, même avec des modèles de pointe, le taux de faux positifs peut parfois approcher les 90 %
  Cela dit, j’ai remarqué la phrase « la maintenance et le développement durables des protocoles cryptographiques open source sont essentiels à l’adoption large des technologies blockchain », et je suis surpris qu’il y ait encore des gens qui croient à la blockchain

  • Je me demandais pourquoi cette phrase était là, puis j’ai compris qu’il s’agissait d’un message envoyé par l’un des sponsors de Filippo
    À ce stade, la contribution la plus précieuse de la technologie blockchain au monde est peut-être d’avoir créé de fortes incitations financières à produire des implémentations de protocoles cryptographiques vraiment sûres. Une partie de ce travail pourrait aussi devenir utile à tout le monde
  • Je me demande ce que signifie ici faux positif. Est-ce que cela veut dire que le modèle affirme avoir trouvé une vulnérabilité, mais qu’après vérification ce n’en est pas une ?
    J’avais l’impression qu’à ce stade il était assez bien établi que la recherche de vulnérabilités et, plus généralement, la compréhension du code font partie des choses que les LLM savent bien faire, donc je me demande ce qu’il en est réellement. Si vous pouviez détailler un peu plus votre expérience directe ou indiquer des références utiles, ce serait apprécié. Je n’utilise pas de LLM, donc j’ai du mal à estimer où on en est aujourd’hui, et je me demande sincèrement si je dois revoir mes hypothèses

• Les signalements de vulnérabilités exceptionnels doivent être traités comme exceptionnels, et le camp des défenseurs devrait mettre en place de meilleurs modes de validation ainsi que des modèles de menace publics. Ainsi, il serait possible de définir un niveau d’exigence plus élevé pour qu’un signalement soit reconnu comme excellent, et de le vérifier

  • C’est peut-être bien ainsi que cela finira. Les signalements de vulnérabilités ne sont généralement pas spéciaux, mais certains, à gravité élevée ou à forte crédibilité, devraient être considérés comme des signalements de vulnérabilités spéciaux

• Je suis d’accord pour dire qu’il est devenu plus facile de trouver des problèmes de sécurité et que la baisse de la barrière à l’entrée a probablement accru le bruit sur les listes de diffusion sécurité par rapport à avant. Cela dit, je continuerais clairement à prioriser les rapports de bugs venant de sociétés de conseil en sécurité réputées comme Trail of Bits ou Zellic
  Pas seulement parce que j’ai confiance dans le fait qu’ils ne soumettront pas de rapports bâclés, mais aussi parce que je considère que la combinaison de chercheurs en sécurité de haut niveau et de LLM est meilleure que le simple fait d’exécuter des LLM dans la CI

  • J’ai récemment travaillé avec ce type de prestataires, et des rapports bâclés arrivent quand même. La qualité moyenne des rapports est simplement plus élevée
    Les LLM peuvent mal comprendre le modèle de menace, quel que soit l’utilisateur qui les pilote, et ils peuvent être paresseux dans la manière de démontrer un « exploit ». Si le chercheur en sécurité laisse passer ces erreurs, elles finissent par nous être transmises en tant que mainteneurs. containerd a reçu des rapports bâclés de la part de ces prestataires, d’entreprises de recherche sur les LLM, d’entreprises connues pour leurs modèles de base, ainsi que de J Random User sur Internet
    Une autre difficulté que Filippo n’aborde pas assez ici, ce sont les signalements en doublon. Si vous regardez les advisories récents de containerd, vous verrez qu’un autre gros problème pour le triage et l’allocation de l’attention, ce sont les doublons. Par exemple, 9 chercheurs/groupes distincts ont été crédités, y compris des groupes réputés comme ceux mentionnés plus haut. Cela montre (a) que les LLM, quel que soit l’utilisateur, trouvent souvent les mêmes problèmes, et (b) qu’un signalement provenant d’un auteur connu n’est pas nécessairement spécial. À l’inverse, celui-ci n’a effectivement donné lieu à aucun doublon, donc une seule personne a été créditée, et il ne s’agissait pas de quelqu’un que nous connaissions déjà ou avec qui nous avions une relation préalable.