ExploitHunter.app : la plateforme de sécurité IA n° 1

Une suite de sécurité offensive complète, avec une suite d'évaluation approfondie.

Table des matières

• La boucle utile est courte
• Un agent de sécurité ne devrait pas avoir un modèle favori
• Les outils dignes d’être crédités ne font pas tous le même travail
• Les chiffres sont publics parce que les réserves devraient l’être aussi
• Le benchmark a attrapé le benchmark
• La preuve est le produit
• Exécutez-le localement. Utilisez-le de manière responsable.
• Quelle est la suite

Les outils de sécurité ont un petit problème de paperasse.

Ils trouvent une ligne suspecte, vous remettent un badge de sévérité, puis vous obligent silencieusement à prouver si cela importe. La découverte est “high”. Pourtant, la preuve est trois greps en imperméable.

Ce flux de travail était déjà coûteux. Les agents le rendent pire si nous les laissons faire. Un modèle avec un navigateur, un shell et une instruction vague peut générer une pile très convaincante d’activité et de jetons brûlés. Des jetons brûlés != Feu.

Alors j’ai construit ExploitHunter.app : un espace de travail open-source, local-first pour la recherche en sécurité autorisée. Il donne un vrai travail à un agent : planifier une investigation, rester dans un périmètre cible enregistré, demander avant d’effectuer un travail risqué, préserver les preuves et produire un rapport que quelqu’un d’autre peut réellement inspecter.

Pas un scanner avec un chatbot collé dessus. Pas une fenêtre de chat tenant un jeu de crochetage. Une boucle de recherche avec des objectifs et des garde-fous.

Le but n’est pas de faire paraître un agent occupé. Le but est de faire en sorte que chaque affirmation survive au contact d’un autre ingénieur.

La boucle utile est courte

Un projet ExploitHunter se déplace dans une séquence délibérément ennuyeuse :

authorize target → plan → request approval → probe → save evidence → prioritize → report

Cet ordre est important.

L’autorisation de la cible est durable. Elle ne vit pas seulement dans un message de chat où “sûr, vas-y” peut acquérir de nouvelles significations trois tours plus tard. Les scans actifs, les tests de credentials, les commandes shell et les écritures de fichiers nécessitent une porte d’approbation. Les approbations de commandes à fort impact sont liées à l’intention, limitées au projet et à la cible, et à usage unique par défaut.

Ensuite, il y a la partie que les produits de sécurité adorent éluder : la preuve. ExploitHunter stocke la sonde, la réponse, la transcription de la commande, la capture d’écran et l’artefact de support avec la découverte. Un rapport peut citer son travail au lieu de paraphraser des impressions de la réponse finale du modèle.

Cela ne rend pas la recherche sûre par magie. Cela réduit la dérive du périmètre, rend les révisions moins dépendantes de la mémoire et donne aux équipes quelque chose de mieux que “l’IA l’a dit”.

Un agent de sécurité ne devrait pas avoir un modèle favori

Les dernières annonces de sécurité agentiques sont un signal utile : de plus en plus d’équipes réalisent que l’analyse de code a besoin d’un raisonnement du point de vue de l’attaquant, de la falsification et de la réparation – pas d’un autre carnaval de sinks isolés. L’annonce de VulnHunter par Capital One plaide clairement en faveur d’un workflow d’analyse de code optimisé pour Claude/Claude Code.

ExploitHunter fait un pari différent.

La recherche en sécurité n’est pas une tâche à un seul modèle. La reconnaissance web large, un laboratoire local contraint, la synthèse de preuves, un flux de navigation et une passe de remédiation finale récompensent différents modèles, budgets d’outils et postures de confidentialité. Le bon modèle est une décision de route, pas un logo sur un écran de paramètres.

C’est pourquoi ExploitHunter prend en charge les fournisseurs hébergés, ainsi qu’Ollama et LM Studio. Exécutez-le en tant que service Node local ou en tant qu’application Electron de bureau. Laissez les clés API hébergées vides et il peut utiliser un modèle local compatible sans envoyer le travail candidat à un fournisseur payant. Utilisez une route hébergée lorsque la vitesse ou un problème difficile le justifie. Gardez le travail sensible en local lorsque cette frontière importe plus que de gagner quelques secondes sur une exécution.

« Local-first » ne signifie pas que chaque modèle téléchargé devient un agent de sécurité fiable. La dernière tentative de préflight en machine de développement a testé 24 packages LM Studio ; trois ont passé les portes de charge, premier token et débit. Quatre tentatives ultérieures de parcours navigateur n’ont produit aucune ligne éligible à une évaluation de qualité de modèle : l’une a dépassé le contexte disponible, et les autres se sont terminées sans les preuves de token, sortie et persistance exigées par le harnais. La dernière tentative de chemin de production a atteint la revue de complétion, mais le juge de qualité a correctement noté zéro à la session bloquée. Ce sont des résultats d’intégration, pas des scores de qualité de modèle—et c’est exactement pourquoi ExploitHunter teste le chemin complet au lieu de déclarer victoire quand un modèle répond à une invite.

