KaliBench : un benchmark fin pour l'usage d'outils de cybersécurité sous Kali Linux

Contexte et définition du problème

Les grands modèles de langage s'intègrent de plus en plus dans les flux de travail des analystes en cybersécurité, où ils servent de couche de traduction entre l'intention exprimée en langage naturel et l'invocation d'outil correspondante. Pourtant, les évaluations existantes restent coincées entre deux extrêmes. D'un côté, des tests fondés sur la connaissance qui se contentent de vérifier si un modèle reconnaît un outil ou un concept, sans rapport direct avec la compétence opérationnelle réelle. De l'autre, des évaluations agentiques de bout en bout qui jugent uniquement le résultat final, qu'il s'agisse de capturer un flag ou d'atteindre un objectif, en laissant chaque commande intermédiaire dans une boîte noire totalement opaque. Aucun des deux extrêmes ne mesure la capacité qui déterminerait réellement l'utilité d'un LLM dans un centre d'opérations de sécurité : sa capacité à transformer de façon fiable une requête en langage naturel en une ligne de commande exécutable.

Cette capacité est plus difficile qu'il n'y paraît, précisément parce que les outils de cybersécurité dépendent d'une syntaxe CLI extrêmement stricte. Un argument mal ordonné, un indicateur lié à la mauvaise valeur, ou une sous-commande mal orthographiée ne produit pas simplement un avertissement : la commande peut silencieusement exécuter une opération totalement différente, ce qui, lors d'un test d'intrusion réel ou d'un exercice d'équipe rouge, fait toute la différence entre un résultat propre et une action dommageable. KaliBench cible précisément cette couche intermédiaire négligée : il ne demande pas si un modèle a mémorisé le manuel d'un outil, ni si une chaîne d'attaque entière aboutit finalement. Il isole et mesure la traduction langage naturel vers CLI elle-même, à l'échelle de chaque commande individuelle.

Architecture centrale et principes techniques

Le jeu de données comprend 8 504 paires requête-commande couvrant 1 642 outils réels de Kali Linux, organisées selon 23 dimensions de capacité et les 5 phases de sécurité canoniques, de la reconnaissance à la post-exploitation. La construction suit un pipeline fondé sur la documentation officielle : plutôt que de rédiger manuellement des invites, le jeu de données s'ancre dans la documentation de chaque outil, puis subit une canonicalisation déterministe qui fait correspondre toute variante syntaxiquement valide d'une commande à une forme normalisée unique. Cela s'accompagne d'une évaluation sensible aux alias, si bien qu'un modèle utilisant un indicateur abrégé équivalent ou un argument alternatif mais sémantiquement identique est noté correctement plutôt que pénalisé pour une simple divergence de chaîne de caractères en surface.

Le choix de conception le plus déterminant reste le pipeline de vérification en trois étapes. La première étape applique une validation fondée sur un LLM pour filtrer la plausibilité sémantique. La deuxième exécute réellement les commandes candidates dans un terminal en bac à sable, capturant un retour d'exécution réel pour confirmer que la commande est non seulement plausible mais véritablement exécutable. La troisième introduit une relecture humaine pour corriger les cas limites que les étapes automatisées manquent. Ensemble, cela confère à KaliBench une double garantie, correction sémantique et exécutabilité pratique, que les benchmarks jugés uniquement par un LLM en une seule étape ne peuvent généralement pas revendiquer.

Évaluation pratique et applications

Les auteurs ont testé 24 configurations de modèles selon trois modes d'évaluation, couvrant des modèles généralistes et des modèles open-weight spécialisés en sécurité. Le résultat principal est préoccupant : dans le réglage sans restriction, sans indice d'outil explicite fourni, aucun modèle open-weight n'a dépassé 42% de précision exacte de commande. Même les modèles ouverts les plus performants actuellement disponibles restent loin de la fiabilité qu'exigerait une opération de sécurité en production si le LLM agissait de façon autonome.

La seconde contribution de KaliBench consiste à transformer ce signal diagnostique en un atout d'entraînement. Parce que le pipeline de vérification produit des récompenses déterministes et indépendantes de l'exécution, elles peuvent être réutilisées directement pour l'apprentissage par renforcement sans réexécuter un bac à sable réel à chaque étape d'entraînement, ce qui rendrait sinon le RL prohibitivement coûteux à grande échelle. L'article démontre qu'un réglage fin supervisé suivi d'un apprentissage par renforcement avec ces récompenses vérifiables issues de KaliBench porte un modèle de 8 milliards de paramètres à un niveau de performance comparable à celui d'un modèle à mélange d'experts de 685 milliards de paramètres.

Impact sur l'industrie et perspectives

Pour les équipes de sécurité qui envisagent de laisser un LLM piloter directement l'invocation d'outils, le plafond de 42% constitue un avertissement clair : la génération autonome de commandes pour des outils de test d'intrusion n'est pas encore suffisamment fiable pour fonctionner sans supervision, et tout pipeline de production construit aujourd'hui nécessite une couche de vérification humaine ou déterministe dans la boucle. La conception de récompenses vérifiables sans exécution en temps réel constitue elle-même un schéma réutilisable au-delà de ce benchmark particulier.

À l'avenir, des benchmarks fins, indexés par dimension de capacité, comme KaliBench, sont susceptibles de devenir la norme pour l'évaluation des agents de sécurité, déplaçant le débat des récits vagues du type « a-t-il percé la cible » vers un diagnostic précis de la dimension de capacité et de la phase de sécurité où des lacunes subsistent encore, offrant à l'industrie un véritable indicateur de progrès mesurable pour le déploiement des LLM dans des opérations de sécurité réelles.