Évaluation BLA-Bench de HCLTech sur 782 tâches d’agents de codage

En bref Nemotron 3.5 Super VL a obtenu une récompense sur 452 des 782 tâches d’abus de logique métier (57,8 %), contre 359 sur 782 (45,9 %) pour OpenAI o4-mini. Il a également enregistré une récompense de détection supérieure (51,2 % contre 40,7 %) et une récompense de remédiation supérieure (64,5 % contre 51,2 %).

L’abus de logique métier compte parmi les problèmes de sécurité applicative les plus difficiles à détecter. Contrairement aux défauts de sécurité mémoire ou aux chemins d’injection évidents, ces vulnérabilités surviennent lorsque le flux de travail prévu d’une application, les règles d’autorisation ou les transitions d’état peuvent être manipulés de façon non anticipée par les développeurs.

HCLTech Applied Research a évalué le modèle NVIDIA Nemotron 3.5 Super VL avec BLA-Bench, un banc d’essai interne conçu pour estimer la capacité des agents de codage à détecter et remédier à des vulnérabilités logiques dans des projets logiciels réalistes. Lors de cette évaluation, la configuration de Nemotron a obtenu une récompense globale supérieure, tant en détection qu’en remédiation, par rapport à la configuration de référence o4-mini.

L’évaluation a placé les deux modèles configurés dans le même Deep Agents Code harness from LangChain avec un profil d’exécution correspondant. Chaque tâche fournissait la classe CWE et une région d’investigation ciblée. Aucun exemple propre au banc d’essai, couche de récupération de la sécurité ou outil de validation spécialisé n’a été ajouté à l’agent standard.

Les résultats par catégorie et par langage sont vastes : Nemotron a enregistré un taux de récompense plus élevé dans les 10 catégories d’abus de logique métier et dans 16 des 17 cohortes de langages de programmation.

Pourquoi l’abus de logique métier est un test difficile pour les agents de codage AI

Les outils traditionnels de sécurité applicative sont très efficaces pour détecter de nombreuses classes de vulnérabilités présentant des modèles identifiables dans le code ou les flux de données. Les vulnérabilités logiques posent un défi différent.

Prenons le cas d’une application qui valide correctement chaque requête API individuelle, mais permet aux utilisateurs d’appeler ces API dans un ordre inattendu. Ou d’un service qui applique correctement les vérifications d’autorisation, mais expose une transition d’état interne qu’un attaquant peut exploiter. Les fragments de code peuvent sembler raisonnables pris isolément. Détecter la vulnérabilité exige de raisonner sur le comportement attendu de l’application et de comprendre comment un attaquant pourrait en détourner l’usage.

Pour évaluer ce problème de façon systématique, HCLTech développe BLA-Bench, un banc d’essai interne organisé selon la taxonomie 2025 du projet incubateur OWASP Top 10 for Business Logic Abuse. La version utilisée lors de cette évaluation contient 391 défis sélectionnés à partir de référentiels open source réels, avec des vulnérabilités publiquement divulguées et corrigées. Les vulnérabilités ont été choisies pour être relativement récentes afin de réduire le risque de saturation des modèles et de couvrir les dix catégories de la taxonomie.

Le banc d’essai couvre 17 langages de programmation, dont C, C++, C#, Java, JavaScript, TypeScript, Python, Go, Rust, Kotlin, Scala, Erlang, Elixir, PHP, Perl, Ruby et Dart.

Chaque défi génère deux tâches évaluées distinctement. Pour la détection, l’agent reçoit le référentiel vulnérable, la classe CWE et une zone de recherche, puis rédige le rapport des constatations. Le vérificateur de détection exige une découverte dans le bon fichier, la bonne classe CWE et la plage de lignes acceptée; il rejette les résultats non crédités pour la CWE cible et limite le nombre de constatations rapportées. Pour la remédiation, l’agent reçoit le fichier vulnérable et la région, puis modifie le référentiel; tous les contrôles statiques et tests de comportement requis doivent être réussis. Cela donne 782 tâches à récompense binaire : 391 en détection et 391 en remédiation.

