Annonce d’ExploitHunter.app

Un atelier de sécurité open source qui centralise le périmètre, les validations, les outils et les preuves dans un même projet.

Table des matières

• La boucle est volontairement ennuyeuse
• Les preuves sont le produit
• Huit modèles, une cible
• Le benchmark a pris le benchmark sur le fait
• Router les modèles selon la tâche
• Où il se situe face à deepsec, VulnHunter et leurs homologues
• Exécutez-le en local. Utilisez-le de manière responsable.
• Et maintenant ?

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

Ils repèrent une ligne suspecte, vous collent un badge de gravité, puis vous laissent discrètement démontrer que le problème est réel. La vulnérabilité est « élevée ». Les preuves sont trois grep en imperméable.

Les agents IA peuvent raccourcir ce workflow. Ils peuvent aussi transformer une instruction vague, un navigateur et un shell en un tas d’actions beaucoup plus rapide, mais invérifié.

ExploitHunter.app commence là où le scanner s’arrête. Donnez-lui une cible autorisée et un objectif. L’agent cartographie les routes accessibles, pilote un navigateur, exécute des outils de terminal et de sécurité, teste une hypothèse, puis enregistre les réponses, les captures d’écran et les transcriptions qui étayent la constatation. Il transforme ensuite ces preuves en rapport, avec des citations.

Le projet est open source et conçu d’abord pour le local. Vous pouvez passer de modèles hébergés à des modèles locaux sans répartir la cible, les approbations, l’historique et les preuves entre plusieurs projets distincts.

Ce n’est pas un scanner auquel on aurait greffé un chatbot. C’est un atelier qui se souvient de ce que l’agent a essayé et de ce qui lui est revenu.

Parler de sécurité ne coûte pas cher. La partie utile consiste à exécuter le contrôle autorisé, à conserver les preuves et à vous donner la prochaine étape.

La boucle est volontairement ennuyeuse

Un projet ExploitHunter suit toujours la même séquence :

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

L’ordre compte, parce que l’agent dispose d’un accès réel.

L’autorisation de la cible relève de l’état du projet, pas du contexte conversationnel. Elle ne vit pas dans un message où « oui, vas-y » pourrait prendre un nouveau sens trois tours plus tard. Les scans actifs, les tests d’identifiants, les commandes shell et les écritures de fichiers sont tous soumis à une étape d’approbation. Les approbations de commandes à fort impact sont liées à une intention, un projet et une cible. Par défaut, elles ne sont valables qu’une seule fois.

Les étapes d’approbation ne sont pas une clause en petits caractères sous le discours produit. C’est ce qui rend raisonnable la connexion d’un agent à de vrais outils. Elles limitent les dérives de périmètre, rendent les revues moins dépendantes de la mémoire et donnent à l’équipe quelque chose de plus solide que « l’IA l’a dit ».

Les preuves sont le produit

La réponse finale du modèle n’est pas l’unité durable du travail de sécurité. Les preuves le sont.

Fermez l’application. Changez de modèle. Revenez demain. L’enquête a toujours une mémoire.

ExploitHunter conserve l’historique des projets et des fils de discussion, mais le registre durable est le pipeline de preuves : ce qui a été tenté, avec quelle approbation, contre quelle cible autorisée et ce qui en est ressorti. La sonde, la réponse, la transcription des commandes, la capture d’écran et l’artefact associé sont stockés avec la constatation. Le rapport cite le travail effectué au lieu de paraphraser le paragraphe de conclusion du modèle.

Les constatations peuvent ensuite alimenter le suivi des corrections, l’analyse des variantes, l’étude des chemins d’attaque et un rapport qu’un réviseur peut vérifier ligne par ligne.

Il y a aussi un avantage égoïste : le débogage cesse d’être mystique. Quand l’agent rate quelque chose, utilise trop d’outils, invente une conclusion ou ne sauvegarde pas un artefact, l’échec est visible dans le registre. Nous corrigeons le produit au lieu de discuter devant la capture d’écran d’une bulle de chat.

