Dans les coulisses du durcissement de Firefox avec Claude Mythos Preview

 (hacks.mozilla.org)
5 points par GN⁺ 2026-05-08 | 2 commentaires | Partager sur WhatsApp
  • Mozilla a mis en place un pipeline capable de trouver à grande échelle de vrais bugs de sécurité dans Firefox, en augmentant le signal et en réduisant le bruit dans les rapports de sécurité générés par l’IA grâce à de meilleures performances des modèles et à l’amélioration du harness
  • Dans Firefox 150 release, 271 bugs identifiés par Claude Mythos Preview ont été corrigés, et des correctifs liés sont aussi inclus dans 149.0.2, 150.0.1 et 150.0.2
  • Parmi les bugs représentatifs rendus publics figurent un primitive de faux objet causée par l’élimination de l’initialisation d’une structure WebAssembly GC dans le JIT, un UAF du processus parent via une condition de concurrence IPC, un problème de désérialisation de NaN, un bug de rehash vieux de 20 ans dans XSLT, ainsi qu’un overflow d’un bitfield de layout sur 16 bits exploitant rowspan=0
  • Une grande partie des bugs publiés sont des évasions de sandbox : ils supposent qu’un processus de contenu déjà compromis élève ses privilèges vers le processus parent, une surface d’attaque que l’analyse par IA couvre plus largement que le fuzzing seul
  • Mozilla a superposé un harness agentique à son infrastructure de fuzzing existante afin d’écarter les suppositions non reproductibles et de valider les hypothèses avec des cas de test, avec l’intention à terme de l’intégrer à l’intégration continue pour scanner les patchs lorsqu’ils entrent dans le tree

Le changement révélé par les bugs de sécurité Firefox trouvés par des modèles d’IA

  • Il y a encore quelques mois, les rapports de bugs de sécurité générés par l’IA soumis aux projets open source paraissaient plausibles mais étaient souvent faux, créant un coût asymétrique pour les mainteneurs
  • Dans Firefox, la situation a beaucoup évolué en peu de temps, principalement grâce aux progrès des modèles et à l’amélioration des techniques permettant de piloter, étendre et combiner les modèles avec un harness pour augmenter le signal et filtrer le bruit
  • Mozilla garde habituellement les rapports de bugs détaillés non publics pendant plusieurs mois, même après la publication des correctifs et des avis de sécurité, mais a décidé cette fois d’en publier une partie compte tenu de l’urgence et de l’intérêt pour l’ensemble de l’écosystème
  • Les rapports publiés couvrent plusieurs sous-systèmes du navigateur ; leur sélection est en partie arbitraire, mais leur profondeur et leur diversité montrent que les défenseurs doivent appliquer ce type de techniques

Bugs représentatifs rendus publics

  • 2024918
    • À cause d’une vérification d’égalité incorrecte, le JIT a supprimé par optimisation l’initialisation d’une structure WebAssembly GC encore vivante, ce qui a permis de créer une primitive de faux objet menant potentiellement à des lectures/écritures arbitraires dans un code ayant pourtant fait l’objet d’un fuzzing intensif par des chercheurs internes et externes
  • 2024437
    • Un bug vieux de 15 ans dans l’élément <legend>, déclenché par une combinaison sophistiquée de cas limites répartis dans des zones éloignées du navigateur, comme la limite de profondeur de pile récursive, des propriétés expando et le cycle collection
  • 2021894
    • Une condition de concurrence IPC pouvait être exploitée de façon fiable pour qu’un processus de contenu compromis manipule le comptage de références d’IndexedDB dans le processus parent, provoquant un UAF et une évasion de sandbox potentielle
  • 2022034
    • Un NaN brut pouvait franchir une frontière IPC en ressemblant à un pointeur d’objet JS tagué, si bien que la désérialisation d’un double pouvait mener à une primitive de faux objet dans le processus parent et à une évasion de sandbox
  • 2024653
    • Un cas de test complexe mêlant boucles d’événements imbriquées, listener pagehide et garbage collection déclenchait un UAF dans le setter d’attributs de l’élément <object>
  • 2022733
    • En injectant des milliers de hachages de certificats dans WebTransport, il était possible d’allonger une condition de concurrence dans une boucle de copie à fort comptage de références, puis de provoquer via IPC un UAF dans le parent à partir d’un processus de contenu compromis
  • 2023958
    • En interceptant des appels aux fonctions DNS de glibc pour simuler un serveur DNS malveillant et reproduire un cas limite de fallback d’UDP vers TCP, il était possible de provoquer pendant le parsing de HTTPS RR et d’ECH une lecture hors limites du tampon et une fuite de mémoire de pile du processus parent
  • 2025977
    • Un bug XSLT vieux de 20 ans où un appel réentrant à key() déclenchait un rehash de table de hachage, libérait le backing store mais continuait d’utiliser des pointeurs bruts vers les entrées ; c’était l’un des plusieurs problèmes XSLT sec-high corrigés
  • 2027298
    • Après avoir patché le sélecteur de couleur pour simuler un choix utilisateur difficile à automatiser, des événements d’entrée synchrones faisaient tourner une boucle d’événements imbriquée, réentraient dans l’actor teardown et provoquaient la libération d’un callback pendant son déroulement, causant un UAF dans le processus de contenu
  • 2023817
    • Un processus de contenu compromis pouvait envoyer une image de fond d’écran arbitraire à décoder dans le processus parent ; combiné à une vulnérabilité hypothétique dans un décodeur d’image, cela pouvait mener à une évasion de sandbox
    • Cela nécessitait dans le processus parent un raisonnement difficile à automatiser pour juger du niveau de confiance de l’entrée
  • 2029813
    • Dans RLBox, la technologie de sandboxing granulaire introduite avec Firefox 95, il était possible de contourner la sandbox en exploitant une faille dans la logique de validation lors de la copie de valeurs du côté non fiable vers le côté fiable
  • 2026305
    • Un cas de test minuscule exploitant la sémantique spéciale de rowspan=0 dans les tableaux HTML ajoutait plus de 65535 lignes pour contourner le clamping et faire déborder un bitfield de layout sur 16 bits, sans être détecté par les fuzzers pendant des années

