nealbridges/vulnhunterScanner de sécurité pour l'IA agentique qui raisonne comme un attaquant sur le code source, confirme les failles exploitables avec des PoC exécutables et pilote des correctifs test-first via les compétences hunt, fix et verify.
[!NOTE] Un fork maintenu de VulnHunter de Capital One (Apache-2.0) — conçu pour fonctionner sur n'importe quel harnais d'agent, pas seulement Claude Code. Ce fork se concentre sur : la portabilité du harnais, la validation d'exploit en bac à sable (conteneurisée) et les PoC à impact mesuré. Voir Pourquoi ces changements · Ce que ce fork change · Les chiffres.
Du pattern-matching à la prouvabilité.
VulnHunter est un outil de sécurité IA agentique open-source qui applique une analyse proactive, orientée attaquant, directement au code source.
Contrairement aux scanners SAST traditionnels et passifs qui signalent des motifs suspects et causent souvent des faux positifs, VulnHunter raisonne comme un adversaire. Il identifie quels défauts sont réellement exploitables, cartographie les chemins d'attaque potentiels et propose des correctifs ciblés et étayés par des preuves.
Les chaînes d'approvisionnement logicielles modernes sont profondément interconnectées. Une seule vulnérabilité dans un composant open-source largement utilisé peut se propager simultanément à des milliers d'entreprises.
VulnHunter a été développé en interne chez Capital One et open-sourcé pour la communauté. Ce fork poursuit ce travail — même méthodologie, retravaillée pour fonctionner sur n'importe quel harnais d'agent, avec la validation d'exploit en bac à sable (conteneurisée) et les PoC à impact mesuré comme feuille de route. Voir Ce que ce fork change.
Mise en garde sur le double usage VulnHunter effectue un travail de cybersécurité à double usage (découverte et exploitation de vulnérabilités). Attendez-vous à des garde-fous : la plupart des modèles disponibles commercialement appliquent des protections cyber à double usage, et un comportement d'exploitation agressif peut déclencher des limites de débit ou des signalements d'usage. Le développement et les tests de VulnHunter ont été menés sur des modèles à poids ouverts, fournis par la communauté — dé-risqués, abliterated et non censurés — qui sont les modèles susceptibles de compter pour un usage organisationnel à l'avenir. N'auditez que le code que vous possédez ou que vous êtes autrement autorisé à auditer.
[!IMPORTANT] Prérequis et exigences relatives aux modèles La méthodologie de VulnHunter est conçue pour fonctionner sur des modèles à poids ouverts, fournis par la communauté — les modèles dé-risqués, abliterated et non censurés que les organisations peuvent réellement déployer. Un modèle de raisonnement performant est requis ; le modèle le plus puissant proposé par votre harnais donne les meilleurs résultats, mais la méthodologie ne dépend pas du modèle de pointe d'un fournisseur spécifique. Vous fournissez votre propre accès au modèle.
| Capacité | Amont (Capital One) | Ce fork | Statut |
|---|---|---|---|
| Portabilité du harnais | Les skills invoquent spécifiquement Claude Code ; l'installateur cible ~/.claude/skills ; les garde-fous de modèle codent en dur Opus ; le harnais épingle claude-opus-4-8 | Les skills sont des fichiers de prompt portables pour harnais (tout harnais disposant d'un répertoire de skills + subagents) ; contrat d'environnement VULNHUNT_SKILLS_DIR / VULNHUNT_AGENTS_DIR / VULNHUNT_BIN_DIR / VULNHUNT_HOST_CMD / VULNHUNT_MODEL ; les garde-fous de modèle reformulés en « le modèle de raisonnement le plus performant de votre harnais » | Livré |
| Installateur sans supposition | install.sh suppose ~/.claude/skills | Répertoires explicites, respecte la sémantique de GROK_HOME, écrit le lanceur vh dans VULNHUNT_BIN_DIR/~/.local/bin, installe le skill vulnhunter-run + la définition d'agent ; équivalents Windows .cmd mis à jour | Livré |
Skill opérateur vulnhunter-run | — (absent) | Opérateur non surveillé : clone → hunt → find-results → écrit/valide le manifeste de scan, avec des règles d'arrêt explicites et sans improvisation | Livré |
| Durcissement du benchmark/juge | Modèle fixe + retry basique | Modèle via l'environnement, configuration retry/backoff, traçage des points de perte du pipeline analyze_misses, suivi de l'historique par finding | Livré |
| Langage de rapport neutre vis-à-vis du harnais | Prose spécifique à Claude dans tous les skills | Langage d'outil neutre vis-à-vis du harnais (Agent → subagent, Claude CLI → session de harnais) | Livré |
| Validation d'exploit en bac à sable d'abord | Les tests d'exploit peuvent être des traces statiques ; choix du runtime ad hoc | Provisionnement du runtime Docker-first ; le runtime enregistré par finding ; sévérité Medium+ doit s'exécuter | En cours |
| PoC à impact mesuré | Les PoC sont des documents ; l'impact est affirmé | PoC exécutable + chiffre d'impact dans le finding (lignes exposées, requêtes amplifiées, heures-clés bloquées) | En cours |
La méthodologie de VulnHunter est par nature agnostique vis-à-vis de l'hôte : c'est une procédure de prompt, pas une liaison à un outil. Le projet amont a grandi au sein de Claude Code — un choix cohérent, et le bon premier foyer. Mais le paysage des harnais d'agents s'est élargi, et une méthodologie de sécurité qui ne s'installe que dans l'un d'eux cesse d'être une capacité d'audit pour devenir une fonctionnalité de fournisseur. Ce fork apporte quatre changements, chacun avec une raison.
Chaque skill ici est un fichier de prompt portable avec un contrat d'environnement explicite (VULNHUNT_SKILLS_DIR, VULNHUNT_AGENTS_DIR, VULNHUNT_MODEL, VULNHUNT_HOST_CMD), et les garde-fous de modèle demandent désormais le modèle de raisonnement le plus performant de votre harnais au lieu d'un produit spécifique. Mieux signifie : la même méthodologie s'installe dans le harnais que votre équipe utilise déjà — et devient comparable entre harnais lors des exécutions de benchmark, ce qui est la façon dont ce fork est développé.
L'installateur amont copiait les skills dans ~/.claude/skills sans condition. Sur une machine exécutant deux harnais — ou un harnais avec un home relocalisé — cette supposition installe au mauvais endroit, silencieusement. L'installateur du fork demande, ou prend des variables d'environnement, et échoue bruyamment avec l'instruction exacte lorsque la réponse est manquante. Mieux signifie : sûr sur les machines multi-harnais, correct sous des homes relocalisés, bruyant plutôt que silencieux en cas de mauvaise configuration.
La conception originale exige déjà la falsification et les tests d'exploit. Ce qu'elle laissait ouvert, c'était à quel point travailler pour réellement les exécuter : trace statique, test mocké, ou un vrai serveur conteneurisé. Dans un benchmark de six exécutions contre un seul commit, cette discrétion a produit entre 3 et 42 findings — et des verdicts opposés sur le même sink, l'un prouvé contre un mock, l'autre clos par un test contre un vrai serveur. Ce fork ajoute une procédure de provisionnement du runtime (Docker-first, enregistrée par finding) et une discipline de PoC où l'impact est mesuré — lignes divulguées, amplification ×, heures-clés bloquées — et non narré. Mieux signifie : la validité d'un finding ne dépend plus du modèle qui a eu l'instinct de monter un conteneur. (En cours — le plan de construction est sur la feuille de route publique ; demandez dans les issues ou surveillez les Discussions du dépôt.)