Huit modèles, une cible

Puisque chaque exécution laisse une trace, comparer les modèles ne relève plus du simple ressenti.

J’ai soumis la même tâche difficile de Juice Shop à huit routes de modèles et je les ai fait passer par le véritable parcours applicatif d’ExploitHunter. Même cible. Mêmes outils. Même contrat de preuve. Si une exécution ne permettait pas de prouver quel modèle avait été utilisé ou ne préservait pas sa sortie, elle n’apparaissait pas dans le tableau. Les benchmarks apprécient peut-être l’ambiguïté. Les factures, rarement.

| Route du modèle | Juge | Coût | Durée | Appels d’outils | Lecture | |---|---:|---:|---:|---:|---| | Kimi K3 | 10.0/10 | $0.220184 | 223.4s | 8.0 | Meilleure qualité au prix le plus bas des deux modèles ayant obtenu la note parfaite | | Claude Opus 4.8 | 10.0/10 | $1.633301 | 115.9s | 8.0 | Même qualité que Kimi, presque deux fois plus rapide, pour un coût multiplié par 7,4 | | DeepSeek V4 Flash | 9.33/10 | $0.058695 | 395.5s | 32.0 | Meilleur score parmi les deux routes qui n’atteignent pas la perfection | | GPT-5.6 Luna | 8.67/10 | $0.016304 | 52.2s | 3.3 | Meilleur résultat en coût et en vitesse | | GPT-5.6 Terra | 8.0/10 | $0.124046 | 107.5s | 6.0 | Devance Sol en prix et en vitesse à score égal | | GPT-5.6 Sol | 8.0/10 | $0.368514 | 229.6s | 10.0 | Capable, mais dominé par Terra sur cet échantillon | | Qwen 3.6 Flash | 5.5/10 | $0.085678 | 96.9s | 16.5 | Le réglage le moins cher améliore l’efficacité, mais la qualité reste en retrait | | GPT OSS 120B | 5.0/10 | $0.062529 | 36.6s | 4.3 | Rapide et peu coûteux, mais trop instable pour être la route par défaut |

Lisez ceci comme une politique de routage, pas comme un podium.

Luna est le point de départ efficace. DeepSeek achète deux tiers de point supplémentaire auprès du juge pour environ 3,6 fois le coût, 7,6 fois la durée et 9,6 fois le nombre d’appels d’outils. Kimi atteint 10/10 sans la facture d’Opus. Opus obtient le même score environ 108 secondes plus tôt, pour 1,41 $ de plus. GPT OSS reste une expérience à superviser, et Terra défend mieux son dossier que Sol sur cette tâche.

Seuls Luna, DeepSeek et Kimi se trouvent sur cette frontière. Les autres routes ne sont pas inutiles. Elles ont besoin d’une justification qui dépasse le score brut et le coût : Opus achète de la vitesse, Terra respecte une contrainte de famille de modèles sans la facture de Sol, et GPT OSS est suffisamment bon marché pour être exploré sous supervision.

La version longue, avec la méthodologie, les budgets d’outils, les contrôles négatifs et les façons dont les modèles se ridiculisent lorsqu’une transcription de commande contient déjà la réponse, se trouve dans Les agents de sécurité ont besoin de routeurs de modèles, pas de classements de modèles.

Le benchmark a pris le benchmark sur le fait

Le résultat le plus important n’était pas la victoire d’un modèle. C’était l’échec du système de notation.

Le premier rapport de récupération de l’archive a donné 5/10 à Kimi et 9/10 à GLM. La tâche elle-même a réussi. Les deux agents ont récupéré harbor-lantern-47, et une vérification indépendante côté hôte avec unzip -t -P a prouvé que ce mot de passe fonctionnait, contrairement aux autres.