Évasions de sandbox et couches de défense

  • Une grande partie des bugs publiés sont des évasions de sandbox, et ils doivent être chaînés avec d’autres exploits pour conduire à une compromission complète de Firefox
  • Ces rapports supposent qu’un processus sandboxé chargé de rendre le contenu d’un site est déjà compromis par un autre bug et que du code machine contrôlé par l’attaquant cherche à élever ses privilèges vers le processus parent privilégié
  • Pour produire des évasions de sandbox, le modèle peut patcher le code source de Firefox tant que le code modifié ne s’exécute qu’à l’intérieur du processus sandboxé
  • Ce type de bug est difficile à trouver par fuzzing ; Mozilla a développé des techniques comme le fuzzing IPC avec snapshots, mais l’analyse par IA a pu couvrir cette surface importante bien plus largement
  • Ce que le modèle n’a pas trouvé restait aussi important
    • Ces dernières années, des chercheurs en sécurité ont envoyé plusieurs rapports montrant comment provoquer une prototype pollution dans le processus parent privilégié afin d’échapper à la sandbox de processus
    • Au lieu de corriger les problèmes un à un, Mozilla a appliqué un changement d’architecture qui fige les prototypes par défaut
    • Les logs du harness montrent de nombreuses tentatives d’emprunter cette voie d’évasion, bloquées par la conception, ce qui confirme directement l’efficacité du travail de durcissement antérieur

Construire un pipeline de durcissement avec un harness

  • Mozilla mène en interne depuis plusieurs années des expériences d’audit de code par LLM pour analyser statiquement du code à haut risque avec des modèles comme GPT 4 ou Sonnet 3.5
  • Les premières expériences montraient du potentiel, mais la proportion de faux positifs était trop élevée pour passer à l’échelle
  • L’arrivée de harness agentiques capables de détecter de façon fiable des problèmes de sécurité a changé la donne
    • ils peuvent trouver de vrais bugs
    • ils permettent d’écarter les suppositions non reproductibles
    • avec les bonnes interfaces et consignes, ils peuvent créer et exécuter des cas de test reproductibles pour valider dynamiquement des hypothèses de bug dans le code
  • Après avoir corrigé les premiers problèmes envoyés par Anthropic en février, Mozilla a construit son propre harness au-dessus de son infrastructure de fuzzing existante
  • Au départ, Mozilla a lancé à petite échelle des expériences avec Claude Opus 4.6 pour rechercher des évasions de sandbox
    • même ce seul modèle a identifié un nombre important de vulnérabilités jusque-là inconnues, nécessitant un raisonnement complexe sur le code d’un moteur de navigateur multiprocessus
    • au début, l’équipe observait directement le processus dans le terminal en ajustant en temps réel les prompts et la logique
    • une fois le fonctionnement stabilisé, les tâches ont été parallélisées sur plusieurs VM éphémères, chacune recherchant des bugs dans des fichiers cibles précis puis enregistrant les résultats dans des buckets
  • Le seul sous-système de découverte ne suffisait pas
    • il fallait l’intégrer à l’ensemble du cycle de vie des bugs de sécurité, y compris quoi chercher, où regarder et comment traiter les résultats
    • cela incluait la déduplication par rapport aux problèmes existants, le suivi des bugs, le triage et la diffusion des correctifs
    • le modèle constitue la primitive centrale qui anime le harness, mais un pipeline complet est nécessaire pour le rendre utile à grande échelle
  • Le harness peut être réutilisable d’un projet à l’autre, mais le pipeline varie selon le sens du codebase, les outils et les processus propres à chaque projet
  • Un important travail itératif a été nécessaire, avec une boucle de retour étroite liée à la façon dont les ingénieurs Firefox traitent les bugs entrants

