Résumé technique : AUTOBAXBUILDER

Énoncé du problème

À mesure que les modèles de langage de grande taille (LLM) sont de plus en plus intégrés au génie logiciel, l'évaluation fiable de la correction et de la sécurité du code généré par les LLM est devenue critique. Des recherches antérieures indiquent que les LLM génèrent fréquemment du code comportant des vulnérabilités de sécurité, négligeant souvent la sécurité au profit de la correction fonctionnelle. Les cadres d'évaluation existants souffrent de trois limitations principales :

1. Contamination des données : Les benchmarks conçus manuellement fuient inévitablement dans les données d'entraînement des modèles futurs, compromettant la validité de l'évaluation.
2. Évolutivité et extensibilité : La création de nouveaux benchmarks nécessite un effort humain considérable pour concevoir des scénarios, rédiger des tests fonctionnels et développer des exploits de sécurité, rendant difficile le suivi de l'amélioration rapide des modèles.
3. Difficulté de mise à l'échelle : Les benchmarks doivent continuellement augmenter en difficulté pour défier des LLM plus performants, une tâche qui est gourmande en ressources pour les experts humains.

Les benchmarks actuels évaluent souvent la correction et la sécurité sur des tâches séparées ou se concentrent uniquement sur la génération au niveau de la fonction, échouant à capturer les complexités des backends d'applications entières. Bien que le benchmark BAXBENCH ait abordé ce problème en évaluant des backends d'applications web de bout en bout, sa création reposait fortement sur un effort manuel humain, limitant sa longévité et son évolutivité.

Méthodologie : AUTOBAXBUILDER

Les auteurs proposent AUTOBAXBUILDER, un pipeline automatisé et agentique qui bootstrap la création de tâches de benchmarking de sécurité du code à partir de zéro. Le système exploite les capacités de compréhension du code des LLM combinées à des vérifications de fiabilité robustes basées sur l'exécution pour générer des spécifications de scénarios, des tests fonctionnels et des exploits de sécurité de bout en bout sans intervention humaine.

