Nelson

Trouver des vulnérabilités par force brute bête

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

Iterate over all files in the source tree.

find . -type f -name *.py -print0 | while IFS= read -r -d '' file; do

Tell Claude Code to look for vulnerabilities in each file.

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

Quickstart

Le flux de travail typique est : scanner, examiner, rapporter.```bash

1. Scan a project, repeating the pass a few times (default --repeat 3)

nelson scan -m claude:haiku /path/to/project

2. Review findings with a smarter model (de-dupes first, then judges each

unique bug once) to filter false positives

nelson review -m claude:sonnet

3. View confirmed findings

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.

Utilisation

Analyse

nelson scan envoie chaque fichier à chaque modèle avec une invite large "find any vulnerability", similaire à l'approche Carlini — une tâche par (fichier, modèle). Le paramètre clé est --repeat : il exécute la matrice entière N fois (par défaut 3). La répétition, et non le ciblage par CWE, est ce qui fait réellement apparaître les bogues, et la détection est suffisamment instable pour qu'un vrai bogue apparaisse souvent dans un seul des trois passages, donc répéter est utile même avec un seul modèle. Les résultats en double entre les passages (et entre les modèles) sont fusionnés au moment de la revue.```bash

Open scan with the default model (claude:haiku), repeated 3 times

nelson scan /path/to/project

A single pass, if you really want one

nelson scan --repeat 1 /path/to/project

A more capable model produces better results

nelson scan -m claude:sonnet /path/to/project

Several models at once (run in parallel, one worker each), repeated 5x

nelson scan -m claude:haiku -m "lmstudio:google/gemma-4-31b" --repeat 5 /path/to/project