Claude Mythos Preview et l’effet du changement de modèle

  • Une fois le pipeline de bout en bout en place, il devient simple de remplacer un modèle par un autre lors de l’arrivée d’un nouveau modèle
  • Mozilla a trouvé plusieurs bugs graves avec des modèles publics, et ce pipeline lui a permis d’exploiter immédiatement l’occasion d’évaluer Claude Mythos Preview
  • La montée en version du modèle a amélioré l’efficacité de l’ensemble du pipeline
    • meilleure détection des bugs potentiels
    • meilleure création de cas de test de preuve de concept démontrant les bugs
    • meilleure caractérisation des pathologies et de leur impact
  • En plus des 271 bugs identifiés par Claude Mythos Preview et corrigés dans Firefox 150 release, des correctifs liés sont aussi inclus dans 149.0.2, 150.0.1 et 150.0.2
  • En interne, l’équipe continue aussi de trouver des bugs par d’autres méthodes, et comme dans d’autres projets, les signalements externes ont fortement augmenté ces derniers mois
  • Tous les bugs ont demandé une attention minutieuse pour être correctement corrigés, et de nombreux efforts ainsi que de longues heures de travail ont été nécessaires ces derniers mois pour suivre cette échelle inédite
  • Plus de 100 personnes ont contribué au code afin de livrer la version la plus sûre possible de Firefox ; au-delà de l’écriture et de la revue des patchs, il a aussi fallu construire et étendre le pipeline, faire le triage, tester les correctifs et gérer le processus de release pour chaque bug

Leçons clés

  • Toute personne qui développe du logiciel peut dès maintenant utiliser des modèles modernes et des harness pour trouver des bugs et durcir son code
  • Il est possible de commencer avec un prompt simple, puis d’observer et d’itérer
    • le prompt initial n’était pas très différent de celui montré dans cette vidéo
    • avec les itérations, de nombreux outils d’orchestration ont été ajoutés pour optimiser et étendre le pipeline, mais la boucle interne restait essentiellement : « il y a un bug dans cette partie du code, trouve-le et génère un cas de test »
  • Firefox n’a probablement pas encore épuisé tout son stock de bugs potentiels, mais Mozilla se dit satisfaite de la trajectoire actuelle
  • Les scans actuels se concentrent surtout sur des zones de code spécifiques désignées, c’est-à-dire des fichiers et des fonctions, en combinant jugement humain et signaux automatiques
  • À court terme, l’objectif est d’intégrer cette analyse au système d’intégration continue afin de scanner les patchs lorsqu’ils entrent dans le tree
  • Les modèles s’adaptent souplement au format du contexte fourni, et Mozilla s’attend à ce qu’un scan basé sur les patchs fonctionne aussi bien, voire mieux, qu’un scan basé sur les fichiers
  • Le moment est risqué, mais l’opportunité est grande, et il faut agir ensemble pour rendre Internet plus sûr

