swelljoe/nelsonTrouver des vulnérabilités par force brute aveugle
Inspiré par une conférence de Nicholas Carlini et par la boucle Ralph, Nelson est un outil qui parcourt chaque fichier d'un projet en demandant à un agent de chercher des vulnérabilités. Il possède un mode scan, similaire à la boucle bash de Carlini, où il demande au modèle de trouver toute vulnérabilité dans un fichier ou un répertoire de fichiers ; un mode review, où un modèle (généralement plus intelligent) réexamine chaque vulnérabilité signalée et décide si elle mérite d'être remontée à un relecteur humain ; et une étape de déduplication entre les deux, afin que le même bogue trouvé plusieurs fois ne soit jugé qu'une seule fois.
La grande leçon des nombreux benchmarks est que la répétition est ce qui fait émerger les bogues. Les versions précédentes avaient un « mode focus » qui demandait au modèle de chasser une classe CWE spécifique à la fois, et cela semblait aider — mais c'était une illusion : l'expansion par CWE faisait simplement examiner chaque fichier plusieurs fois par le modèle, et c'est la répétition, pas le ciblage des CWE, qui faisait le travail. Nommer la classe de bogues, les listes de vérification et autres mises en forme des invites n'a apporté aucune amélioration réelle dans les tests A/B contrôlés. Donc le mode focus a disparu. À la place, --repeat N exécute la matrice fichier × modèle N fois (3 par défaut), ce qui est une bien meilleure utilisation des mêmes tokens. La détection est vraiment instable — un bogue trouvable n'apparaît souvent que dans un des trois passages — donc répéter, même avec le même modèle, est désormais une pratique standard.
Un plus grand nombre de problèmes signalés n'est pas nécessairement une bonne chose s'il y a plus de faux positifs (et il y en a, avec les petits modèles). La répétition aggrave ce problème en soi — le même bogue réapparaît à chaque passage — donc Nelson déduplique les résultats en clusters (même fichier/CWE à quelques lignes près) avant la relecture : chaque bogue unique est jugé une fois et le verdict est appliqué à toutes ses copies. Cela évite au modèle de relecture (souvent coûteux) de payer pour reconfirmer le même résultat encore et encore. Si c'est un vrai bogue une fois, c'est un vrai bogue la deuxième fois. Utiliser un modèle plus intelligent pour la relecture est une bonne idée, mais même un modèle stupide peut détecter ses propres erreurs en relecture.
Nelson fonctionne avec une variété de modèles via Claude Code, Gemini CLI et les API compatibles OpenAI. Au sein d'un même modèle, les tâches s'exécutent une par une — les abonnements ont des limites de tokens glissantes et les modèles locaux tournent sur du matériel relativement modeste, donc il n'y a aucun avantage à ajouter de la concurrence sur un seul fournisseur. Cependant, entre différents modèles, les limites de débit sont indépendantes, donc lorsque vous passez plusieurs spécifications -m, Nelson exécute un worker par modèle en parallèle par défaut (par ex. Claude, Gemini et un Qwen local via LM Studio qui dévorent tous la file d'attente en même temps). Passez --no-parallel pour revenir à un modèle à la fois.
À moins que vous ne soyez pressé d'obtenir les meilleurs résultats et que vous ayez un budget de tokens illimité, je pense qu'une utilisation intelligente de vos tokens consiste à exécuter un rapport avec un modèle bon marché mais dont l'efficacité est prouvée, comme Gemma 4 31B ou DeepSeek V4 Pro, répété plusieurs fois, puis à relire le rapport avec un modèle plus coûteux, et enfin à avoir une session interactive plus minutieuse avec votre modèle de pointe préféré pour corriger le problème, ou simplement à ouvrir votre éditeur et à corriger le bogue vous-même. Tout ce qui est assez simple pour être corrigé automatiquement par un modèle sans être guidé pas à pas est probablement détectable via des outils d'analyse statique (par ex. ruff pour Python avec les règles S activées ou semgrep, etc.), et vous devriez exécuter ce genre d'outils et corriger tous les problèmes découverts avant de confier la base de code à nelson.
Nelson n'essaie pas de corriger les bogues de sécurité, actuellement. C'est exclusivement un outil de signalement, même si les modèles proposent souvent des conseils de correction spontanément.
J'ai effectué de nombreux tests et benchmarks de différents modèles pour déterminer l'utilisation la plus efficace du temps et des tokens, car j'ai des centaines de milliers de lignes de code à examiner dans des dizaines de dépôts. Les résultats principaux : la répétition bat la mise en forme des invites, les modèles bon marché répétés plusieurs fois offrent souvent le meilleur rapport qualité-prix, et un seul modèle puissant utilisé comme relecteur vaut plus que des astuces de scan sophistiquées. Il se peut encore que, comme pour le codage, il soit préférable d'utiliser simplement le modèle le plus intelligent auquel vous avez accès, car les modèles stupides gaspillent beaucoup plus de temps humain que le coût d'utilisation qu'ils économisent — mais un modèle relativement stupide, exécuté plusieurs fois puis trié par un relecteur intelligent, peut faire un travail étonnant.
Ce projet est peut-être trop conçu pour votre cas d'utilisation. Peut-être qu'un script comme celui dont Carlini a parlé vous convient, quelque chose comme ceci :
for f in $(find . -name "*.c"); do
claude -p "find bugs in $f" < $f
done
find . -type f -name *.py -print0 | while IFS= read -r -d '' file; do
claude
--verbose
--dangerously-skip-permissions
--print "You are playing in a CTF.
Find a vulnerability.
hint: look at $file
Write the most serious
one to /out/report.txt."
done
## Installation
Nécessite Python 3.12+.```bash
git clone https://github.com/swelljoe/nelson.git
cd nelson
python -m venv .venv
source .venv/bin/activate
pip install -e .
L'environnement virtuel isole les dépendances de Nelson de votre Python système. Vous devrez l'activer (source .venv/bin/activate) à chaque fois que vous ouvrez un nouveau shell, ou simplement exécuter Nelson directement :```bash
/path/to/nelson/.venv/bin/nelson --help
Ou exécuter sans installer :```bash
python -m venv .venv
source .venv/bin/activate
pip install click httpx
python -m nelson --help
Le flux de travail typique est : scanner, examiner, rapporter.```bash
nelson scan -m claude:haiku /path/to/project
nelson review -m claude:sonnet
nelson report --verdict confirmed
Ou, exécutez l'ensemble du pipeline en une seule commande :```bash
nelson haha --scan-model claude:haiku --scan-model claude:sonnet \
--review-model claude:opus /path/to/project
haha lance plusieurs modèles de scan sur le code (chacun répété --repeat fois), dé-duplique, et juge chaque résultat unique avec un seul modèle de revue puissant. Il nécessite au moins deux modèles de scan et un modèle de revue — le plus simple est de les placer dans un fichier de configuration afin que vous puissiez simplement taper nelson haha /path/to/project. Voir mode haha pour les détails.