Des problèmes potentiels découverts dans curl par un outil d’IA

• Joshua Rogers a trouvé une vaste liste de problèmes potentiels dans la base de code de curl à l’aide de son propre ensemble d’outils basé sur l’IA
• Cette liste comprend non seulement de légers défauts de style de code, mais aussi de petits bugs et des failles de sécurité potentielles
• Les problèmes détectés sont pour la plupart de petits bugs, mais l’un ou deux d’entre eux pourraient être des défauts de sécurité critiques
• Comme il s’agit de problèmes qui n’avaient pas été découverts auparavant, le résultat a une réelle valeur
• Sur la base de ce qui a été signalé, 22 corrections de bugs ont déjà été effectuées
• Il reste encore plus du double d’issues non vérifiées, et les revues ainsi que les corrections se poursuivent
• Les problèmes détaillés sont indiqués comme "Reported in Joshua's sarif data", et si cela vous intéresse, vous pouvez consulter ces données directement

[GN⁺]

Avis Hacker News

• C’est exactement l’image idéale que je me fais d’un « compagnon de codage IA »
  Au lieu d’écrire ou de corriger le code directement, je veux qu’il indique les parties suspectes du code et les endroits que je devrais examiner plus en détail
  Quand je demande à Claude de trouver des bugs dans ma bibliothèque C de 20 000 lignes, il découpe les fichiers et cherche certains motifs de code avec grep, pour au final simplement me lister mes commentaires FIXME (rires)
  En réalité, c’est du niveau d’un simple script bash, donc assez décevant
  ChatGPT est encore moins utile : il se contente de répéter « tout a l’air bien ! formidable ! high five ~ »
  Jusqu’ici, l’analyse statique traditionnelle m’a bien plus aidé à trouver de vrais bugs, mais ce n’est pas parce que l’analyse statique est propre qu’il n’y a pas de bugs logiques
  C’est précisément là, à mon avis, que les LLM devraient briller
  S’il faut construire un environnement extrêmement personnalisé pour obtenir d’un LLM des informations vraiment utiles sur des bugs potentiels, son utilité finit par diminuer, tout comme les outils d’analyse statique sont peu utilisés quand ils exigent une configuration trop complexe
  • On parle très peu du fait que beaucoup de programmeurs aiment concevoir et coder eux-mêmes (hors code répétitif en particulier), mais n’aiment pas faire de revue de code
    L’idée que l’IA écrive le code et que les programmeurs ne fassent plus que de la revue me semble être une direction bancale
    Bien sûr, je comprends pourquoi on essaie de vendre cela avec l’argument « le nombre de lignes de code augmente ~ »
  • Quand Claude produit des résultats décevants comme ceux évoqués, une méthode qui marche souvent consiste à « demander directement à Claude quel prompt serait efficace »
    Par exemple : « Quel prompt devrais-je utiliser pour demander à Claude Code d’ignorer les commentaires comme FIXME ou TODO et d’élaborer un plan efficace pour relire des bugs logiques ? »
    Le prompt obtenu est trop long pour être mis ici, mais on peut voir un exemple publié sur gist
    On peut ensuite continuer à l’améliorer à partir de ce résultat et même en faire un agent
  • Cursor BugBot correspond assez bien à ce rôle
    Après l’essai gratuit, il a été suffisamment apprécié dans notre équipe de développement pour que nous l’adoptions officiellement
    À part quelques faux positifs occasionnels, c’est très utile
    Cela fait gagner du temps à la fois à l’auteur de la PR et au relecteur
  • J’ai déjà demandé à Claude : « Il y a un bug de lenteur de réponse sur un endpoint spécifique, sans lien avec l’utilisation CPU/mémoire ni avec la DB ; quelle peut en être la cause ? » et, après quelques itérations, j’ai obtenu une piste sur un bug vraiment difficile à trouver
    Il m’est déjà arrivé de résoudre ainsi en quelques indices un problème qui m’aurait auparavant pris des heures
    Ce genre d’usage de l’IA me rend très optimiste
  • GPT-5 est bien moins flatteur que les modèles précédents dans ce genre de situation
    J’ai été un peu surpris de voir sortir une réponse du style « tout a l’air bien »
    Quand je l’utilise dans Codex CLI, il soulève souvent des doutes
    Gemini 2.5 Pro est aussi correct sur ce point