Questions fréquentes

  • Pourquoi le nombre de « 271 bugs » diffère des chiffres des avis de sécurité

    • La page web des avis de sécurité regroupe plusieurs bugs signalés en interne sous des CVE « rollup »
    • La page est générée à partir du yaml du dépôt foundation-security-advisories, qui est l’emplacement officiel des attributions de CVE
    • Certains navigateurs ne créent pas d’identifiants CVE pour les problèmes découverts en interne, mais Mozilla les publie afin de fournir une information aussi transparente que possible
    • Firefox 150 contenait 3 rollups internes
      • CVE-2026-6784 : 154 bugs
      • CVE-2026-6785 : 55 bugs
      • CVE-2026-6786 : 107 bugs
    • Le total des trois rollups internes est de 316 bugs, soit plus que les 271 bugs annoncés comme trouvés avec Claude Mythos Preview
    • La raison est que l’équipe sécurité de Mozilla attaque Firefox chaque jour pour trouver de nouveaux bugs, en combinant systèmes de fuzzing, inspection manuelle et nouveau pipeline agentique utilisant plusieurs modèles
    • Dans la release d’avril, 423 bugs de sécurité ont été corrigés au total
      • les 271 bugs annoncés il y a deux semaines
      • 41 bugs signalés de l’extérieur
      • les 111 restants ont été découverts en interne et se répartissent globalement en trois catégories
        • des bugs trouvés avec ce pipeline utilisant Claude Mythos Preview mais corrigés dans d’autres releases que Firefox 150
        • des bugs trouvés avec ce pipeline utilisant d’autres modèles
        • des bugs trouvés par d’autres techniques comme le fuzzing
    • Anthropic reçoit aussi directement le crédit pour 3 CVE, distinctement de ce travail plus récent
      • CVE-2026-6746
      • CVE-2026-6757
      • CVE-2026-6758
    • Il s’agit de correctifs de bugs envoyés à Mozilla il y a plusieurs mois par l’Anthropic Frontier Red Team, et chacun a reçu son propre CVE selon la procédure habituelle

  • Signification des niveaux de gravité sécurité

    • Mozilla applique des security severity ratings de critical à low pour indiquer l’urgence d’un bug
    • sec-critical et sec-high sont attribués aux vulnérabilités pouvant être déclenchées par un comportement utilisateur normal, comme la visite d’une page web
    • Il n’y a pas de différence technique entre sec-critical et sec-high, mais sec-critical est réservé aux problèmes publiquement divulgués ou connus comme exploités dans des attaques réelles
    • sec-moderate est attribué à des vulnérabilités qui seraient autrement classées sec-high mais exigent des étapes anormales et complexes de la part de la victime
    • sec-low est attribué à des bugs gênants mais éloignés d’un préjudice utilisateur, comme un crash sans impact de sécurité
    • La répartition des 271 bugs annoncés dans Firefox 150 est la suivante
      • 180 sec-high
      • 80 sec-moderate
      • 11 sec-low
    • Mozilla accorde la plus haute priorité aux bugs critical/high, mais il est aussi courant de prioriser des bugs de sécurité moderate et low pour corriger des problèmes de justesse et renforcer la défense en profondeur

  • Différence entre sec-high ou sec-critical et un exploit réel

    • Un bug sec-high ou sec-critical ne signifie pas automatiquement un exploit pratique
    • Dans la plupart des cas, un seul bug critical/high ne suffit pas à compromettre Firefox
    • Firefox dispose d’une architecture de défense en profondeur ; par exemple, exploiter un bug JIT ne donne qu’une exécution de code à distance dans un processus sandboxé et isolé par site
    • En pratique, un attaquant doit généralement enchaîner plusieurs exploits pour franchir une ou plusieurs couches de sandboxing ainsi que des mitigations au niveau de l’OS, comme l’ASLR, afin d’élever ses privilèges
    • Mozilla ne développe généralement pas d’exploits pour vérifier si un bug pourrait réellement être utilisé par des attaquants
    • La classification sec-high repose sur des symptômes de crash prévisibles, comme des use-after-free ou des problèmes mémoire hors limites signalés par AddressSanitizer
    • Le modèle de menace part du principe qu’avec suffisamment d’efforts, ce type de bug peut être exploitable
    • Cette approche réduit le risque de faux négatifs dans l’analyse d’exploitabilité et permet de concentrer les ressources sur la découverte et la correction d’un plus grand nombre de vulnérabilités

À lire aussi