**Outils pour les modèles compatibles OpenAI.** Claude Code et Gemini CLI sont déjà
des agents — ils lisent les fichiers dont ils ont besoin par eux-mêmes. Un point d'accès
OpenAI-compatible nu (`openai:`, `lmstudio:`, `ollama:`) ne l'est pas : par défaut, il ne voit
que le seul fichier collé dans l'invite. Utilisez `--tools` pour donner à ces modèles une
boucle d'outils `read_file` / `grep` / `list_dir` en lecture seule, enracinée dans l'arborescence
analysée, afin qu'ils puissent suivre les imports, les appelants et les helpers dans d'autres fichiers
avant de décider si une vulnérabilité est réelle et accessible. (Installez [ripgrep](https://github.com/BurntSushi/ripgrep)
pour l'outil `grep`.) Cela utilise plus de jetons par fichier. C'est sans effet pour les spécifications `claude:` /
`gemini:`.```bash
# Let a local Qwen poke around the project, not just the one file
nelson scan --tools -m "lmstudio:Qwen/Qwen3-27B" /path/to/project

Vous pouvez également pointer nelson scan vers un ou plusieurs fichiers individuels au lieu d'un répertoire entier. Ceci est utile pour vérifier ponctuellement un seul fichier, ou pour analyser tout ce qu'un glob shell développe. Lorsque vous nommez explicitement des fichiers, les filtres habituels basés sur les chemins (patterns de test/doc, détection de fichiers générés) sont ignorés — Nelson vous fait confiance pour savoir ce que vous voulez. Il en va de même pour nelson inventory et nelson haha.```bash

Scan a single file

nelson scan path/to/suspicious.py

Scan everything a glob expands to (shell does the expansion)

nelson scan src/api/*.py

Mix and match — multiple explicit files are fine

nelson scan src/auth.py src/db.py src/handlers/*.go

Same shape works for inventory and haha

nelson inventory src/api/*.py nelson haha src/auth.py src/db.py

Les analyses sont interrompables. Si interrompu, reprenez simplement par ID d'analyse :```bash
nelson scan --resume 3

Révision

Le passage de révision commence par dédupliquer les résultats du scan en clusters (même fichier et CWE, numéros de ligne dans --line-tolerance, par défaut 2), puis envoie un représentant par cluster à un modèle (de préférence plus intelligent) avec le fichier source complet, en lui demandant de tracer le flux d'exécution et d'évaluer si la vulnérabilité est atteignable et réaliste. Le verdict résultant est appliqué à chaque résultat du cluster, de sorte qu'un bogue que --repeat et plusieurs modèles ont révélé de nombreuses fois est jugé une seule fois — le réviseur n'est pas payé encore et encore pour le même résultat. Toutes les lignes en double sont conservées (avec le modèle/pass qui les a trouvées) afin que la vue comparaison fonctionne toujours.```bash

Review with Claude Sonnet (default)

nelson review

Review a specific scan

nelson review 3

Review with a different model

nelson review -m claude:opus

Widen/narrow how aggressively near-by findings are treated as one bug

nelson review --line-tolerance 5

Let an OpenAI-compatible reviewer read related files while tracing reachability

nelson review -m "lmstudio:Qwen/Qwen3-27B" --tools

Chaque découverte reçoit un verdict : `confirmed`, `false_positive`, `needs_review` ou `resolved` (si le fichier a été supprimé depuis l'analyse). Le flag `--tools` fonctionne de la même manière que pour `nelson scan` : il donne à un modèle compatible OpenAI (`openai:`/`lmstudio:`/`ollama:`) une boucle en lecture seule `read_file`/`grep`/`list_dir` sur l'arbre analysé, afin qu'il puisse suivre une découverte dans les fichiers qu'elle touche avant de statuer sur l'accessibilité. C'est une opération sans effet pour `claude:`/`gemini:`, qui lisent déjà les fichiers par eux-mêmes. La révision est idempotente -- en l'exécutant à nouveau, seules les découvertes non examinées sont traitées, vous pouvez donc réviser avec un modèle puis effectuer un second passage avec un autre.

### Reporting```bash
# Show all findings from the latest scan
nelson report

# Show findings from a specific scan
nelson report 3

# Filter by review verdict
nelson report --verdict confirmed
nelson report --verdict false_positive
nelson report --verdict needs_review

# Filter by confidence or CWE
nelson report --confidence high
nelson report --cwe CWE-89

# JSON output for scripting
nelson report --json-output
nelson report --verdict confirmed --json-output

Comparaison des modèles

Lorsque vous analysez avec plusieurs modèles (en parallèle ou non), nelson compare regroupe les résultats en groupes de « même problème » afin que vous puissiez voir où les modèles étaient d'accord :```bash

Compare models within a single multi-model scan (default: latest)

nelson compare nelson compare 5

Compare across separate scans on the same target/commit

nelson compare --scans 3,5,7

Tighter or looser matching (default: ±2 lines)

nelson compare --line-tolerance 0 # exact line match only nelson compare --line-tolerance 5 # more forgiving

Filters

nelson compare --min-agreement 2 # only show clusters >= 2 models flagged nelson compare --cwe CWE-89 nelson compare --confidence high

JSON for scripting / your own benchmarking

nelson compare --json-output

HTML version

nelson html-compare nelson html-compare --scans 3,5,7 -o my-comparison.html

Un « cluster » est un problème apparent : même fichier, même CWE, numéros de ligne dans la fenêtre de tolérance. Pour chaque cluster, le rapport montre quels modèles l'ont signalé et quels modèles ont eu l'occasion de le signaler mais ne l'ont pas fait (l'ensemble des électeurs éligibles est constitué de chaque modèle qui a terminé un scan ouvert sur ce fichier). Les clusters avec un haut degré d'accord (par exemple 3/3) sont un signal fort ; les clusters d'un seul modèle sont généralement des faux positifs. Utile à la fois pour filtrer le bruit et pour voir comment un petit modèle local se compare à un modèle de pointe.

### Rapports HTML

![Exemple de rapport HTML montrant les totaux et les résultats révisés](https://assets.kitploit.com/production/public/readmes/9113/03ad22bd9693d8bd8cac544a054001dfe45d77f3174f7b1afe9f4e04355b8383.png)

Nelson peut générer des rapports HTML statiques autonomes :```bash
# Detailed report for a single scan (default: latest)
nelson html-report
nelson html-report 3
nelson html-report -o my-report.html

# Executive summary across all scans
nelson html-summary
nelson html-summary -o summary.html

Le rapport détaillé montre chaque résultat groupé par fichier, avec des badges de confiance, des verdicts de révision, des extraits de code et l'utilisation de jetons. Le résumé exécutif est une page unique affichant tous les scans avec les comptes de confirmés/faux positifs/à réviser et une répartition des résultats confirmés par scan.

Autres commandes```bash

List source files that would be scanned, with security tooling assessment

nelson inventory /path/to/project

(also accepts individual files or globs, just like nelson scan)

List all scans

nelson list

Show detailed status of a scan (job counts, token usage, review summary)

nelson status nelson status 3

### Mode Haha

La commande `haha` (la phrase fétiche de Nelson) envoie tout sur le code en une seule fois :

1. **Scan** — chaque modèle de scan audite chaque fichier, `--repeat` fois chacun (par défaut 3)
2. **Dedup** — les résultats combinés sont regroupés en bogues uniques
3. **Review** — un modèle de révision fort évalue chaque bogue unique une fois
4. **Summary** — imprime les décomptes de confirmés/faux positifs/à réviser

Il nécessite **au moins deux modèles de scan et un modèle de révision**. Fournissez-les en ligne de commande, ou — plus commodément — dans un [fichier de configuration](#configuration) ; `haha` se termine avec une erreur s'il ne les trouve pas.```bash
# Models from ./nelson.yaml or ~/.nelson.yaml
nelson haha /path/to/project

# Or specify on the command line (--scan-model is repeatable)
nelson haha /path/to/project \
    --scan-model "openai:deepseek-v4-flash@https://api.deepseek.com/v1" \
    --scan-model "lmstudio:google/gemma-4-26b-a4b" \
    --review-model claude:opus \
    --repeat 3

Tout atterrit dans un seul scan, que vous pouvez inspecter ensuite avec nelson report <scan_id>, nelson html-report <scan_id>, ou nelson compare <scan_id>.

Avertissement sur l'utilisation des tokens : Sur un grand projet, haha consomme beaucoup de tokens et prend du temps — il exécute files × scan_models × repeat tâches de scan plus une tâche de révision par bogue unique. Envisagez d'exécuter les commandes individuelles nelson scan et nelson review si vous voulez plus de contrôle sur le rythme et le coût.

Configuration

Nelson lit une configuration YAML optionnelle pour que vous n'ayez pas à retaper vos modèles préférés par étape. Il cherche d'abord ./nelson.yaml (projet-local) puis ~/.nelson.yaml (répertoire personnel) ; le fichier projet l'emporte par clé, et les options explicites en ligne de commande remplacent les deux. Toutes les clés sont optionnelles :```yaml

nelson.yaml

scan_models: # used by haha (needs >= 2) and as the default for scan

• openai:deepseek-v4-flash@https://api.deepseek.com/v1
• lmstudio:google/gemma-4-31b review_model: claude:opus # used by haha (required) and as the default for review repeat: 3 # default number of passes db: nelson.db # default database path delay: 2.0 # default per-job pacing (seconds)

Avec cela en place, `nelson haha /path/to/project` fonctionne directement, et `nelson scan` / `nelson review` reprennent les mêmes réglages par défaut sauf si vous les remplacez.

## Configuration des modèles

Les modèles sont spécifiés avec une syntaxe `type:model` :

| Spec | Description |
|------|-------------|
| `claude:haiku` | Claude Haiku via CLI |
| `claude:sonnet` | Claude Sonnet via CLI |
| `claude:opus` | Claude Opus via CLI |
| `gemini:gemini-2.5-flash` | Gemini CLI avec modèle spécifique |
| `gemini:` | Gemini CLI avec modèle par défaut |
| `lmstudio:google/gemma-4-26b-a4b` | LM Studio sur localhost:1234 |
| `ollama:llama3` | Ollama sur localhost:11434 |
| `openai:model@http://host:port/v1` | Tout point de terminaison d'API compatible OpenAI (local ou hébergé) |
| `openai:deepseek-v4-pro@https://api.deepseek.com/v1` | DeepSeek (hébergé) |
| `openai:nvidia/nemotron-3-super-120b-a12b@https://openrouter.ai/api/v1` | OpenRouter (hébergé) |

Le type `openai:` parle à tout ce qui parle l'API OpenAI chat-completions — un serveur local *ou* un fournisseur hébergé. Pour les serveurs locaux (spec `lmstudio:`, `ollama:`, ou `openai:...@http://localhost...`) aucune clé n'est nécessaire. Pour les fournisseurs hébergés, voir [Hosted API models](#hosted-api-models-deepseek-mimo-openrouter) ci-dessous.

Plusieurs modèles peuvent être utilisés dans un seul scan pour comparer leur efficacité. Par défaut, ils s'exécutent en parallèle — un worker par modèle, car les limites de débit sont par fournisseur :```bash
# Claude Haiku and a local Qwen model both work the queue at once
nelson scan /path/to/project \
    -m claude:haiku \
    -m "lmstudio:Qwen/Qwen3-27B"

Use --no-parallel si vous préférez épuiser chaque modèle en séquence (par exemple, pour réduire la contention CPU/GPU entre deux modèles locaux sur la même machine).

Les agents en ligne de commande (Claude Code, Gemini CLI) sont espacés avec un délai configurable entre les tâches afin d'éviter d'atteindre les limites d'abonnement récurrentes. Les modèles basés sur une API (LM Studio, Ollama, endpoints personnalisés) s'exécutent sans délai. Le délai par défaut est de 2 secondes ; ajustez avec --delay. Le rythme est par travailleur, donc chaque modèle attend indépendamment son délai entre ses propres tâches :```bash nelson scan /path/to/project -m claude:haiku --delay 5

### Modèles d'API hébergés (DeepSeek, MiMo, OpenRouter)

Vous n'avez pas besoin d'un GPU local pour exécuter un modèle bon marché. Tout fournisseur hébergé avec un point de terminaison compatible OpenAI fonctionne via la spécification `openai:`, sous la forme `openai:MODEL@BASE_URL` où `BASE_URL` se termine par `/v1`. Dans mes benchmarks, ces modèles « bon marché » hébergés — DeepSeek et le MiMo de Xiaomi en particulier — ont été les leaders en termes de rapport qualité-prix/performance : ils trouvent la plupart de ce que les modèles de frontière trouvent pour une fraction du coût, ce qui en fait un bon choix pour l'approche systématique de Nelson sur tous les fichiers.

**Authentification.** Nelson lit la clé depuis la variable d'environnement `OPENAI_API_KEY` (la convention universelle compatible OpenAI). Exportez la clé de votre fournisseur sous ce nom avant l'analyse — quel que soit le fournisseur pointé par `@BASE_URL` :```bash
export OPENAI_API_KEY="sk-your-provider-key"

Garder la clé dans l'environnement (ou dans un fichier .env non suivi que vous source) la maintient hors de votre historique de shell et hors de tout fichier que Nelson écrit. Une clé manquante ou rejetée se manifeste par un échec d'authentification, jamais par un silencieux « scanné et rien trouvé ».

DeepSeek — deepseek-v4-pro est le modèle plus puissant/plus cher, deepseek-v4-flash le moins cher :```bash export OPENAI_API_KEY="sk-..." # your DeepSeek key

nelson scan /path/to/project -m "openai:deepseek-v4-pro@https://api.deepseek.com/v1"

Cheaper, still surprisingly capable

nelson scan /path/to/project -m "openai:deepseek-v4-flash@https://api.deepseek.com/v1"

**MiMo (Xiaomi)** — pointer vers le point de terminaison compatible OpenAI de MiMo :```bash
export OPENAI_API_KEY="..."      # your MiMo key

nelson scan /path/to/project \
    -m "openai:mimo-v2.5-pro@https://token-plan-sgp.xiaomimimo.com/v1"

OpenRouter — une seule clé et une URL de base permettent d'accéder à la plupart des modèles majeurs derrière un seul compte ; l'identifiant du modèle est le slug préfixé par le fournisseur provenant du catalogue d'OpenRouter (par exemple nvidia/nemotron-3-super-120b-a12b, ajoutez :free pour une route gratuite). C'est un moyen pratique d'essayer de nombreux modèles sans s'inscrire auprès de chaque fournisseur :```bash export OPENAI_API_KEY="sk-or-..." # your OpenRouter key

nelson scan /path/to/project
-m "openai:nvidia/nemotron-3-super-120b-a12b@https://openrouter.ai/api/v1"

Par défaut un modèle hébergé `openai:` est **single-shot** — il ne voit que le seul fichier collé dans chaque invite. Ajoutez `--tools` (voir [Analyse](#scanning)) pour lui donner une boucle en lecture seule `read_file`/`grep`/`list_dir` sur le projet afin qu’il puisse suivre les imports et les sites d’appel dans d’autres fichiers avant de décider qu’une découverte est réelle. Cela coûte plus de tokens mais tend à réduire les faux positifs :```bash
nelson scan --tools /path/to/project \
    -m "openai:deepseek-v4-pro@https://api.deepseek.com/v1"

La même spécification et OPENAI_API_KEY fonctionnent pour nelson review — un modèle hébergé bon marché peut scanner et un modèle plus puissant peut réviser, ou vice versa :```bash nelson review -m "openai:deepseek-v4-pro@https://api.deepseek.com/v1" --tools

Étant donné que les limites de débit sont par fournisseur, vous pouvez mélanger un modèle hébergé avec un modèle local
(ou Claude/Gemini) dans un seul scan et Nelson exécute un travailleur par modèle en
parallèle :```bash
nelson scan /path/to/project \
    -m "openai:deepseek-v4-flash@https://api.deepseek.com/v1" \
    -m "lmstudio:Qwen/Qwen3-27B" \
    -m claude:haiku

Invites

L'invite de scan demande au modèle de trouver quoi que ce soit dans un seul fichier, une invite par tâche (fichier, modèle) (et toute la matrice est répétée --repeat fois) :``` You are a security researcher performing a vulnerability audit. Analyze the following python file and find any security vulnerabilities.

Look for all classes of vulnerability including but not limited to:

• Injection attacks (SQL, command, code, XSS, etc.)
• Authentication and authorization flaws
• Cryptographic weaknesses
• Path traversal
• Hard-coded credentials
• Any other security-relevant bugs

IMPORTANT INSTRUCTIONS:

• If you find NO vulnerabilities, you MUST return exactly: []
• If you find vulnerabilities, return a JSON array of objects with these fields:
  • "line": the line number (integer)
  • "code": the vulnerable code snippet (string)
  • "cwe": the CWE ID if you can identify one, otherwise "unknown" (string)
  • "explanation": what the vulnerability is and why it matters (string)
  • "confidence": "high", "medium", or "low" (string)
• Return ONLY the JSON array, no other text.
• Rank by severity — put the most serious vulnerability first.

File: app/db.py

Le modèle identifie la CWE elle-même ; Nelson l'enregistre avec la constatation et l'utilise (ainsi que le numéro de ligne) pour regrouper les rapports en double lors de la révision. La passe de révision utilise une invite séparée qui fournit au réviseur le fichier complet et la constatation signalée, et lui demande de tracer l'atteignabilité et de classer `confirmed` / `false_positive` / `needs_review`.

## File filtering

Nelson exclut automatiquement les fichiers qui sont peu susceptibles de contenir des vulnérabilités de production :

- **Test code** : `test_*`, `*_test.*`, `*_spec.*`, `tests/`, `__tests__/`, etc.
- **Documentation** : `docs/`, `*.md`, `*.txt`
- **Generated code** : fichiers avec en-têtes "DO NOT EDIT" / "AUTO-GENERATED"
- **Vendored code** : `vendor/`, `node_modules/`, `third_party/`
- **Large files** : plus de 500 Ko
- **Non-source files** : analyse uniquement les fichiers avec extensions reconnues (`.py`, `.go`, `.ts`, `.js`, `.c`, `.cpp`, `.rs`, `.java`, `.rb`, `.php`, `.pl`, `.pm`, `.sh`)

Utilisez `nelson inventory /path/to/project` pour voir exactement quels fichiers seraient analysés.

Ces filtres ne s'appliquent que lors de l'analyse d'un répertoire. Si vous nommez des fichiers explicitement en ligne de commande (par exemple `nelson scan src/foo.py src/bar.py`), seules les vérifications d'extension et de taille sont appliquées — la détection des fichiers de test/doc/générés est ignorée, en supposant que vous avez tapé ce que vous vouliez.

## Security tooling assessment

Nelson vérifie si votre projet utilise les outils d'analyse statique recommandés et signale les lacunes. Cela s'exécute automatiquement dans le cadre de `nelson inventory` et `nelson report`. Par exemple, il signalera si :

- Ruff est présent mais les règles de sécurité S (Bandit) ne sont pas activées
- Un projet Go n'a pas de golangci-lint avec gosec
- Un projet TypeScript n'a pas eslint-plugin-security
- Un projet Perl n'a pas de configuration Perl::Critic

L'idée est que les outils d'analyse statique sont moins chers et plus rapides que l'IA pour la détection de motifs de vulnérabilités, et Nelson devrait les compléter plutôt que de dupliquer leur travail.

## Database

L'état de l'analyse est stocké dans une base de données SQLite (`nelson.db` dans le répertoire courant par défaut). Utilisez `--db` pour spécifier un chemin différent.

Tous les résultats d'analyse, constatations et verdicts de révision sont conservés, ce qui facilite la comparaison des résultats entre modèles, modes et temps.

## Token tracking

Nelson suit l'utilisation des tokens et le coût par tâche. Utilisez `nelson status` pour voir les totaux.