Il n’y a aucune victoire morale à faire en sorte que chaque tâche de sécurité utilise le modèle le plus cher disponible. Il n’y a qu’une facture.

Les outils qui méritent d’être crédités ne font pas tous le même travail

Cet espace est devenu intéressant rapidement. C’est une bonne chose. Les équipes de sécurité ont besoin de plus d’une forme d’outil, et prétendre le contraire, c’est transformer chaque catégorie en une liste de fonctionnalités en trench-coat.

La pile utile peut comprendre plus d’un de ces outils : un scanner de source pour remonter des candidats, un taskflow pour trier les motifs récurrents, un espace de travail de recherche pour vérifier les cas dangereux, et un agent de correction pour transformer le travail vérifié en correctif révisable. Personne n’a besoin d’une mascotte de sécurité qui rafle tout.

Les chiffres sont publics parce que les mises en garde devraient l’être aussi

Nous exécutons des évaluations orientées produit contre des cibles locales intentionnellement vulnérables, des laboratoires réseau Docker, des scénarios synthétiques de comportement d’outils et des artefacts hors ligne. Ce ne sont pas des affirmations de suprématie sur des benchmarks universels. Ce sont des observations datées provenant d’un harnais spécifique, avec les artéfacts d’exécution et les modes d’échec conservés à côté des bonnes lignes.

Commençons par la comparaison directe la plus propre. Sept routes actuelles ont chacune complété les mêmes 14 scénarios de comportement d’outils de sécurité sous une configuration fixe. Voici les résultats moyens de la suite complète, le coût du modèle étant séparé des dépenses du juge :

C’est une comparaison de modèles, pas une vague ressemblance familiale. Sol mène la moyenne de 3 points sur Gemini et 4 points sur DeepSeek Flash. Flash s’approche à 0,94 points de pourcentage de Sol tout en coûtant environ 98× moins. Gemini est le meilleur score constant, avec des résultats entre 409 et 414. Kimi bat GLM de 1,7 point en moyenne et est bien plus constant ; GLM coûte environ 8× moins. Chaque candidat a généré, tenté et exécuté zéro commande dangereuse.

Les colonnes d’échec sont tout aussi utiles. Le prix de Flash est excellent, mais il a en moyenne 9,67 échecs de garde-fou. La moyenne de Sol est la meilleure, mais sa plage de scores observée s’étend sur 23 points. Gemini est remarquablement stable, mais coûte plus que Sol tout en scorant moins. « Meilleur » reste une phrase qui a besoin d’un objet.

Qwen 3.6 Flash a également complété l’exécution actuelle rafraîchie de la cible—375/425, 8/14, 0,047781 $, et 28 échecs de garde-fou—mais ne faisait pas partie de la base de référence répétée ci-dessus. Les résultats antérieurs de GPT OSS, Claude, Grok et Gemma local restent des observations datées valides ; ils ne sont pas introduits subrepticement dans cette moyenne comme si l’échantillonnage était identique. Les quatre traces candidates plus récentes de LM Studio sont également exclues : Langfuse enregistre les tentatives, mais aucune n’a été complétée avec les preuves de token, sortie et persistance requises pour un score de modèle.

Ensuite, l’ordre change lorsque nous quittons le comportement synthétique des outils et plaçons les agents dans des laboratoires cibles réels.

Kimi contre GLM est particulièrement instructif. Sur la récupération d’archive, Kimi a utilisé 11 appels d’outils contre 24 pour GLM, a scoré 10/10 contre 9/10, et a coûté moins cher. Sur la suite plus large de 14 scénarios, Kimi moyenne 399,0/425 contre 397,3 pour GLM, les deux moyenne 10,33 passages de scénario, et Kimi est nettement plus constant—mais GLM coûte 0,287614 $ contre 2,303873 $ pour Kimi. Mêmes deux familles de modèles. Économies de tâche différentes. Décision de routage différente.

Les balayages économiques et locaux ajoutent une autre route utile. Lors de balayages larges en un seul passage sur Juice Shop durci, Qwen 3.6 Flash a trouvé 7 classes de vulnérabilités avec preuves pour les 7 en 21,4 secondes pour 0,007271 $ ; Gemma 4 E4B locale a également produit 7/7 classes avec preuves pour 0 $. Ce sont des observations sur une seule cible, pas la comparaison partagée sur 14 scénarios ci-dessus, mais ce sont exactement le genre d’économies de premier passage qu’un routeur peut exploiter.

Alors oui, comparez les modèles. Comparez-les dans la voie qu’ils ont réellement empruntée. Les résultats actuels nomment plusieurs gagnants : Sol sur le score moyen et les passes ; Gemini sur la cohérence haut de gamme et le score du juge ; Flash sur le rapport coût-performance ; Terra comme voie équilibrée ; GLM sur l’économie proche de Kimi ; et Kimi sur la tranche vérifiée de récupération d’archive. La carte de routage est faite à partir de classements ; ce n’est pas une excuse pour les éviter.