• Je ne m’attendais vraiment pas à voir une anecdote positive mêlant curl et IA
  Vu l’historique, ça vaut le coup de jeter un œil à ce lien de recherche HN sur curl+AI
  • Je trouve impressionnant que Daniel Stenberg ait abordé cette fois la question avec autant d’ouverture, malgré les nombreux problèmes qu’il a eus par le passé avec des rapports de bugs liés à l’IA
• Le point clé semble être l’idée de « boîte à outils ». Il ne confond pas cela avec un pilote automatique ; il combine correctement les outils et les utilise comme un système
  • J’imagine que l’auteur a donné davantage de détails dans le billet d’origine blog de référence (mention Mastodon : lien associé)
  • C’est dommage que la discussion ait été réduite à une opposition binaire du type « conduite autonome vs abandon total »
    Au fond, la bonne grille de lecture semble plutôt être la différence entre quelqu’un qui comprend vraiment ce qu’il fait et quelqu’un qui code simplement à l’ambiance
  • Stenberg parle d’une boîte à outils, mais je serais aussi curieux de connaître le point de vue du contributeur qui a effectivement utilisé ces outils
• Il y a 55 PR fermées dans le dépôt curl qui mentionnent « sarif data », et ce sont apparemment celles dont il est question ici
  Cela contraste avec le fait que Daniel Stenberg avait auparavant été harcelé par des pseudo-problèmes de sécurité médiocres générés par l’IA
  À propos de HackerOne : « Les gens qui soumettent des signalements merdiques générés par IA sont bannis immédiatement. C’est pratiquement une attaque DDoS. J’ai presque envie de leur facturer le temps perdu »
  Voir aussi un billet de blog de Daniel publié en janvier cette année : The I in LLM stands for Intelligence?
  • Certains bugs (par exemple l’utilisation d’un mauvais spécificateur de format printf pour size_t) peuvent être détectés simplement avec de bons flags d’avertissement du compilateur
    Que l’IA conseille « il manque des flags d’avertissement importants du compilateur » serait déjà très utile
    Une partie des PR semble venir de correspondances Dependabot, et on peut voir une liste plus précise des PR en recherchant « Joshua sarif data » ici
  • Les modèles utilisés à l’époque semblent s’être beaucoup améliorés
    J’imagine que c’est ce qui explique le changement d’impression de Daniel Stenberg
• Parmi les scanners SAST commerciaux, il y en a de bons, mais la plupart ne sont pas satisfaisants
  Beaucoup plaident pour l’adoption de technologies SAST fondées sur l’IA, et des produits existent effectivement sur ce créneau, mais la grande majorité reste encore en dessous des attentes
  Être simplement déçu serait déjà le meilleur scénario ; dans le pire des cas, cela peut créer un faux sentiment de sécurité, ce qui est dangereux
  Une critique argumentée des scanners SAST basés sur l’IA est présentée ici
• Il n’était pas facile de comprendre immédiatement quels outils IA précis avaient été utilisés
  Comme plusieurs outils n’avaient pas réussi à trouver les bugs auparavant, je me demande pourquoi cette stratégie-ci a été plus efficace
  • On peut trouver davantage d’informations dans ce blog avec un chapitre consacré aux produits
    J’imagine que le lien Mastodon servait à confirmer qu’il s’agissait bien d’un vrai bug, même avec un extrait de code erroné
• Dans le même registre, voici un cas parlant de gens qui « font quelque chose avec de l’IA sans savoir eux-mêmes ce qu’ils font » : You did this with an AI and you do not understand what you're doing here