BLA-Bench est intentionnellement difficile pour un agent de codage généraliste. L’invite précise la classe CWE et une région d’investigation. Cependant, l’agent standard n’a accès à aucun exemple spécifique au banc, aucun tutoriel sur la catégorie Abus de logique métier, aucune couche de récupération de la sécurité ni outil de validation spécialisé. La localisation et la remédiation reposent donc sur la reconstruction de l’invariant vulnérable à partir du référentiel et du comportement vérifié par le validateur de tâches.

Évaluation de Nemotron 3.5 Super VL dans un agent de codage avec BLA-Bench

Pour la comparaison présentée dans ce blogue, nous utilisons l’original Deep Agents Code from LangChain avec OpenAI o4-mini comme agent de référence. Nous utilisons OpenAI o4-mini comme référence fermée, économique et réputée de taille comparable au modèle Nemotron 3.5 Super VL. L’objectif va au-delà de la sélection de modèles d’agent : il s’agit de construire un agent de codage spécialisé en sécurité, d’en améliorer continuellement la qualité de détection et de remédiation, ainsi que l’efficacité opérationnelle.

• Les deux configurations ont exécuté les mêmes 782 identités de tâche : 391 tâches de détection et 391 tâches de remédiation.
• Les deux ont utilisé le code Deep Agents fourni par LangChain, sans outils spécialisés additionnels en sécurité.
• Les modèles configurés étaient NVIDIA Nemotron-3.5-Super-VL-120B-A12B et OpenAI o4-mini-2025-04-16.
• Les deux ont utilisé Harbor, le cadre d’évaluation d’agent conteneurisé, avec le même adaptateur Deep Agents et le même profil d’exécution.
• Les résultats décrivent donc les systèmes configurés complets sur ce groupe de référence, et non les poids de modèles isolés.
• Pour plus d’informations sur l’évaluation, voir les détails ci-dessous.

Meilleure récompense globale, de détection et de remédiation avec Nemotron

Figure 1. Taux de récompense globale, de détection et de remédiation observés. Plus c’est élevé, mieux c’est.

Nemotron a obtenu une récompense sur 452 des 782 tâches (57,8 %), contre 359 sur 782 (45,9 %) pour o4-mini, une différence de 93 tâches récompensées et de 11,9 points de pourcentage. Comme les identités des tâches sont appariées, l’intervalle de confiance à environ 95 % pour la différence globale est de 8,4 à 15,3 points de pourcentage.

Les résultats par tâche favorisent Nemotron dans les deux parties du benchmark. La récompense pour la détection était de 51,2 % (200 sur 391), contre 40,7 % (159 sur 391) pour o4-mini. La récompense pour la remédiation était de 64,5 % (252 sur 391), contre 51,2 % (200 sur 391). L’écart pour la remédiation était de 13,3 points de pourcentage, comparé à 10,5 points pour la détection.

Pour ce résultat de benchmark, la différence correspond à 41 tâches de détection additionnelles et 52 tâches de remédiation supplémentaires recevant la récompense complète du vérificateur. Pour une équipe de sécurité applicative, cela peut signifier que la configuration Nemotron a produit une localisation exploitable et une remédiation vérifiable dans plus de cas. Notez qu’il s’agit de résultats de benchmark, et non d’estimations des vulnérabilités de production évitées, des heures de triage sauvées ou des correctifs acceptés sans révision.

Les diagnostics d’exécution révèlent moins de marqueurs d’erreur et moins d’exceptions d’agent

Les résultats des outils sérialisés montrent des taux de marqueurs d’erreur explicites plus faibles avec Nemotron sur chaque outil de base sélectionné de l’agent à la figure 2. Les écarts les plus marqués apparaissent pour « execute » (6,6 % contre 21,6 %) et « ls » (0,7 % contre 15,5 %) ; « edit_file » demeure l’outil sélectionné avec le plus de friction pour les deux configurations (40,5 % contre 46,0 %).

Figure 2. Taux de marqueur d’erreur explicite pour les résultats des outils sérialisés sélectionnés, ordonnés par taux Nemotron du plus bas au plus élevé. Plus c’est bas, mieux c’est.

Sur l’ensemble des résultats de l’outil sérialisé analysés, 1 191 sur 21 278 résultats Nemotron (5,6 %) contenaient un marqueur d’erreur explicite, contre 831 sur 8 015 résultats o4-mini (10,4 %). Les résultats enregistrés mentionnent des exceptions d’agent dans 22 essais Nemotron sur 782 (2,8 %) et 32 sur 782 essais o4-mini (4,1 %).

