Fuzzing alimenté par l’IA : briser la barrière de la chasse aux insectes

Depuis 2016, OSS-Fuzz a été à l’avant-garde de la découverte automatisée des vulnérabilités pour les projets open source. La découverte de vulnérabilités est un élément important pour assurer la sécurité des chaînes d’approvisionnement logicielles, c’est pourquoi notre équipe travaille constamment à l’amélioration d’OSS-Fuzz. Au cours des derniers mois, nous avons testé si nous pouvions améliorer les performances d’OSS-Fuzz en utilisant les grands modèles linguistiques (LLM) de Google.

Cet article de blog partage notre expérience dans l’application réussie de la puissance générative des LLM pour améliorer la technique automatisée de détection des vulnérabilités connue sous le nom de fuzz testing (« fuzzing »). En utilisant les LLM, nous sommes en mesure d’augmenter la couverture de code pour les projets critiques utilisant notre service OSS-Fuzz sans écrire manuellement de code supplémentaire. L’utilisation des LLM est une nouvelle façon prometteuse d’étendre les améliorations de sécurité à plus de 1 000 projets actuellement fuzzés par OSS-Fuzz et d’éliminer les obstacles à l’adoption du fuzzing par de futurs projets.

Fuzzing assisté par LLM

Nous créé le service OSS-Fuzz pour aider les développeurs open source à trouver des bogues dans leur code à grande échelle, en particulier les bogues qui indiquent des vulnérabilités de sécurité. Après plus de six ans d’utilisation d’OSS-Fuzz, nous prenons désormais en charge gratuitement plus de 1 000 projets open source avec un fuzzing continu. Comme le Vulnérabilité au cœur brisé nous l’a montré, les bogues qui pourraient être facilement trouvés avec le fuzzing automatisé peuvent avoir des effets dévastateurs. Pour la plupart des développeurs open source, la mise en place de leur propre solution de fuzzing peut coûter du temps et des ressources. Avec OSS-Fuzz, les développeurs peuvent intégrer leur projet pour une découverte de bugs gratuite et automatisée à grande échelle.  

Depuis 2016, nous avons trouvé et vérifié un correctif pour plus de 10 000 failles de sécurité. Nous pensons également qu’OSS-Fuzz pourrait probablement trouver encore plus de bogues avec une couverture de code accrue. Le service de fuzzing ne couvre en moyenne qu’environ 30 % du code d’un projet open source, ce qui signifie qu’une grande partie du code de nos utilisateurs reste intacte par le fuzzing. Recherche récente suggère que le moyen le plus efficace d’augmenter ce résultat consiste à ajouter des cibles de fuzz supplémentaires pour chaque projet, l’une des rares parties du flux de travail de fuzzing qui n’est pas encore automatisée.

Lorsqu’un projet open source est intégré à OSS-Fuzz, les responsables investissent initialement du temps pour intégrer leurs projets dans l’infrastructure, puis ajoutent des cibles fuzz. Les cibles fuzz sont des fonctions qui utilisent une entrée aléatoire pour tester le code ciblé. L’écriture de cibles fuzz est un processus manuel spécifique au projet, similaire à l’écriture de tests unitaires. Les avantages continus du fuzzing en matière de sécurité valent la peine pour les responsables de cet investissement initial en temps, mais écrire un ensemble complet de cibles de fuzz est une attente difficile pour les responsables du projet, qui sont souvent des bénévoles.

Mais et si les LLM pouvaient écrire des cibles fuzz supplémentaires pour les responsables ?

« Hey LLM, fuzz ce projet pour moi »

Pour découvrir si un LLM pouvait réussir à écrire de nouvelles cibles fuzz, nous avons construit un cadre d’évaluation qui connecte OSS-Fuzz au LLM, mène l’expérience et évalue les résultats. Les étapes ressemblent à ceci :