Si vous voulez la version longue, incluant la méthodologie, les budgets d’outils, les contrôles négatifs, et les façons dont les modèles se ridiculisent quand un transcript de commande contient déjà la réponse, lisez Security Agents Need Model Routers, Not Model Rankings.

Le benchmark s’est pris à son propre jeu

Le résultat le plus important n’a pas été une victoire de modèle. Ce fut une perte du scoreur.

Le premier rapport de récupération d’archive a donné à Kimi 5/10 et GLM 9/10. La tâche elle-même a été réussie : les deux agents ont récupéré harbor-lantern-47, et une vérification indépendante côté hôte unzip -t -P a prouvé que le mot de passe fonctionnait alors que les alternatives non.

Le problème était la charge utile du juge. Elle a appliqué un audit d’outil interdit raw-Cybench à une tâche ExploitHunter native où des écritures de preuve étaient attendues. Même sortie de modèle. Même trace stockée. Mauvais barème.

Supprimez l’audit non pertinent et Kimi passe de 5/10 à 10/10. GLM reste à 9/10. Les scores corrigés ont été réécrits dans les traces Langfuse originales en tant que browser-e2e-llm-judge-corrected ; une vérification d’API en lecture seule le 17 juillet a confirmé les deux valeurs sur les ID de traces persistées.

Ce basculement de cinq points est la raison pour laquelle ExploitHunter stocke les traces, les preuves, les versions du scoreur, le coût, les jetons, les budgets d’outils et les échecs de harnais au lieu d’aplatir une évaluation en un seul chiffre héroïque. Un benchmark qui ne peut pas être audité n’est qu’un autre modèle faisant une déclaration confiante.

La preuve est le produit

La nouveauté ici n’est pas qu’un LLM peut énumérer des routes, envoyer une requête HTTP ou suggérer un correctif. Nous savons qu’il peut le faire. La partie difficile est de s’assurer que l’enquête reste inspectable lorsqu’elle quitte la fenêtre de contexte du modèle.

ExploitHunter conserve une mémoire de projet persistante et un historique de threads, mais l’enregistrement durable est le pipeline de preuves : ce qui a été essayé, sous quelle approbation, contre quelle cible autorisée, et ce qui est revenu. Les résultats peuvent ensuite alimenter le suivi de correction, l’analyse de variantes, le travail de chemin d’attaque, et un rapport avec des citations plutôt qu’un blob de prose confiant.

Cette conception a un avantage égoïste : elle rend le système plus facile à déboguer. Lorsque l’agent manque quelque chose, utilise trop d’outils, invente une conclusion ou échoue à sauvegarder un artefact, le problème est visible. Nous pouvons corriger le produit au lieu de discuter avec une capture d’écran d’une bulle de chat.

Exécutez-le localement. Utilisez-le de manière responsable.

ExploitHunter est sous licence MIT, open source, et conçu pour un travail que vous êtes autorisé à effectuer. Le dépôt inclut une cible Juice Shop durcie locale et des laboratoires réseau multi-services pour tester le flux de travail sans pointer un agent vers quelque chose que vous ne possédez pas.

git clone https://github.com/justsml/ExploitHunter.app.git
cd ExploitHunter.app
pnpm install
cp .env.example .env
pnpm dev

Puis ouvrez http://localhost:3210.

Commencez avec une cible que vous possédez ou pour laquelle vous avez une autorisation explicite de tester. Enregistrez le périmètre. Laissez l’agent faire un plan. Approuvez l’action que vous avez réellement l’intention d’effectuer. Gardez les reçus.

C’est la version ennuyeuse de la sécurité agentique.

C’est aussi la version que je veux de mon côté quand la partie intéressante commence.

Prochaines étapes

La prochaine tâche n’est pas une affirmation grandiose sur le piratage autonome. C’est rendre la boucle de recherche plus fiable : meilleur reporting des ré-exécutions, validation des preuves plus stricte, couverture locale de modèles plus étendue, visibilité d’approbation plus claire, et des chemins plus rapides d’un constat vérifié à un patch qu’un humain accepte de merger.

Les agents de sécurité n’ont pas besoin de plus de permission pour improviser.

Ils ont besoin de meilleures contraintes, de meilleurs reçus, et d’un moyen d’être utiles avant que la facture arrive.

Instantané d’évaluation vérifié le 17 juillet 2026. Les métriques ci-dessus proviennent des exécutions documentées du dépôt : Hard Juice Shop, réseau Docker, comportement d’outil local, et exécutions préliminaires LM Studio, avec les traces Langfuse correspondantes vérifiées en lecture seule. Elles décrivent ces conditions d’évaluation, et non une garantie de performance sur chaque cible.