La performance varie selon les catégories d’abus de la logique d’entreprise

Nemotron a enregistré un taux de récompense plus élevé qu’o4-mini dans les 10 catégories d’abus de la logique d’entreprise. Les écarts les plus notables ont été observés pour la BLA6, Validation de transition manquante (67,4 % contre 45,3 %) ; la BLA8, Divulgation d’état interne (59,5 % contre 39,2 %) ; et la BLA10, Abus de fonction masquée (60,7 % contre 42,9 %).

Les meilleurs taux de récompense par catégorie de Nemotron sont BLA6 à 67,4 % (58 sur 86), BLA10 à 60,7 % (34 sur 56), BLA3 à 60,5 % (46 sur 76) et BLA5 à 60,3 % (41 sur 68).

Figure 3. Récompense observée par catégorie d’abus de la logique d’entreprise pour Nemotron 3.5 Super VL et o4-mini, classée par la récompense Nemotron de la plus élevée à la plus faible. Plus c’est élevé, mieux c’est.

Les taux de récompense les plus faibles de Nemotron par catégorie étaient BLA7, Violation du quota de ressources (48,0 %, 48 sur 100) et BLA1, Dépassement de la limite d’action (50,0 %, 20 sur 40). Ensemble, elles représentent 140 des 782 tâches, ce qui en fait des cibles concrètes pour une meilleure localisation, une validation guidée par le vérificateur et une évaluation spécifique à la catégorie.

Récompense plus élevée dans 16 des 17 langages

Nemotron a mené dans 16 des 17 langages. La performance pour Kotlin était de 80,0 % contre 70,0 % (16 sur 20 contre 14 sur 20), un écart de 10,0 points, inférieur à celui de Scala (25,0), C# (20,8), Rust (20,0) et C++ (16,7). Dart était la seule exception en faveur d’o4-mini (80,0 % contre 60,0 % ; 10 tâches).

Figure 4. Récompense observée pour les 17 langages de programmation pour Nemotron 3.5 Super VL et o4-mini, classée par la récompense Nemotron de la plus élevée à la plus faible. Plus c’est élevé, mieux c’est.

Comment utiliser ce résultat
Utilisez la vue par langage comme carte de couverture et de priorisation. Nemotron a mené dans 16 cohortes sur 17 ; les prochains tests de régression devraient conserver cette ampleur tout en ciblant les segments à performance plus faible.

D’une évaluation de base à un agent de sécurité en amélioration continue

L’évaluation fournit une référence pour l’amélioration itérative de l’agent. Sa valeur la plus utile est diagnostique : BLA7 et BLA1 restent les segments de catégorie à plus faible performance ; les marqueurs d’erreur explicites dans les résultats d’outil demeurent concentrés dans edit_file et les trajectoires révèlent des occasions de réduire les étapes redondantes et la consommation de jetons. Les deux configurations ont aussi produit des volumes de résultats d’outils nettement différents : 21 278 résultats sérialisés pour Nemotron et 8 015 pour o4-mini, soit environ 2,65 fois plus. Cette différence au niveau du système est une cible concrète pour l’optimisation du harness agent et du modèle et pour le rapport des étapes, des jetons et de la durée mur-à-mur, en plus de la récompense.

La récompense était plus élevée pour la configuration Nemotron, mais l’efficience ne l’était pas. Sur les 782 tâches, les artefacts Harbor rapportent 567,8 millions de jetons entrée-plus-sortie pour Nemotron et 147,1 millions pour o4-mini. Le temps médian d’exécution de l’agent était de 106,1 secondes contre 62,0 secondes et le temps mural médian par essai était de 615,6 secondes contre 311,3 secondes. La comptabilisation des jetons et du cache dépend du fournisseur, alors ces totaux sont descriptifs plutôt qu’une comparaison normalisée de facturation.

Quelques prochaines étapes pour l’agent :