1. OSS-Fuzz Outil Fuzz Introspecteur identifie une partie sous-fuzzée et à fort potentiel du code de l’exemple de projet et transmet le code au cadre d’évaluation.
2. Le cadre d’évaluation crée une invite que le LLM utilisera pour écrire la nouvelle cible fuzz. L’invite inclut des informations spécifiques au projet.
3. Le cadre d’évaluation prend la cible fuzz générée par le LLM et exécute la nouvelle cible.
4. Le cadre d’évaluation observe l’exécution pour tout changement dans la couverture du code.
5. Dans le cas où la cible fuzz ne parvient pas à se compiler, le cadre d’évaluation invite le LLM à écrire une cible fuzz révisée qui corrige les erreurs de compilation.

Présentation de l’expérience : l’expérience illustrée ci-dessus est un processus entièrement automatisé, depuis l’identification du code cible jusqu’à l’évaluation du changement dans la couverture du code.

Au début, le code généré à partir de nos invites ne se compilerait pas ; cependant, après plusieurs séries de ingénierie rapide et en essayant les nouvelles cibles fuzz, nous avons vu les projets gagner entre 1,5 % et 31 % de couverture de code. L’un de nos exemples de projets, tinyxml2, est passé de 38% couverture de ligne à 69% sans aucune intervention de notre équipe. L’affaire de minusculexml2 nous l’a appris : lorsque des cibles fuzz générées par LLM sont ajoutées, tinyxml2 couvre la majorité de son code. 

Exemples de cibles fuzz pour tinyxml2 : chacune des cinq cibles fuzz affichées est associée à une partie différente du code et contribue à l’amélioration globale de la couverture.

Répliquer manuellement les résultats de tinyxml2 aurait nécessité au moins une journée de travail, ce qui signifierait plusieurs années de travail pour couvrir manuellement tous les projets OSS-Fuzz. Compte tenu des résultats prometteurs de tinyxml2, nous souhaitons les implémenter en production et étendre une couverture automatique similaire à d’autres projets OSS-Fuzz.

De plus, dans le projet OpenSSL, notre LLM a pu générer automatiquement un objectif de travail qui a redécouvert CVE-2022-3602, qui se trouvait dans une zone de code qui n’avait auparavant pas de couverture fuzzing. Bien qu’il ne s’agisse pas d’une nouvelle vulnérabilité, cela suggère qu’à mesure que la couverture du code augmente, nous trouverons davantage de vulnérabilités actuellement ignorées par le fuzzing.

Apprenez-en davantage sur nos résultats à travers notre exemple invites et sorties ou via notre rapport d’expérimentation. 

L’objectif : un fuzzing entièrement automatisé

Dans les prochains mois, nous ouvrirons notre cadre d’évaluation pour permettre aux chercheurs de tester leur propre génération automatique de cibles fuzz. Nous continuerons d’optimiser notre utilisation des LLM pour la génération de cibles fuzzing grâce à un réglage plus fin des modèles, une ingénierie rapide et des améliorations de notre infrastructure. Nous collaborons également étroitement avec le OSS assuré équipe sur cette recherche afin de sécuriser encore plus de logiciels open source utilisés par les clients de Google Cloud.

Nos objectifs à long terme comprennent :

• Ajout de la génération de cibles LLM fuzz en tant que fonctionnalité entièrement intégrée dans OSS-Fuzz, avec génération continue de nouvelles cibles pour les projets OSS-fuzz et aucune implication manuelle.

• Extension de la prise en charge des projets C/C++ à des écosystèmes de langage supplémentaires, comme Python et Java.

• Automatisation du processus d’intégration d’un projet dans OSS-Fuzz pour éliminer tout besoin d’écrire même des cibles fuzz initiales.

Nous travaillons vers un avenir de détection personnalisée des vulnérabilités avec peu d’effort manuel de la part des développeurs. Avec l’ajout de cibles fuzz générées par LLM, OSS-Fuzz peut contribuer à améliorer la sécurité open source pour tous.