Une bibliothèque logicielle presque invisible, utilisée depuis des décennies pour compresser des données, vient de servir de banc d’essai à une nouvelle génération d’outils de cybersécurité. Sur zlib, le modèle GPT-5.5-Cyber d’OpenAI a construit en une journée un environnement de fuzzing couvrant une douzaine de points d’entrée. D’après Trail of Bits, la société de sécurité qui pilotait l’expérience, un chercheur expérimenté aurait normalement consacré plusieurs semaines à ce travail.
Le résultat, détaillé le 2 juillet 2026, ne se résume pas à un modèle qui écrit quelques tests. L’agent a choisi sa méthode, compilé plusieurs variantes de la bibliothèque, créé des programmes capables de la solliciter automatiquement, puis écarté de lui-même un plantage jugé peu réaliste. Plusieurs problèmes plus sérieux sont désormais examinés dans le cadre d’une divulgation coordonnée ; leurs détails ne seront publiés qu’après correction.
Cette démonstration donne une forme concrète à Patch the Planet, le programme lancé en juin par OpenAI et Trail of Bits pour aider des projets open source critiques. Elle révèle surtout un changement de rythme : l’intelligence artificielle ne sert plus seulement à lire du code ou à suggérer un correctif. Elle peut désormais monter une campagne d’audit dynamique de bout en bout. Cette puissance profite aux défenseurs, mais réduit aussi le niveau d’expertise nécessaire pour rechercher des failles.
Pourquoi zlib constitue un test difficile
zlib est une bibliothèque de compression sans perte ancienne, compacte et extrêmement répandue. Elle manipule notamment le format DEFLATE, présent dans des archives, des images, des protocoles réseau et de nombreux logiciels. Son code a été relu, testé et soumis au fuzzing pendant des années. Trouver de nouvelles zones intéressantes n’a donc rien d’un exercice scolaire.
Le fuzzing consiste à alimenter un programme avec un très grand nombre d’entrées générées ou modifiées automatiquement. Un moteur observe ensuite le comportement du logiciel : plantage, accès mémoire invalide, boucle anormalement longue ou différence inattendue avec une autre implémentation. Les outils modernes utilisent la couverture du code comme boussole. Lorsqu’une entrée fait exécuter un chemin encore inexploré, elle devient le point de départ de nouvelles mutations.
Cette technique est particulièrement efficace contre les erreurs de mémoire, telles que les dépassements de tampon ou les accès à des objets déjà libérés. Elle n’est pourtant pas automatique au sens complet. Pour tester une bibliothèque, il faut généralement écrire un harnais de fuzzing : un petit programme qui transforme les données produites par le moteur en appels valides vers l’interface à examiner.
Un mauvais harnais peut déclencher des erreurs impossibles dans un usage réel, ignorer une partie importante du code ou s’arrêter avant d’atteindre les états les plus intéressants. La difficulté ne consiste donc pas seulement à envoyer des données aléatoires, mais à construire les bonnes conditions d’expérimentation.
Le modèle n’a pas simplement relu le code
Trail of Bits a confié à GPT-5.5-Cyber un objectif : rechercher dans zlib une catégorie précise de problèmes dangereux pour les bibliothèques de compression. L’équipe ne lui a pas fourni une procédure détaillée.
Le modèle a d’abord estimé qu’une revue statique du code avait peu de chances d’être productive sur un projet aussi examiné. Il a choisi de créer un laboratoire de fuzzing dynamique. Pendant plusieurs heures, il a assemblé une campagne comportant :
- des versions compilées avec AddressSanitizer et UndefinedBehaviorSanitizer, afin de rendre visibles les erreurs de mémoire et les comportements indéfinis ;
- des jeux d’entrées dérivés de tests existants couvrant des cas limites ;
- des harnais en C et C++ pour une douzaine d’interfaces, dont plusieurs fonctions de décompression et outils annexes ;
- des variantes de compilation activant des chemins cachés par la configuration habituelle ;
- une boucle guidée par la couverture pour étendre les tests quand une piste cessait de progresser.
Le point important n’est pas l’originalité de chaque technique. Les spécialistes les utilisent déjà. La nouveauté tient à leur enchaînement autonome sur une bibliothèque réelle, sans que l’opérateur décrive chaque étape.
Le harnais le plus productif ne s’est pas contenté d’envoyer des octets arbitraires aux interfaces de fichiers compressés. Il a construit des états valides qui ne se produisent que lorsque le système d’exploitation exerce une contre-pression sur les entrées-sorties. Autrement dit, l’agent a cherché à reproduire une situation d’exécution crédible plutôt qu’un simple plantage artificiel.
Une journée gagnée ne signifie pas une faille confirmée
Le chiffre spectaculaire — une journée au lieu de plusieurs semaines — concerne la construction de l’infrastructure de test. Il ne permet pas de conclure que toutes les alertes produites sont exploitables, ni même qu’elles recevront un identifiant CVE.
Trail of Bits indique que plusieurs résultats sont en cours de divulgation coordonnée. Tant que les mainteneurs n’ont pas analysé les causes, préparé les correctifs et publié une version sûre, l’entreprise ne révèle ni les mécanismes précis ni la gravité définitive. Cette retenue fait partie du travail de sécurité : publier trop tôt une preuve d’exploitation peut donner une avance aux attaquants.
L’expérience fournit aussi un contre-exemple instructif. Le modèle a détecté un plantage lié à un rappel nul dans une fonction de décompression. Le bug était réel au sens technique, mais il supposait qu’un programme appelant prépare un état extrêmement improbable. GPT-5.5-Cyber l’a classé comme non atteignable dans les conditions visées et a poursuivi sa recherche.
Ce tri est décisif. Un outil capable de générer des milliers de rapports peu réalistes ne renforce pas un projet open source ; il consomme le temps de ses mainteneurs. La performance utile ne se mesure donc pas au nombre d’alertes, mais à la proportion de résultats reproductibles, atteignables et suffisamment graves pour justifier un correctif.
Patch the Planet veut fermer la boucle jusqu’au correctif
OpenAI a présenté Patch the Planet le 22 juin avec une ambition plus large que la seule détection. Le programme associe ses modèles spécialisés et Codex Security aux chercheurs de Trail of Bits. HackerOne et Calif participent également au tri, à la recherche ciblée et à la divulgation coordonnée.
Les premiers projets cités comprennent notamment cURL, NATS Server, pyca/cryptography, Sigstore, aiohttp, Go, freenginx, Python et python.org. Ils se trouvent au cœur des communications réseau, de la cryptographie, des chaînes d’approvisionnement logicielles ou des environnements de développement.
OpenAI indique que des chercheurs de Trail of Bits travaillent à temps plein avec Codex et GPT-5.5-Cyber sur 19 projets dans le premier sprint. L’entreprise affirme que des centaines de problèmes ont été identifiés et des dizaines de correctifs fusionnés, tandis que d’autres résultats restent sous embargo. Trail of Bits évoque désormais une collaboration avec plus de 30 projets, ce qui suggère un périmètre plus large que l’équipe initialement mobilisée à plein temps.
Le dispositif produit aussi des outils réutilisables : harnais de fuzzing, modèles de menace, tests différentiels, analyse de variantes de CVE historiques et chaînes de filtrage des doublons. L’objectif n’est pas seulement de livrer une liste de défauts, mais de laisser aux mainteneurs une infrastructure qu’ils pourront continuer à exploiter.
La validation humaine reste le goulot d’étranglement
OpenAI reconnaît que ses modèles génèrent encore beaucoup de faux positifs. Chaque résultat du programme est donc revu par un chercheur de Trail of Bits avant d’être transmis au projet concerné. Les experts reproduisent le problème, vérifient sa compatibilité avec le modèle de menace, éliminent les doublons, réévaluent la gravité et préparent des tests ou un correctif selon les règles du mainteneur.
Cette organisation corrige une faiblesse structurelle de l’automatisation : un modèle juge facilement un plantage intéressant sans comprendre si l’interface a été utilisée correctement, si l’entrée est contrôlable par un attaquant ou si une protection déjà déployée rend l’exploitation impossible.
Les documentations d’OSS-Fuzz insistent elles aussi sur ce contexte. Un dépassement de tampon mérite généralement une priorité élevée, tandis qu’un délai d’exécution ou une consommation excessive de mémoire peut être moins urgent. La gravité dépend toujours de la manière dont le logiciel est déployé et des données qu’un acteur hostile peut réellement lui fournir.
L’humain ne disparaît donc pas de la boucle. Son rôle se déplace : moins de temps à écrire l’échafaudage technique, davantage à définir les critères de validité, reproduire les résultats et décider comment les corriger sans casser les usages légitimes.
L’avantage défensif dépend désormais de la vitesse de correction
La même automatisation peut servir une équipe de sécurité ou un attaquant. Jusqu’ici, monter une campagne de fuzzing sur mesure exigeait de connaître les interfaces, les compilateurs, les outils de détection mémoire et les conditions réalistes d’exécution. Ce coût constituait une barrière pratique pour les adversaires peu expérimentés.
Trail of Bits estime que cette barrière s’effondre. Un spécialiste peut auditer beaucoup plus de projets ; un opérateur moins qualifié peut, lui aussi, déléguer la préparation technique à un agent. La découverte accélérée ne crée donc un avantage défensif que si la validation, la correction et le déploiement suivent au même rythme.
Pour les organisations qui dépendent de composants open source, plusieurs conséquences se dessinent :
- connaître précisément les bibliothèques présentes dans leurs produits devient indispensable pour réagir à une divulgation ;
- les projets critiques auront besoin de canaux structurés pour recevoir des preuves reproductibles plutôt que des rapports générés en masse ;
- les correctifs devront être testés et distribués plus vite, sans sacrifier la stabilité ;
- les modèles spécialisés devront fonctionner dans des environnements isolés, avec des règles de divulgation strictes ;
- les budgets doivent financer la maintenance humaine, pas uniquement l’achat d’outils de détection.
Le risque serait de multiplier les scanners sans renforcer les équipes capables d’interpréter leurs sorties. Une file d’attente de vulnérabilités validées mais non corrigées reste une exposition, même si sa découverte a coûté moins cher.
Le vrai progrès se mesurera dans les versions corrigées
L’expérience menée sur zlib montre qu’un agent peut désormais accomplir une part substantielle du travail préparatoire d’un audit dynamique. Elle ne prouve pas qu’il peut remplacer un chercheur en sécurité, encore moins qu’il sait seul mesurer l’impact d’une faille dans tous les contextes.
Patch the Planet adopte pour l’instant la bonne unité de résultat : non pas le nombre de bugs annoncés, mais la chaîne complète allant de la découverte au correctif testé, avec le mainteneur aux commandes. Les prochains rapports techniques permettront de juger la qualité réelle des problèmes trouvés, leur gravité et le taux de bruit après validation.
Une journée pour construire un laboratoire de fuzzing est un gain spectaculaire. Mais, pour les utilisateurs de zlib et des autres briques critiques, la seule victoire qui compte reste plus discrète : une version corrigée, publiée avant qu’un attaquant n’exploite la même accélération.
Références
- Trail of Bits, « GPT-5.5-Cyber built a zlib fuzzing lab in a day », 2 juillet 2026
- OpenAI, « Patch the Planet: a Daybreak initiative to support open source maintainers », 22 juin 2026
- OSS-Fuzz, documentation générale et présentation du fuzzing
- OSS-Fuzz, recherche sur la génération de harnais de fuzzing avec des modèles de langage
- OSS-Fuzz, recommandations pour analyser et prioriser les bugs
