OSS-Fuzz ne veut plus seulement trouver les failles

Les projets open source savent désormais repérer des bugs à la chaîne. Le vrai bouchon arrive juste après : comprendre la cause, écrire le correctif, le tester et convaincre un mainteneur de le relire. Google veut raccourcir ce tunnel avec CodeMender, un agent de sécurité branché sur OSS-Fuzz. L’idée est séduisante, mais elle ne transforme pas un patch généré en vérité révélée : le mainteneur garde le dernier mot, et c’est heureux.

Le fuzzing ne veut plus s’arrêter au rapport

Depuis 2016, OSS-Fuzz exécute en continu des campagnes de fuzzing sur des projets open source. Le principe est brutal et efficace : envoyer au logiciel des entrées inattendues, observer les plantages et transmettre les cas reproductibles aux équipes concernées. La documentation du service indique qu’il prend en charge plusieurs langages, dont le C, le C++, Rust, Go, Python, JavaScript et Lua. Google le présente comme un service gratuit destiné aux projets open source éligibles, pas comme un scanner magique que n’importe quel dépôt peut appeler sans préparation.

Cette approche a un avantage décisif sur un agent lancé à l’aveugle : le bug commence par un signal d’exécution concret. Un crash reproductible réduit déjà une bonne partie du bruit qui empoisonne les audits automatisés. Mais il laisse encore une corvée considérable : remonter jusqu’à la cause racine, choisir une correction qui ne déplace pas le problème et vérifier que le logiciel continue de fonctionner. Trouver la faille n’est donc que la moitié du travail. Parfois même, c’est la moitié la plus facile.

CodeMender arrive précisément à cet endroit. Quand OSS-Fuzz valide une vulnérabilité, le pipeline lui transmet les détails du crash et le contexte du code source. L’agent explore plusieurs chemins et hypothèses, cherche la cause racine, puis propose un correctif complet. Google décrit le système comme une étape supplémentaire au-dessus du fuzzing : l’IA ne remplace pas la détection, elle tente de convertir un signal fiable en modification examinable.

Illustration : évolution d’OSS-Fuzz, du signal de vulnérabilité au correctif vérifié avec CodeMender. Source : Google, « From Finding to Fixing: Reducing maintainer burden with automated patches » — https://blog.google/security/from-finding-to-fixing-reducing-maintainer-burden-with-automated-patches/

Le détail qui évite le grand n’importe quoi

Google sait très bien que les mainteneurs n’ont pas besoin d’une nouvelle avalanche de demandes de fusion approximatives. Le billet officiel reconnaît que les dépôts reçoivent déjà beaucoup de contributions produites par des IA, avec un coût de triage parfois supérieur au bénéfice attendu. La promesse de CodeMender repose donc moins sur la génération brute que sur une chaîne de validation avant transmission.

Le pipeline vérifie d’abord les règles du dépôt. Si un projet refuse les contributions générées par une IA, Google indique qu’il n’enverra pas de proposition. Ce point paraît évident, mais il tranche avec les outils qui considèrent chaque dépôt public comme une autorisation implicite de produire du code. L’open source donne accès au code ; il ne donne pas automatiquement le droit d’inonder ses mainteneurs de correctifs fabriqués à la chaîne.

Les correctifs retenus sont ensuite testés dans un environnement isolé. Google affirme vérifier la compilation, la résolution du crash et l’absence de régression dans les tests fonctionnels disponibles. Pendant la phase bêta, des ingénieurs de Google relisent aussi les propositions avant leur livraison. Cette supervision humaine est importante : elle transforme le patch en suggestion fortement contrôlée, pas en écriture automatique dans la branche principale.

La nuance est encore plus importante pour les projets anciens, mal testés ou très dépendants de comportements implicites. Un correctif peut faire disparaître le crash observé tout en cassant un format accepté depuis quinze ans. Il peut aussi fermer le symptôme et laisser une variante exploitable dans un autre chemin. Les tests isolés augmentent la confiance ; ils ne prouvent pas que la correction est complète dans tous les contextes.

Pour l’instant, un périmètre volontairement étroit

Le lancement ne concerne pas tout le catalogue OSS-Fuzz. Google précise que les correctifs automatisés sont disponibles pour les projets C et C++ dans lesquels OSS-Fuzz détecte des vulnérabilités de sûreté mémoire. Les autres langages pris en charge par le fuzzing ne bénéficient donc pas nécessairement de la génération de patchs. Même chose pour les défauts qui ne se traduisent pas par un crash ou qui demandent une compréhension métier profonde.