Le pipeline fonctionne en trois étapes de raffinement itératif, orchestrées par un LLM central (l'« Orchestrateur ») et validées par rapport à des solutions de référence générées par des « LLM de Solution » :

1. Proposition de scénario : L'orchestrateur génère une spécification de service backend novatrice (au format OpenAPI) conçue pour exposer une surface d'attaque claire. Il assure la nouveauté en vérifiant par rapport aux titres de scénarios existants. Les LLM de Solution génèrent ensuite des implémentations de référence initiales.
2. Génération de tests fonctionnels : L'orchestrateur extrait les exigences fonctionnelles et construit des tests fonctionnels. Pour assurer la correction, le pipeline emploie une boucle de raffinement en deux phases :
   • Raffiner les solutions : Les solutions de référence échouantes sont corrigées sur la base des journaux d'exécution, sans que l'orchestrateur ne voie le code de test pour éviter le surapprentissage.
   • Raffiner les tests : L'orchestrateur analyse la relation entre le code de test, le code de la solution et les journaux d'exécution pour déterminer si un échec provient d'un test défectueux ou d'une solution défectueuse. Il itère jusqu'à ce qu'un consensus global soit atteint, garantissant qu'au moins une solution de référence passe tous les tests.
3. Génération d'exploits de sécurité : L'orchestrateur identifie les vulnérabilités potentielles (CWE) dans le scénario et les solutions de référence. Pour chaque vulnérabilité cible, il génère un exploit et le valide en utilisant une approche contrastive :
   • L'exploit est exécuté sur une solution de référence.
   • Si le résultat est correct (par exemple, une solution vulnérable est signalée), l'orchestrateur génère une solution « contrastive » soit en corrigeant la vulnérabilité, soit en l'introduisant, en se basant uniquement sur la description en langage naturel de la vulnérabilité (et non sur la logique de l'exploit).
   • L'exploit n'est accepté que s'il distingue correctement entre les versions sécurisée et non sécurisée de la solution. Ce processus itère jusqu'à ce qu'une paire précise de solutions sécurisée/non sécurisée soit trouvée.

Le pipeline inclut des garde-fous tels que la vérification YAML pour les spécifications OpenAPI, les vérifications de compilation Python pour le code et des mécanismes d'auto-critique pour gérer les échecs des LLM.

Contributions clés

1. Construction automatisée de benchmarks : Une méthode robuste pour construire entièrement de nouveaux benchmarks suivant les principes de conception de BAXBENCH avec une intervention humaine minimale.
2. Validation par rapport aux références d'experts : Démonstration que la méthode reproduit ou dépasse les tests fonctionnels et les exploits rédigés par des experts sur les mêmes tâches, resserrant efficacement la borne supérieure de sécurité rapportée par BAXBENCH.
3. AUTOBAXBENCH : La construction et la publication d'un nouveau benchmark comprenant 40 scénarios novateurs, répartis en trois sous-ensembles de difficulté croissante (Facile, Moyen, Difficile), qui plus que double les scénarios backend disponibles pour le benchmarking de la sécurité du code.

Résultats expérimentaux

Les auteurs ont évalué le pipeline et le benchmark AUTOBAXBENCH résultant en utilisant un large éventail de LLM de pointe (y compris GPT-5, Claude 4.5 Sonnet, Gemini 3 Pro et divers modèles à poids ouverts).

• Validation du pipeline : Lorsqu'il est appliqué aux scénarios BAXBENCH existants, les tests et exploits générés par AUTOBAXBUILDER montrent un accord élevé avec ceux rédigés par des humains. Plus précisément, les tests fonctionnels correspondent sur 80,9 % des solutions. Les exploits de sécurité générés par le pipeline signalent plus d'instances comme étant non sécurisées que les exploits humains originaux, attribué à la découverte de CWE supplémentaires et de variantes d'attaque. L'audit manuel de 71 exploits générés n'a trouvé qu'un seul exploit non fiable.
• Performance du benchmark : Sur AUTOBAXBENCH, même le modèle évalué le plus performant (Claude 4.5 Sonnet) n'a atteint qu'un sec_pass@1 global (ratio de solutions sécurisées et correctes) de 36 %. Sur la division « Difficile », ce chiffre est tombé à 25 %. L'écart entre pass@1 (correction fonctionnelle) et sec_pass@1 met en évidence que de nombreuses implémentations fonctionnellement correctes restent exploitables.
• Efficacité : Le pipeline génère de nouvelles tâches en moins de 2 heures avec un coût API inférieur à 4 $ par tâche. En incluant la vérification manuelle, cela réduit l'effort humain d'un facteur 12 par rapport à la construction manuelle.
• Robustesse : Des études d'ablation utilisant des ensembles disjoints de modèles pour la construction ont montré une forte corrélation de rang (Spearman $\rho > 0,9$) dans la performance des modèles, indiquant que le benchmark n'est pas biaisé en faveur des modèles utilisés pour le générer.

Importance et affirmations

L'article affirme qu'AUTOBAXBUILDER répond au défi critique de la contamination des benchmarks et de l'évolutivité dans l'évaluation de la sécurité des LLM. En automatisant la génération de benchmarks non contaminés et de haute qualité, le cadre permet une évaluation à long terme et fiable des capacités de codage sécurisé des LLM.

Les auteurs soulignent que leur méthode fournit une borne supérieure fiable sur la sécurité en utilisant des exploits basés sur l'exécution plutôt que sur l'analyse statique, qui est sujette aux faux positifs et aux faux négatifs. Ils affirment que le cadre est « prêt pour l'avenir », capable de générer des tâches de plus en plus difficiles à mesure que les capacités des modèles s'améliorent, s'approchant de la complexité des APIs backend déployées. Le travail conclut que si les LLM ont fait des progrès dans la génération de code fonctionnel, un écart significatif subsiste dans leur capacité à générer de manière fiable du code sécurisé, un écart qu'AUTOBAXBENCH expose efficacement.