swelljoe/nelsonSchwachstellen durch einfaches Brute-Force finden
Inspiriert von einem Vortrag von Nicholas Carlini und der Ralph-Schleife ist Nelson ein Tool, das jede Datei in einem Projekt durchläuft und einen Agenten auffordert, nach Schwachstellen zu suchen. Es gibt einen Scan-Modus, ähnlich Carlinis Bash-Schleife, bei dem das Modell aufgefordert wird, in einer Datei oder einem Dateiverzeichnis nach Schwachstellen zu suchen; einen Review-Modus, in dem ein (normalerweise schlauere) Modell jede gemeldete Schwachstelle erneut prüft und entscheidet, ob sie an einen menschlichen Prüfer weitergeleitet werden sollte; und einen De-Duplizierungsschritt dazwischen, sodass derselbe Fehler, der mehrfach gefunden wurde, nur einmal bewertet wird.
Die große Erkenntnis aus umfangreichen Benchmarks ist, dass Wiederholung Fehler zutage fördert. Frühere Versionen hatten einen „Focused Mode", der das Modell bat, eine bestimmte CWE-Klasse auf einmal zu jagen, und es sah so aus, als ob das half – aber das war eine Illusion: Die CWE-spezifische Erweiterung ließ das Modell jede Datei nur mehrmals ansehen, und es war die Wiederholung, nicht die CWE-Ausrichtung, die die Arbeit erledigte. Die Benennung der Fehlerklasse, Checklisten und andere Prompt-Formulierungen brachten in kontrollierten A/B-Tests keine echte Verbesserung. Also ist der Focused Mode verschwunden. Stattdessen führt --repeat N die gesamte Datei × Modell-Matrix N-mal aus (Standard 3), was eine weitaus bessere Nutzung derselben Tokens ist. Die Erkennung ist wirklich unbeständig – ein auffindbarer Fehler taucht oft nur in einem von drei Durchläufen auf – daher ist Wiederholung, selbst mit demselben Modell, jetzt Standardpraxis.
Mehr gemeldete Probleme sind nicht unbedingt gut, wenn es mehr falsch Positive gibt (und das gibt es, bei kleineren Modellen). Wiederholung macht dies von sich aus schlimmer – derselbe Fehler taucht in jedem Durchlauf wieder auf – daher dedupliziert Nelson Funde in Cluster (gleiche Datei/CWE innerhalb weniger Zeilen) vor dem Review: Jeder eindeutige Fehler wird einmal bewertet und das Urteil auf alle Kopien angewendet. Dadurch wird verhindert, dass das (oft teure) Review-Modell immer wieder dasselbe Ergebnis bestätigen muss. Wenn es einmal ein echter Fehler ist, ist es beim zweiten Mal auch ein echter Fehler. Ein schlauere Modell zur Überprüfung zu verwenden, ist eine gute Idee, aber selbst ein dummes Modell kann seine eigenen Fehler im Review erkennen.
Nelson arbeitet mit einer Vielzahl von Modellen über Claude Code, Gemini CLI und OpenAI-kompatible APIs. Innerhalb eines einzelnen Modells werden Jobs nacheinander ausgeführt – Abonnementpläne haben rollierende Token-Limits und lokale Modelle laufen auf relativ bescheidener Hardware, sodass es keinen Vorteil durch zusätzliche Parallelität bei einem Anbieter gibt. Bei verschiedenen Modellen sind die Ratenbegrenzungen jedoch unabhängig, sodass Nelson bei der Übergabe mehrerer -m-Spezifikationen standardmäßig einen Worker pro Modell parallel ausführt (z.B. Claude, Gemini und ein lokales Qwen über LM Studio, die alle gleichzeitig die Warteschlange abarbeiten). Übergeben Sie --no-parallel, um auf ein Modell nach dem anderen zurückzufallen.
Wenn Sie nicht in Eile sind, die besten Ergebnisse zu erzielen, und ein unbegrenztes Token-Budget haben, glaube ich, dass eine kluge Nutzung Ihrer Tokens darin besteht, einen Bericht mit einem billigen, aber bewährten effektiven Modell wie Gemma 4 31B oder DeepSeek V4 Pro zu erstellen, mehrmals wiederholt, dann den Bericht mit einem teureren Modell zu überprüfen und schließlich eine sorgfältigere interaktive Sitzung mit Ihrem bevorzugten Frontier-Modell durchzuführen, um das Problem zu beheben, oder einfach Ihren Editor zu öffnen und den Fehler selbst zu korrigieren. Alles, was einfach genug ist, um von einem Modell ohne Hilfe automatisch behoben zu werden, ist wahrscheinlich durch statische Analysetools erkennbar (z.B. ruff für Python mit aktivierten S-Regeln oder semgrep usw.), und Sie sollten diese Art von Tools ausführen und alle gefundenen Probleme beheben, bevor Sie die Codebasis an nelson übergeben.
Nelson versucht derzeit nicht, Sicherheitsfehler zu beheben. Es ist ausschließlich ein Berichtstool, obwohl Modelle oft unaufgefordert Ratschläge zur Behebung geben.
Ich habe viele Tests und Benchmarks mit verschiedenen Modellen durchgeführt, um die effizienteste Nutzung von Zeit und Tokens herauszufinden, da ich Hunderttausende von Codezeilen in Dutzenden von Repos überprüfen muss. Die wichtigsten Erkenntnisse: Wiederholung schlägt Prompt-Formulierung, billige Modelle, die mehrmals wiederholt werden, sind oft das beste Preis-Leistungs-Verhältnis, und ein einzelnes starkes Modell als Reviewer ist mehr wert als ausgefallene Scan-Tricks. Es kann sich immer noch herausstellen, dass es, wie beim Programmieren, am besten ist, einfach das intelligenteste Modell zu verwenden, das Ihnen zur Verfügung steht, weil die dummen Modelle viel mehr menschliche Zeit verschwenden, als sie an Nutzungskosten sparen – aber ein relativ dummes Modell, das ein paar Mal ausgeführt und dann von einem intelligenten Reviewer triagiert wird, kann erstaunlich viel leisten.
Dieses Projekt könnte für Ihren Anwendungsfall überdimensioniert sein. Vielleicht ist ein Skript wie das, über das Carlini sprach, das Richtige für Sie, so etwas wie:
for f in $(find . -name "*.py"); do
cat $f | head -n 3000 | llm -m gemini-2.5-pro "Describe what this file does and how it works. Look for any security vulnerabilities." > /tmp/output.txt
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
Erfordert 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 .
Die virtuelle Umgebung hält die Abhängigkeiten von Nelson von Ihrem System-Python isoliert. Sie müssen sie aktivieren (source .venv/bin/activate) jedes Mal, wenn Sie eine neue Shell öffnen, oder führen Sie Nelson einfach direkt aus:```bash
/path/to/nelson/.venv/bin/nelson --help
Oder ohne Installation ausführen:```bash
python -m venv .venv
source .venv/bin/activate
pip install click httpx
python -m nelson --help
Der typische Arbeitsablauf ist: scannen, überprüfen, berichten.```bash
nelson scan -m claude:haiku /path/to/project
nelson review -m claude:sonnet
nelson report --verdict confirmed
Oder führen Sie die gesamte Pipeline in einem Befehl aus:```bash
nelson haha --scan-model claude:haiku --scan-model claude:sonnet \
--review-model claude:opus /path/to/project
haha wirft mehrere Scan-Modelle auf den Code (jeweils --repeat-mal wiederholt), dedupliziert und beurteilt jeden eindeutigen Fund mit einem starken Review-Modell. Es werden mindestens zwei Scan-Modelle und ein Review-Modell benötigt – am einfachsten ist es, diese in einer Konfigurationsdatei zu speichern, sodass Sie einfach nelson haha /path/to/project eingeben können. Siehe haha-Modus für Details.