Le juge avait appliqué un audit brut des outils interdits de Cybench à une tâche ExploitHunter native dans laquelle l’écriture des preuves était requise. Il a pénalisé exactement le comportement demandé par le harness. Même sortie du modèle. Même trace enregistrée. Mauvais barème.

Une fois l’audit hors sujet supprimé, Kimi passe de 5/10 à 10/10. GLM reste à 9/10. Les scores corrigés ont été réécrits dans les traces Langfuse d’origine sous le nom browser-e2e-llm-judge-corrected, et une vérification en lecture seule de l’API, effectuée le 17 juillet, a confirmé les deux valeurs sur les identifiants de traces persistés.

Cette variation de cinq points explique pourquoi ExploitHunter enregistre les traces, les preuves, les versions des scoreurs, le coût, les tokens, les budgets d’outils et les échecs du harness, au lieu d’aplatir une évaluation en un seul chiffre héroïque. Si le benchmark ne peut pas montrer son travail, ce n’est qu’un modèle de plus qui avance une affirmation avec aplomb.

Router les modèles selon la tâche

ExploitHunter ne se contente pas de prendre en charge une longue liste de fournisseurs de modèles. Il les traite comme un banc de touche.

Une phase de reconnaissance, une vérification d’exploit, un parcours navigateur, une synthèse des preuves et une proposition de remédiation relèvent toutes de la sécurité. Ce ne sont pas les mêmes tâches pour un modèle.

Capital One’s VulnHunter fait un pari cohérent sur un workflow d’analyse du code optimisé pour Claude/Claude Code. ExploitHunter fait un pari différent : conserver le périmètre du projet, les approbations, les outils et les preuves, tout en faisant varier la route du modèle selon le travail à effectuer.

Une reconnaissance web large peut tirer parti d’un modèle peu coûteux et rapide, avec un budget d’outils strict. Un laboratoire local contraint peut privilégier la confidentialité et l’inférence hors ligne. Une validation difficile ou un rapport final peuvent justifier une route frontier plus lente. ExploitHunter déplace le travail entre ces voies, tandis que la cible, l’historique, les approbations, les outils et les artefacts restent en place.

Le bon modèle est une décision de routage, pas un logo sur un écran de configuration.

ExploitHunter prend en charge les fournisseurs hébergés, ainsi qu’Ollama et LM Studio. Exécutez-le comme service Node local ou comme application de bureau Electron. Laissez vides les clés d’API hébergées : un modèle local compatible conservera alors le travail candidat à l’écart des fournisseurs payants. Utilisez une route hébergée lorsque la vitesse ou la difficulté du problème le justifie. Gardez les travaux sensibles en local lorsque cette frontière compte davantage que le fait de gagner quelques secondes sur une exécution.

Il n’y a aucune victoire morale à envoyer chaque tâche de sécurité au modèle le plus cher disponible. Il n’y a qu’une facture.

Où il se situe face à deepsec, VulnHunter et leurs homologues

ExploitHunter est délibérément plus large qu’un harness d’analyse de code. Il prend un candidat dans une cible en fonctionnement, l’examine avec des outils de navigateur et de terminal, conserve les preuves, puis transmet une vulnérabilité vérifiée au système qui doit la corriger.

Plusieurs projets couvrent désormais différentes parties de ce workflow. Tant mieux. Les équipes de sécurité ont besoin d’outils capables de se transmettre le travail, pas d’une nouvelle catégorie où un seul vainqueur écrase tous les autres.