2 commentaires

 
GN⁺ 2026-05-09
Avis sur Hacker News

  • Je le répète : un bug reste un bug. Une « vulnérabilité potentielle » est aussi un bug, et une vulnérabilité doit voir son impact sécurité vérifié au moyen d’une preuve de concept ou d’un élément équivalent
    Les mots comptent, et les bugs aussi. Corriger beaucoup de bugs a toujours été important, et c’est un travail qui se faisait déjà ; en soi, c’est déjà très impressionnant
    Mythos n’a pas rédigé de preuve de concept pour 271 vulnérabilités ni démontré l’atteignabilité de chemins de code ayant un impact sécurité. Mythos a trouvé 271 bugs valides, et c’est déjà suffisant à mes yeux

    • La définition m’avait un peu embrouillé, mais Mozilla a réparti ces 271 « choses » comme suit [1]
      Pour donner plus de contexte, Mozilla applique des niveaux de gravité de sécurité allant de critical à low pour indiquer l’urgence d’un bug. sec-critical et sec-high sont attribués à des vulnérabilités pouvant être déclenchées par des actions ordinaires d’un utilisateur, comme visiter une page web ; techniquement, Mozilla ne distingue pas les deux, mais sec-critical est réservé aux problèmes rendus publics ou connus pour être exploités en conditions réelles
      sec-moderate désigne des vulnérabilités qui relèveraient autrement de sec-high, mais qui exigent de la victime des étapes anormales et complexes, et sec-low s’applique à des bugs pénibles mais éloignés d’un préjudice utilisateur, par exemple un crash sans danger
      Parmi les 271 bugs annoncés pour Firefox 150, 180 étaient sec-high, 80 sec-moderate et 11 sec-low
      Mozilla emploie aussi le mot « vulnerability » pour sec-high, tout en précisant juste en dessous que cela ne signifie pas forcément un exploit pratique. La page de définition classe même sec-low parmi les « vulnerabilities » [2]
      Les mots sont des outils, et leur utilité vient d’un sens collectif. Je me demande d’où vient ce système de sens, et s’il correspond à celui de Mozilla ou s’en écarte
      [1] https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
      [2] https://wiki.mozilla.org/Security_Severity_Ratings/Client
    • Mythos a effectivement rédigé des preuves de concept pour tous les bugs provoquant un crash à cause de violations de sûreté mémoire comme des use-after-free ou des lectures/écritures hors limites
      De notre point de vue, en l’absence d’élément contraire, c’est une preuve concrète suffisante pour considérer cela comme une vulnérabilité de sécurité, et c’est toujours ainsi qu’on a traité les bugs de fuzzing
    • Claude peut, et le fait effectivement, produire des proofs of concept d’exploit pour des bugs exploitables qu’il a trouvés lorsqu’il croit que l’utilisateur possède ce code
      Ma seule source, c’est mon expérience personnelle, et je ne peux pas partager de preuve
    • Quand il faut décider quoi traiter en premier sur le terrain, cette distinction ne tient pas
    • Si ce n’est pas « 271 PoC de vulnérabilités », alors le mot que vous cherchez ressemble davantage à exploit

  • J’avais pris le précédent billet non technique pour une promotion produit à peine déguisée pour Anthropic. L’article lié sur Mozilla Hacks est une meilleure source que cet article-ci, et c’est une publication bienvenue
    Il semble désormais difficile de nier qu’il y a des résultats concrets. La définition interne de « vulnérabilité » chez Mozilla paraît plus large que ce que beaucoup imaginent intuitivement, mais il est bon que ces problèmes soient pris au sérieux et corrigés

  • Source d’origine : https://news.ycombinator.com/item?id=48051079
    C’est mieux, car cela liste une partie des rapports Bugzilla effectivement publiés. Le sujet avait déjà été discuté auparavant, mais le fait que les rapports de bug soient publics est entièrement nouveau
    La discussion précédente remonte à deux semaines et comptait 36 commentaires : https://news.ycombinator.com/item?id=47885042

  • J’aimerais qu’on arrive au jour où les LLM seront tellement bons pour trouver et corriger des bugs que les ingénieurs Firefox pourront se concentrer uniquement sur l’ajout de nouvelles fonctionnalités
    Ce n’est pas ironique. Firefox mérite d’être davantage utilisé. La plupart des gens autour de moi ne l’utilisent pas parce que « Chrome fait presque tout mieux », et Firefox a du mal à rivaliser avec la roadmap des autres navigateurs

    • Je suis tout à fait d’accord avec l’idée que Firefox devrait être plus utilisé. Au point que, lorsque j’achète sur un site, je choisis parfois où acheter en fonction de la compatibilité avec Firefox
      Il m’arrive aussi d’écrire au support pour signaler que Firefox n’est pas pris en charge ou que certaines fonctionnalités marchent mal. Il ne se passe presque jamais rien, mais j’ai l’impression que c’est une des rares choses que je puisse faire pour garder ce navigateur dans le champ de vision
    • Une partie du problème, c’est que lorsque Mozilla cesse de corriger des bugs, ils se mettent à faire des trucs façon Mr Robot. Nous, on veut juste un navigateur web. Personne n’a demandé Pocket ni l’IA
      Si l’IA corrige tous les bugs, à part maintenir la compatibilité syntaxique avec plusieurs langages de build, que restera-t-il à faire ? J’ai l’impression qu’ils finiront simplement par revenir à l’idée de remettre le navigateur en désordre
    • J’ai l’impression que cette qualité et cette disponibilité permettent justement à Chrome de prendre beaucoup d’avance sur Firefox
      À moins que Mozilla ne construise en interne un LLM ou un harnais propriétaire qu’ils seraient seuls à utiliser et qui leur permettrait de dépasser Chrome, mais même cela me paraît peu réaliste
    • Chrome n’est pas significativement meilleur dans plus de 99 % des usages. Je suis développeur et cela fait environ dix ans que je n’utilise que Firefox et uBlock Origin
      Ma femme utilise aussi Firefox comme navigateur principal depuis que je lui ai expliqué à quel point l’expérience Internet pouvait être différente
      Donc j’aimerais qu’on évite le discours du type « les monopoles sont mauvais et Google est un peu maléfique, alors utilisez le petit outsider imparfait ». Pour tout ce que je lui ai demandé, Firefox a offert une expérience de premier ordre, et sur mobile c’est même trois fois plus vrai. C’est de loin l’expérience de navigateur mobile la plus utile
    • Les navigateurs n’ont plus besoin de nouvelles fonctionnalités depuis très longtemps. Pour cela, la solution aurait dû être les extensions

  • Il n’y a que quelques tickets liés, donc peut-être qu’en voyant les 271 éléments réels individuellement on changerait d’avis, mais ceux que j’ai regardés étaient tous de graves bugs dans du code C++
    Firefox est écrit dans plusieurs langages et le C++ n’en représente qu’environ 25 %, pourtant tous ces problèmes semblent impliquer du C++

    • La limite générale de cette approche, c’est qu’un validateur n’est bon qu’à hauteur de ce qu’il sait valider. Par exemple, rien n’est plus facile à valider qu’un cas de test qui déclenche un use-after-free avec AddressSanitizer
      Il reste à voir si les problèmes plus subtils exigeront des validateurs plus spécifiques, ou si les LLM deviendront meilleurs pour imaginer eux-mêmes d’autres conditions risquées à vérifier
    • Il est possible que Mythos soit bien meilleur pour trouver des vulnérabilités C++ que celles d’autres langages, puisque ces modèles sont eux aussi construits à partir de matériaux d’analyse de sécurité existants
      À mes yeux, une bonne partie de ces bugs ne relèvent pas uniquement du C++, mais sont plutôt des problèmes tombés par hasard dans du code C++. Même le Rust le plus sûr ne peut pas magiquement éliminer des problèmes comme TOCTOU
    • Comme les bugs ont été validés avec AddressSanitizer, le système était, par construction, orienté vers la découverte de bugs C++

  • Lire cet article à côté de l’attitude de certaines personnes côté Zig, qui ne veulent même pas examiner les bugs générés par des LLM, change ma façon de voir quelles technologies intégrer à ma toolchain à l’avenir

    • Les deux points de vue sont valables, et cela dépend du modèle utilisé ainsi que de la personne qui soumet le bug. Les capacités des modèles de pointe sont passées en quelques mois de 99 % de bruit à 99 % de bugs valides
      Certains projets sont encore inondés du premier type, au point qu’il faut des garde-fous pour éviter que cela ne devienne en pratique une attaque par déni de service contre les mainteneurs

  • Quand j’étais chez PalmSource, j’ai essayé d’obtenir du budget pour des outils d’analyse statique du code comme CoVerity ou Fortify, mais ma hiérarchie a répondu que c’était « trop cher »
    J’ai passé un an de plus à réduire les coûts et à proposer une solution limitée au scan de la pile réseau ; cette fois, on m’a répondu que « c’est basé sur BSD, et BSD est intrinsèquement sûr ». Les deux affirmations étaient fausses
    J’ai fini par quitter l’entreprise pour aller chez Mozilla, et il y avait partout dans le code des commentaires /* flawfinder ignore */
    Mon hypothèse, c’est que Mythos s’est contenté d’ignorer ces directives flawfinder ignore et de signaler des vulnérabilités déjà connues dans le code

    • Le code est public. Si quelqu’un peut démontrer que c’est bien le cas, ce serait une vraie information

  • Je me demande quel impact cela aura sur les outils d’analyse statique. L’approche est très différente, mais l’objectif est souvent le même
    Les outils d’analyse statique peuvent être lents et produire beaucoup de faux positifs. Si ces modèles deviennent suffisamment bons et bon marché, je me demande si les gens finiront par presque ne plus utiliser l’analyse statique

    • Les LLM sont bien meilleurs pour utiliser des outils que pour remplacer des outils. En général, il est bien plus rapide d’utiliser les outils existants que d’essayer d’obtenir le même résultat directement avec un LLM
      Utiliser des outils de coding assistés par LLM pour nettoyer en continu la sortie d’outils d’analyse statique fonctionne très bien, et ajouter des garde-fous pour s’assurer qu’aucun problème ne reste est aussi une bonne idée. C’est comme un contrôle CI qui vérifie que tout est propre
      Les faux positifs varient selon les outils. J’évite généralement ceux qui ne produisent que du bruit, et ces outils permettent souvent de désactiver les règles les plus bruyantes. Sinon, on peut aussi demander au LLM de tout corriger. Si corriger coûte moins cher que débattre avec la règle, alors autant corriger. Avant, il fallait que des humains le fassent manuellement, donc c’était très coûteux ; aujourd’hui, ce n’est plus le cas
      J’ai utilisé cette approche récemment en remettant à jour une base de code Ansible que je n’avais pas touchée depuis des années. Il y avait des centaines de problèmes ansible-lint, pour la plupart des avertissements de dépréciation et des alertes non critiques ; dix minutes plus tard, il n’y en avait plus aucun. Ce n’étaient sans doute pas des problèmes très graves, mais cela restait une forme de dette technique. Si je devais corriger manuellement des centaines d’avertissements, je ne le ferais probablement pas ; mais si un coup de baguette magique peut tout faire disparaître, il n’y a plus vraiment de raison de s’en priver. J’ai depuis ajusté les garde-fous pour exécuter ansible-lint en permanence et corriger les problèmes, et cela ne prend que quelques secondes de plus
    • Une possibilité intéressante serait de renforcer les outils d’analyse statique pour qu’ils détectent les formes de bugs initialement découvertes par les LLM [0]
      Il ne fait guère de doute que les outils d’analyse statique sont plus rapides et moins coûteux ; ils passent donc mieux à l’échelle sur d’énormes bases de code et pourraient généraliser la méthode des LLM
      [0] https://lwn.net/Articles/1068968/
    • Les outils d’analyse statique peuvent aussi être bien plus rapides et sont pour la plupart entièrement déterministes ; intégrés à la CI, ils permettent d’arrêter des bugs ou bugs potentiels avant qu’ils n’entrent dans la base de code
      Je maintiens les outils d’analyse statique utilisés dans la CI de Firefox. Pour faire entrer un patch dans notre arbre, il faut corriger tous les signalements, qu’il s’agisse de faux positifs ou de vrais positifs, ou bien les marquer explicitement comme non problématiques. Autrement dit, nous devons tolérer 0 signalement, ce qui est un standard assez strict
      C’est un compromis assumé. Pour garder un rapport signal/bruit suffisamment élevé afin que les gens n’ignorent pas les alertes, ne les commentent pas en masse ou n’arrêtent pas complètement d’exécuter l’outil, il faut affaiblir l’analyse et accepter certains faux négatifs. Presque tous les outils d’analyse statique doivent gérer cet équilibre
      À l’inverse, l’IA couramment utilisée dispose de beaucoup plus de marge. Il est presque fondamental qu’on doive lui permettre d’halluciner davantage de faux positifs, et c’est aussi une part importante de sa puissance. C’est pourquoi il faut ensuite plusieurs couches de validation et de vérification. Cela peut être lent, et on ne peut pas dire « cette forme d’erreur précise sera détectée à 100 % », mais malgré cela, cela permet de trouver énormément de choses
      J’ai un exemple concret. Mon analyse avait à tort jugé peu probable l’apparition de vrais bugs dans un certain cas, et sa mise en œuvre me semblait fastidieuse, donc je ne l’avais pas traitée. Je ne sais plus si c’était Opus ou Mythos, mais ils ont commencé à signaler des vulnérabilités issues de ce cas, et j’ai dû étendre en urgence l’analyse pour combler le trou. Cela m’a pris un bon moment à implémenter, et quand j’ai lancé le scan sur tout l’arbre des sources, Claude avait déjà trouvé tous les problèmes importants qu’il avait signalés. L’analyse statique en a trouvé quelques-uns de plus, mais pour être honnête, je ne sais toujours pas si certains sont réellement déclenchables
      Malgré tout, je pense que l’analyse statique garde de la valeur. Certaines occurrences d’un motif de problème peuvent rester atteignables par des chemins encore trop compliqués pour qu’une IA les construise aujourd’hui. Et elles pourraient devenir de vrais problèmes plus tard si d’autres parties du code changent. Pour ces deux raisons, il semble utile de tout corriger dès maintenant, sans compter une raison plus secondaire : éviter que l’IA ne perde du temps à tenter de les exploiter. En même temps, il est clair que l’équilibre coût/efficacité a changé
      Les deux approches peuvent aussi coopérer. Je pourrais assouplir mes critères pour que l’outil d’analyse produise un rapport complémentaire de problèmes suspects, avec l’attente explicite qu’il puisse y avoir des faux positifs, puis injecter cette liste dans une IA pour validation. En substance, il s’agirait de nourrir une machine à bouillie avec de la bouillie afin qu’elle y tamise, de façon non déterministe, quelques pépites
      Voilà un sujet qui mérite réflexion
    • Ces harnais utilisent probablement déjà des outils d’analyse statique, et continueront sans doute à le faire

  • Dans le dernier Mission Impossible, il faut récupérer dans un sous-marin russe coulé le logiciel source originel d’une AGI surhumaine qui s’est échappée afin de sauver le monde
    Luther écrit immédiatement, à partir du code source original, une « poison pill » qui neutralise l’IA d’un seul coup. Je me demandais comment ce code magique avait pu être écrit, et maintenant je sais. Luthor a simplement donné le code source au prompt de Mythos et a demandé un exploit fatal immuable

  • Je me demande si les gens pensent que les LLM rendront les logiciels plus sûrs ou moins sûrs d’ici cinq ans

    • Ils élimineront probablement certains types de problèmes, ce qui sera probablement une bonne chose. Et ce qui restera peu sûr pourra encore être porté vers d’autres langages
      Avant même l’arrivée des LLM, il existait déjà une dynamique de portage manuel vers Rust. Grâce aux LLM, ce travail va devenir plus simple et plus rapide. La valeur à long terme viendra du nettoyage de l’énorme dette technique que représentent les bases de code C/C++ existantes. Elles sont responsables de l’écrasante majorité des exploits mémoire, buffer overflows et autres problèmes, et malgré des décennies d’attention, on continue d’en trouver dans les grandes bases de code
      Si Mozilla a trouvé ces problèmes, c’est parce que des ingénieurs très compétents essaient depuis 25 ans de faire les choses correctement, en utilisant tous les outils disponibles pour empêcher ce type de défaut d’apparaître. J’ai énormément de respect pour cette équipe et pour tout ce qu’elle a apporté au fil des années en matière d’outils, de tests et de pratiques de vérification. Le problème n’est pas leur effort ni leur compétence
      Prendre un système existant bien testé, bien documenté et bien spécifié, puis produire une implémentation de remplacement drop-in devient désormais quelque chose de crédible à envisager. Il y a encore quelques années, cela aurait impliqué un coût et un risque de projet énormes ; aujourd’hui, c’est quelque chose qu’on peut commencer un vendredi après-midi. Au pire, on échoue ; au mieux, on obtient une implémentation bien meilleure
      On est encore au début, et le code généré par LLM a encore beaucoup de problèmes de qualité. Mais les taux de réussite et d’échec ont de bonnes chances de s’améliorer avec le temps
    • Les deux. Les personnes compétentes s’en serviront pour trouver des problèmes, et les moins compétentes pour produire du code-bouillie non sûr que les personnes compétentes devront ensuite corriger
    • C’est un peu comme les magasins de bricolage, les outils électroportatifs, le matériel facilement disponible et les tutoriels YouTube : cela a permis de fabriquer des meubles formidables et robustes, mais aussi des meubles grossiers, laids, voire dangereux
      Quand davantage de gens ont accès à davantage d’outils, davantage de choses sont fabriquées, sur un éventail plus large de qualité
    • Les logiciels seront plus sûrs, mais un peu comme la population devient globalement plus saine après une épidémie
    • Quand ils sont appliqués de manière appropriée, ils rendront les logiciels plus sûrs
      En revanche, pour les projets qui n’utilisent pas ce type d’outils, cela signifie aussi que les black hats auront plus facilement l’occasion de les exploiter
 