• Former et évaluer la détection avant la correction afin que le correctif repose sur un invariant de sécurité correctement localisé.
• Utiliser les trajectoires réussies et échouées conservées pour optimiser le choix des outils, la robustesse des modifications, la validation et la terminaison, et pas seulement les réponses finales.
• Améliorer l’efficacité des trajectoires d’agent en détectant les cycles de fichiers et d’outils répétés, en exigeant des progrès mesurables lors de la validation et en s’arrêtant ou en escaladant lorsque des itérations supplémentaires ne produisent aucune nouvelle preuve.
• Améliorer l’efficacité des jetons grâce à la compaction du contexte, à la rétention sélective de l’historique et à des limites sur la répétition des lectures de dépôt et les résultats volumineux d’outils.
• Renforcer les tranches à faible performance. Prioriser BLA7 et BLA1, améliorer la localisation de la détection et le contrôle des faux positifs et réévaluer le petit groupe Dart avant de tirer des conclusions propres à une langue.
• Mener des ablations contrôlées d’adaptateur et d’inférence avant les bancs d’essai complets, incluant des contrôles de raisonnement natifs au modèle, des budgets de raisonnement, des budgets de sortie et d’autres paramètres de génération pris en charge.
• Réévaluer le même groupe vérifié après chaque changement d’architecture du modèle ou de l’agent, puis tester la généralisation sur de nouvelles vulnérabilités tenues à l’écart.

Cette boucle constitue la valeur pratique de BLA-Bench. Elle transforme un problème complexe de sécurité applicative en un programme mesurable de développement de systèmes : évaluer, conserver les preuves, diagnostiquer le comportement du modèle et du harnais d’agent, optimiser et vérifier sur des tâches inchangées et en retrait.

Vers une correction fiable et agentique des vulnérabilités

Sur cette cohorte BLA-Bench de 782 tâches, la configuration Nemotron a produit une récompense observée plus élevée dans l’ensemble et tant pour la détection que la correction. Elle a devancé o4-mini dans les 10 catégories d’abus de la logique d’affaires et dans 16 des 17 cohortes linguistiques.

Pour HCLTech et HCLSoftware, ces résultats établissent une base de référence pour des évaluations ultérieures. La voie vers une correction agentique et fiable passe par un modèle axé sur la sécurité et un harnais d’agent qui progressent ensemble, avec des trajectoires ancrées dans des preuves exécutables et chaque optimisation mesurée selon les mêmes résultats en matière de sécurité.

Explorez et testez NVIDIA Nemotron 3.5 Super VL pour vos propres agents. Pour discuter des agents de programmation spécialisés en sécurité et de l’évaluation, contactez HCLTech.

Détails du banc d’essai et de l’évaluation

• Benchmark : évaluation interne HCLTech BLA-Bench ; 391 cas et 782 tâches par modèle.
• Notation des tâches : récompense binaire, 1 uniquement lorsque toutes les vérifications d’un vérificateur de tâches réussissent, sinon 0.
• Chaque tâche avait une limite de mémoire Docker de 4 Gio.
• Couverture du benchmark : les 10 catégories du Top 10 OWASP 2025 pour la taxonomie Business Logic Abuse incubator-project et 17 langages de programmation.
• Conception de l’évaluation : chaque tâche avait une tentative notée. La comparaison globale est appariée sur les mêmes 782 identités de tâches.
• Agent : LangChain Deep Agents Code et profil d’exécution correspondant.
• Modèles : NVIDIA Nemotron-3.5-Super-VL-120B-A12B et OpenAI o4-mini-2025-04-16.
• Configurations de modèle : Les deux configurations établissent un délai d’expiration de 600 secondes par appel pour les requêtes modèle/API et max_completion_tokens à 16 384.
• Configurations de modèle : chaque modèle utilisait la configuration de raisonnement recommandée par le fournisseur. Nemotron : raisonnement activé, reasoning_budget 8 192 jetons, température 1,0, top_p 0,95. o4-mini : reasoning_effort moyen, température 1,0.
• Interprétation des sous-groupes : Les répartitions par catégorie et langue sont descriptives et doivent être lues avec la taille du groupe concerné.
• Diagnostics des résultats d’outils : Un indicateur d’erreur explicite est un résultat d’outil sérialisé avec une ligne débutant par error, exception, traceback ou failed ; il s’agit d’un diagnostic textuel, non d’une mesure de correction sémantique ni de fiabilité en production.
• Preuve : fichiers de configuration Harbor, fichiers result.json par essai, résultats d’agent sérialisés et trajectoires, et identités exactes des tâches reliées aux métadonnées de la tâche BLA-Bench pour les segments catégorie et langue.