| Outil | Ses points forts | Ce qui différencie ExploitHunter | |---|---|---| | Vercel deepsec | Un harness centré sur le code source : découverte statique de candidats, investigation par un agent de programmation, revalidation, enrichissement et fan-out facultatif vers des sandbox à grande échelle. | Deepsec convient à l’analyse de dépôts et au suivi orienté pull request. ExploitHunter place au centre un projet de recherche autorisé pouvant inclure une application en fonctionnement, un navigateur, un laboratoire réseau, un terminal, des preuves persistantes et des approbations explicites de l’opérateur. | | Capital One VulnHunter | Une analyse du code source menée comme un attaquant, la falsification structurée des résultats et des propositions ciblées de correction du code. | Le recouvrement est réel : les preuves et la réduction des faux positifs devraient être le strict minimum. ExploitHunter est moins lié à un harness de programmation ou à une seule voie de modèle, et davantage axé sur la coordination de l’investigation avant de proposer une modification du code. | | GitHub Security Lab Taskflow Agent | Des taskflows déclaratifs compatibles MCP, notamment pour le triage des alertes CodeQL et l’analyse des variantes. GitHub indique que l’outil a contribué à trouver environ 30 vulnérabilités réelles. | La bonne base lorsque l’entrée est un workflow reproductible d’analyse du code. ExploitHunter est l’établi destiné à la recherche exploratoire utilisant des outils, lorsque le périmètre, les approbations et les preuves doivent survivre à une investigation plus longue. | | OpenHands Vulnerability Fixer | Transformer les sorties de Trivy ou d’autres outils en corrections, tests et pull requests priorisés. | Une usine à remédiations. ExploitHunter intervient plus tôt dans la boucle : établir que le résultat est réel, consigner pourquoi, puis transmettre un problème solidement étayé au système de correction. | | Assay | L’application hors ligne de politiques, la relecture déterministe et les lots de preuves cryptographiques pour les appels d’outils des agents. | Complémentaire, pas concurrent. C’est le type de contrôle d’exécution deny-by-default que les espaces de travail de recherche agentique devraient pouvoir utiliser sous leur propre couche d’approbation. |

Une pile utile comprend probablement plusieurs de ces éléments : un scanner de code source fait émerger des candidats, un taskflow trie les schémas récurrents, un espace de recherche vérifie les cas dangereux, et un agent de remédiation transforme le travail vérifié en correctif révisable. Les transmissions comptent davantage que le fait de couronner la mascotte de la sécurité.

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

ExploitHunter est sous licence MIT, open source et conçu pour les travaux que vous êtes autorisé à effectuer. Le dépôt fournit une cible Juice Shop locale durcie ainsi que des laboratoires réseau multiservices, afin que vous puissiez exercer l’ensemble du workflow sans pointer un agent vers quelque chose qui ne vous appartient pas.

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

Ouvrez ensuite http://localhost:3210.

Choisissez une route de modèle, autorisez une cible dont vous êtes propriétaire ou que vous avez explicitement l’autorisation de tester, puis donnez un objectif à l’agent. Laissez-le cartographier le travail, approuvez les actions que vous comptez réellement effectuer et regardez les éléments de preuve s’accumuler au lieu de disparaître dans l’historique du chat.

Voilà la version peu spectaculaire de la sécurité agentique.

C’est aussi celle que je veux de mon côté quand les choses deviennent intéressantes.

Et maintenant ?

La prochaine étape n’est pas de formuler une affirmation plus ambitieuse sur le piratage autonome. Il s’agit de rendre la boucle de recherche plus fiable : de meilleurs rapports sur les exécutions répétées, une validation plus stricte des éléments de preuve, une couverture accrue des modèles locaux, une visibilité plus claire sur les approbations et un chemin plus rapide entre une vulnérabilité vérifiée et un correctif qu’un humain aura envie d’intégrer.

Les agents de sécurité n’ont pas besoin d’un espace illimité pour improviser. Ils ont besoin d’une portée suffisante pour nous surprendre, de limites strictes autour de cette portée et de preuves lorsqu’ils revendiquent une réussite.

Voilà ExploitHunter : un même endroit pour appliquer les modèles, les outils, les laboratoires, les approbations, les éléments de preuve et le suivi au même problème.

À vous maintenant de le pointer vers quelque chose que vous avez le droit de casser.