GN⁺ 2026-05-08
Avis sur Lobste.rs

  • J’aimerais qu’ils publient aussi les prompts et autres fonctionnalités utilisés pour ce travail
    Ce serait bien d’inclure les prompts dans les rapports de bugs ou les historiques de résolution pour que ce soit reproductible
    Comme ils ont aussi mentionné des modèles non-Mythos, une partie de ce travail pourrait sembler immédiatement utile à d’autres

    • Pour la plupart des projets, la barrière à l’entrée est vraiment faible
      En gros, il suffit de dire : « examine ce projet sous l’angle des problèmes de sécurité, en commençant par (fichier), et liste tous les chemins possibles », puis pour chaque élément d’enchaîner avec : « vérifie ce rapport et crée une preuve de concept »
      À ce stade, avec Opus, il est plus difficile de ne rien trouver que de trouver quelque chose de cette manière
    • Vous pensez vraiment que le prompt allait au-delà de « trouve des vulnérabilités de sécurité dans cette base de code » ?

  • Quoi qu’on en dise, c’est vraiment impressionnant
    Ils ont trouvé 271 problèmes de sécurité avec Mythos, et 423 au total
    Parmi eux, 180 étaient de gravité élevée, et certains problèmes de sécurité dataient de 20 ans

    • On ne sait pas tout à fait à quel point la comparaison entre Opus 4.6 et Mythos était équitable
      Le texte laisse entendre, sans le dire exactement ainsi, que Mythos a trouvé « 271 bugs » dans du code déjà scanné auparavant avec la 4.6
      Je me demande aussi si le harnais de recherche a changé en même temps

  • Le passage disant que « l’un des nombreux problèmes sec-high que nous avons corrigés concernait XSLT » semble avoir été inclus à cause de la controverse sur la suppression de XSLT

  • Ce qui m’intrigue le plus ici, c’est aussi le nombre de faux positifs signalés
    Le modèle a peut-être signalé environ deux fois plus de vulnérabilités potentielles, et je me demande si ce qui est présenté ici correspond uniquement à celles qui ont été confirmées
    Je ne sais pas non plus s’il va jusqu’à reproduire le problème avant de le signaler
    Dans les tickets publics, on voit des commentaires qui semblent tenter une reproduction, mais il pourrait aussi s’agir d’un bot déjà existant
    Je ne connais pas très bien la façon dont Firefox traitait ce type de travail à l’origine, ni comment cela se passe maintenant avec l’IA, donc une explication plus détaillée serait vraiment très intéressante