Cette restriction est plutôt saine qu’agaçante. La sûreté mémoire fournit des traces d’exécution et des critères de validation plus nets qu’un défaut d’autorisation ou une logique métier ambiguë. Demander à un agent de corriger un dépassement de tampon reproductible est déjà délicat ; lui demander de deviner la politique exacte d’un compte administrateur serait une autre catégorie de problème. Le périmètre réduit indique surtout où Google estime pouvoir mesurer le résultat sans vendre une certitude en carton.

Les projets déjà inscrits à OSS-Fuzz n’auraient pas de configuration supplémentaire à ajouter pour recevoir les propositions éligibles, selon Google. Ils peuvent toutefois désactiver la remédiation automatisée en modifiant leur politique de soumission. Là encore, la possibilité de refus compte autant que la fonction : un mainteneur doit pouvoir choisir le niveau d’automatisation compatible avec son équipe et ses règles de contribution.

Le correctif ne dispense pas de comprendre le bug

Le premier risque est le faux sentiment de sécurité. Un patch qui compile et fait passer les tests n’est pas forcément le bon patch. Les suites de tests mesurent ce qu’elles couvrent, tandis qu’une vulnérabilité peut vivre dans une combinaison d’entrées ou d’états que personne n’a écrite dans un scénario de test. La validation automatisée est une barrière ; elle ne remplace ni l’analyse du code ni la connaissance du projet.

Le deuxième risque est organisationnel. Si une équipe accepte les propositions uniquement parce qu’elles viennent d’un pipeline estampillé Google, elle déplace la confiance au lieu de la contrôler. Chaque correctif doit rester traçable : problème initial, preuve de reproduction, hypothèse de cause, changement effectué, tests exécutés et limites connues. Sans cette chaîne, le diff devient une pièce jointe impressionnante que personne n’ose vraiment contester.

Le troisième risque concerne la responsabilité. Quand un agent propose une correction, le mainteneur reste celui qui décide de l’intégrer, de la publier et d’en assumer les conséquences. C’est moins confortable qu’un bouton « réparer », mais c’est la seule manière raisonnable de traiter du code dont dépendent des utilisateurs réels. L’IA peut accélérer le travail de vérification ; elle ne peut pas signer à la place de l’équipe qui maintient le logiciel.

Ce que les mainteneurs peuvent en tirer

Pour un projet open source, le bénéfice potentiel est concret : réduire le délai entre la découverte et la proposition d’un correctif exploitable. Les équipes qui manquent de temps peuvent récupérer une première analyse et consacrer leur énergie à la revue, aux tests complémentaires et à la publication. Le gain sera surtout visible sur les projets déjà structurés, avec une compilation reproductible, des tests utiles et des règles de contribution explicites.

La bonne méthode reste assez terre à terre. Vérifie que le dépôt est bien couvert par OSS-Fuzz, lis la politique de soumission, examine le crash avec le correctif et rejoue les tests dans ton propre environnement. Cherche aussi les effets de bord : changement de comportement, compatibilité binaire, performances, formats acceptés et chemins d’erreur voisins. Un patch généré peut faire gagner des heures ; une revue bâclée peut en faire perdre des semaines.

CodeMender ne signe pas la fin des mainteneurs. Il formalise plutôt une direction : les outils de sécurité ne veulent plus seulement produire des alertes, ils veulent livrer des modifications prêtes à examiner. C’est utile si la preuve reste visible, si le dépôt peut refuser et si l’humain conserve le contrôle de la fusion. Sinon, on aura simplement remplacé le vieux backlog de failles par un nouveau backlog de diffs brillants.

Sources

Google, « From Finding to Fixing: Reducing maintainer burden with automated patches » — https://blog.google/security/from-finding-to-fixing-reducing-maintainer-burden-with-automated-patches/ — annonce du raccordement entre OSS-Fuzz et CodeMender, validation, bêta et périmètre C/C++.

OSS-Fuzz, « AI patches (beta) » — https://google.github.io/oss-fuzz/ai-patches-beta/ — fonctionnement des propositions de correctifs, conditions d’éligibilité et options de refus.

OSS-Fuzz, documentation officielle — https://google.github.io/oss-fuzz/ — rôle du fuzzing, langages pris en charge, historique et limites du service.

Google DeepMind, « Introducing CodeMender, an AI agent for code security » — https://deepmind.google/blog/introducing-codemender-an-ai-agent-for-code-security/ — présentation de l’agent de sécurité et de son approche de génération de correctifs.

—

Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.