LLMGui — Security Commands

LLMGui bringt eine vollständige Security Operations Toolchain als Slash-Commands mit — von statischer Analyse über Dependency-Audits bis hin zu autonomen Self-Healing-Loops, File Integrity Monitoring und Docker-Sandbox-Execution.

Alle Findings werden zentral in ~/.brainy/security_findings.db (SQLite) persistiert. Der Control Center Security-Tab und die VS Code Findings-TreeView greifen auf dieselbe Datenbank zu.

Navigation

Überblick

Command	Kurzbeschreibung
`/full-audit`	Alle Checks in einem Durchlauf
`/security`	Statischer Security-Scan (bandit)
`/vuln-scan`	Multi-Layer Dependency-Audit
`/secret-scan`	Secrets & API-Key-Erkennung
`/sec-audit`	OWASP Top 10 Compliance-Audit
`/pentest`	Adversarielle Taint-Path-Analyse
`/fuzz`	Smart Fuzzing mit generierten Payloads
`/exploit-gen`	PoC-Exploit-Generator
`/threat-model`	STRIDE Threat Modeling
`/hardening-gen`	Infrastructure Hardening-Generator
`/sec-fix`	Autonomer Self-Healing Loop
`/sec-verify`	Fix-Verifikation via Re-Exploit
`/sec-log`	Security-Log aus Datenbank
`/sec-monitor`	Real-Time File Integrity Monitoring
`/sandbox-exec`	Isolierte Docker-Sandbox-Ausführung
`/sec-lab`	Docker Pentest Lab Start/Stop
`/harden`	Autonomer Security-Repair-Loop

Datenbank & Findings-Workflow

Alle Scan-Commands speichern ihre Befunde automatisch in:

~/.brainy/security_findings.db   (SQLite)
  ├── findings          — Security-Befunde (CVEs, Secrets, Lint-Issues)
  ├── fim_events        — File Integrity Monitoring Events
  └── threat_models     — STRIDE-Modelle (Mermaid + JSON)

Schema (findings):

Spalte	Typ	Beschreibung
`id`	INTEGER	Primärschlüssel — wird von `/sec-fix` und `/sec-verify` genutzt
`ts`	TEXT	Timestamp (ISO 8601 UTC)
`tool`	TEXT	Erzeugendes Tool (bandit, pip-audit, safety, semgrep, …)
`package_or_file`	TEXT	Betroffene Datei oder Paketname
`vuln_id`	TEXT	CVE-ID, Regel-Code oder Schwachstellenname
`severity`	TEXT	critical / high / medium / low / info
`cvss_score`	REAL	CVSS-Score (0.0–10.0)
`description`	TEXT	Beschreibung der Schwachstelle
`fix_available`	TEXT	Fix-Vorschlag oder verfügbare Version
`line`	INTEGER	Zeilennummer (bei Datei-Befunden)
`status`	TEXT	open / fixed / verified_fixed
`project_path`	TEXT	Workspace-Pfad
`consensus`	INTEGER	Anzahl Tools die denselben Befund bestätigen

REST-Zugriff: GET /api/findings?workspace=...&status=open

Commands im Detail

/full-audit

Alle Checks in einem Durchlauf — der schnellste Weg zu einem vollständigen Überblick.

/full-audit [path]

Führt 7 Checks sequenziell aus:

#	Check	Tool
1	Linting	flake8 / ruff / pylint
2	Type Check	mypy
3	Security (statisch)	bandit
4	Complexity	radon
5	Dead Code	vulture
6	Dependency-Scan	pip-audit / safety / semgrep
7	Secret-Scan	Regex + Shannon-Entropy

Ohne Argument wird der aktuelle Workspace gescannt. Jeder Schritt zeigt in VS Code einen animierten Spinner (→ Checkmark). Am Ende: Summary-Tabelle + Anzahl offener DB-Findings nach Severity.

/full-audit                        # scannt gesamten Workspace
/full-audit src/                   # scannt nur src/
/full-audit auth.py                # scannt einzelne Datei

/security

Statischer Security-Scan via bandit.

/security <file_or_directory>

Scannt Python-Code auf bekannte Sicherheitsmuster (SQL-Injection, hardcoded Credentials, unsichere Hash-Algorithmen etc.). Bei High/Medium-Findings wird zusätzlich eine LLM-Analyse mit Remediation-Vorschlägen gestartet. Findings werden in die DB gespeichert.

/security src/auth.py
/security brainy/

/vuln-scan

Multi-Layer Dependency-Audit — kombiniert mehrere Tools zu einem einheitlichen Report mit CVSS-Scoring.

/vuln-scan [path] [--sbom] [--cbom]

Scanner (in Reihenfolge):

Tool	Scope
`bandit`	Python-Quellcode — unsichere Patterns
`pip-audit`	Python-Dependencies — CVE-Datenbank
`safety`	Python-Dependencies — Snyk-Datenbank
`npm audit`	Node.js-Dependencies
`semgrep p/php`	PHP-Quellcode
`semgrep p/secrets`	Alle Dateien — hardcoded Secrets

CVSS-Matrix (eigene Formel wenn kein offizieller Score):

Severity × Confidence	CVSS
ERROR + HIGH	9.0
ERROR + MEDIUM	8.0
WARNING + MEDIUM	5.5
WARNING + LOW	3.5

Optionen:
- --sbom — generiert Software Bill of Materials (CycloneDX JSON)
- --cbom — generiert Cryptography BOM

Deduplication: Befunde, die von mehreren Tools identifiziert werden, werden zusammengeführt (consensus-Feld gibt an, wie viele Tools übereinstimmen).

/vuln-scan .                       # aktueller Workspace
/vuln-scan /pfad/zum/projekt
/vuln-scan . --sbom

/secret-scan

Deep Secret Scan — kombiniert Regex, Shannon-Entropie und Git-History-Analyse.

/secret-scan [directory]

Drei Scan-Ebenen:

Regex-Patterns — ~40 vordefinierte Muster für API-Keys, Tokens, Passwörter (AWS, GCP, GitHub, Stripe, Twilio, …)
Shannon-Entropie — erkennt hochentropische Strings die kein valides Wort sind (typisch für Secrets ohne bekanntes Format)
Git-History — scannt die letzten 50 Commits nach Secrets die gelöscht wurden (git show diff)

Findings werden nach Severity gruppiert und in die DB gespeichert.

/secret-scan                       # scannt Workspace
/secret-scan /pfad/zum/projekt

/sec-audit

OWASP Top 10 Compliance-Audit — A01 bis A07 mit CVSS-Scoring und optionalem Consensus-Modus.

/sec-audit <file_or_directory> [--consensus]

Prüft auf die kritischsten OWASP-Kategorien:

OWASP	Kategorie
A01	Broken Access Control
A02	Cryptographic Failures
A03	Injection (SQL, Command, XSS)
A04	Insecure Design
A05	Security Misconfiguration
A06	Vulnerable and Outdated Components
A07	Identification and Authentication Failures

Mit --consensus wird jeder Befund von einem zweiten LLM-Aufruf bestätigt, um False Positives zu reduzieren. Ergebnisse werden in die DB gespeichert.

/sec-audit src/
/sec-audit auth.py --consensus

/pentest

Adversarielle Taint-Analyse — intra- und inter-prozedurale Pfadverfolgung von Sources zu Sinks.

/pentest <file_or_directory>

Analysiert den Code wie ein Angreifer: verfolgt wie externe Eingaben (HTTP-Parameter, Umgebungsvariablen, Dateien) durch den Code fließen und ob sie ungefiltert gefährliche Sinks (SQL, Shell, Filesystem) erreichen. Liefert konkrete Angriffspfade mit Evidenz.

/pentest src/api/
/pentest webapp/views.py

/fuzz

Smart Fuzzing — extrahiert Funktionssignaturen und generiert gezielt Payloads.

/fuzz <file> [--sandbox]

Analysiert die Funktionssignaturen der Zieldatei und generiert einen Fuzzing-Harness mit:
- Boundary-Values (0, -1, MAX_INT, leerer String, None, …)
- Injection-Payloads (SQL, XSS, Path Traversal, …)
- Typ-Mismatch-Tests

Mit --sandbox wird der generierte Harness in einer isolierten Docker-Umgebung ausgeführt.

/fuzz src/parser.py
/fuzz src/api.py --sandbox

/exploit-gen

PoC-Exploit-Generator — für beschriebene Schwachstellen.

/exploit-gen <vulnerability_description>

Generiert einen Proof-of-Concept-Exploit basierend auf einer natürlichsprachigen Beschreibung. Geeignet für Penetration-Testing-Engagements und CTF-Challenges. Gibt klar an wenn eine beschriebene Schwachstelle nicht ausnutzbar erscheint.

/exploit-gen "SQL injection in login endpoint via username parameter"
/exploit-gen "Deserialization vulnerability in the session handler"

/threat-model

Automatisches STRIDE Threat Modeling — generiert ein interaktives Mermaid-Risikodiagramm.

/threat-model [directory]

Analysiert den Quellcode und generiert:
- Ein STRIDE-Threat-Model (JSON) mit identifizierten Bedrohungen je Kategorie
- Ein Mermaid-Diagramm der Angriffspfade und Komponenten

Das Modell wird in ~/.brainy/security_findings.db (Tabelle threat_models) persistiert und kann im Control Center betrachtet werden.

/threat-model                      # analysiert Workspace
/threat-model src/

/hardening-gen

Infrastructure Hardening — generiert sicherheitskonforme Konfigurationsdateien.

/hardening-gen [directory]

Analysiert das Projekt und generiert:
- security.Dockerfile — gehärtetes Dockerfile (non-root, minimales Image, read-only FS)
- .env.example.secure — Template für Umgebungsvariablen mit Hinweisen zu sicheren Werten

/hardening-gen .
/hardening-gen /pfad/zum/projekt

/sec-fix

Self-Healing Loop — lässt das LLM einen DB-Finding autonom beheben.

/sec-fix <id>

Die <id> stammt aus /sec-log oder dem Control Center Security-Tab.

Ablauf:
1. Finding aus DB laden (Tool, Datei, Zeile, Beschreibung)
2. Datei-Kontext (±20 Zeilen) laden
3. LLM generiert Patch
4. Patch wird auf die Datei angewendet
5. Finding-Status wird auf fixed gesetzt

/sec-fix 42
/sec-fix 117

/sec-verify

Fix-Verifikation via automatisiertem Re-Exploit — bestätigt ob ein Patch wirklich hält.

/sec-verify <finding_id>

Generiert einen PoC-Exploit für das Finding und führt ihn in einer Docker-Sandbox aus. Schlägt der Exploit nach dem Fix fehl → Status wird auf verified_fixed gesetzt. Funktioniert der Exploit noch → Fix ist unvollständig.

/sec-verify 42

/sec-log

Security-Log — zeigt persistierte Befunde aus der Datenbank.

/sec-log [--critical|--high|--medium] [--tool <name>] [--count <n>]

Liest direkt aus ~/.brainy/security_findings.db und zeigt die neuesten Findings tabellarisch an. Nützlich um die ID für /sec-fix oder /sec-verify zu ermitteln.

/sec-log                           # letzte 20 Findings (alle Severity)
/sec-log --critical                # nur Critical
/sec-log --high --count 50         # letzte 50 High-Findings
/sec-log --tool bandit             # nur bandit-Findings

/sec-monitor

Real-Time File Integrity Monitoring (FIM) — überwacht kritische Dateien via watchdog und SQLite-Eventlog.

/sec-monitor [directory] [--stop] [--log] [--watch <glob,...>]

Startet einen Background-Observer auf dem Verzeichnis. Jede Dateimodifikation wird in fim_events geloggt. Kritische Dateien (.env, settings.py, config.*, etc.) lösen sofort einen AI-Judge aus, der entscheidet ob die Änderung legitim oder verdächtig ist.

/sec-monitor .                     # startet FIM im Workspace
/sec-monitor . --watch .env,*.cfg  # zusätzliche Patterns
/sec-monitor --stop                # beendet laufenden Monitor
/sec-monitor --log                 # zeigt FIM-Eventlog

/sandbox-exec

Isolierte Docker-Sandbox — führt Code mit Behavioral Monitoring aus. Kein Netzwerk, limitierte Ressourcen.

/sandbox-exec <script_path_or_code> [--image python:slim] [--timeout 30]

Führt ein Skript oder einen Inline-Code in einem gekapselten Docker-Container aus:
- Kein Netzwerkzugang (--network none)
- Memory-Limit (256 MB Standard)
- CPU-Limit (0.5 Cores)
- Behavioral Monitoring: Syscall-Tracing, Filesystem-Änderungen

Ideal für das Testen von unbekanntem Code, Fuzzing-Harnessen oder PoC-Exploits.

/sandbox-exec test_exploit.py
/sandbox-exec test_exploit.py --timeout 60
/sandbox-exec test_exploit.py --image python:3.12-slim

/sec-lab

Docker Pentest Lab — Start/Stop einer vollständigen Pentest-Umgebung.

/sec-lab <start|stop|status>

Verwaltet ein Docker-basiertes Pentest-Lab mit vorinstallierten Tools (nmap, metasploit, etc.).

/sec-lab start
/sec-lab status
/sec-lab stop

/harden

Autonomer Security-Repair-Loop — kombiniert Diagnose und Behebung.

/harden <file_or_path>

Führt zunächst einen kombinierten Scan (bandit + Pattern-Analyse) durch und startet dann für jeden kritischen Befund automatisch einen Repair-Loop: LLM generiert Patch → anwenden → erneut scannen bis sauber oder max. Iterations-Limit erreicht.

/harden src/auth.py
/harden src/api/

Workflow-Beispiel: Vollständiges Security-Audit

# 1. Alle Checks auf einmal
/full-audit .

# 2. Findings ansehen
/sec-log --critical

# 3. Kritischen Befund fixen (ID aus sec-log)
/sec-fix 42

# 4. Fix verifizieren
/sec-verify 42

# 5. Threat Model erstellen
/threat-model .

# 6. Monitoring aktivieren (läuft im Hintergrund)
/sec-monitor .

VS Code Integration

Nach einem Scan erscheinen Findings automatisch in:

Security Findings TreeView (LLMGui-Seitenleiste) — nach Severity gruppiert, Klick öffnet die Datei an der betroffenen Zeile
CodeLens-Annotierungen über betroffenen Funktionen im Editor
VS Code Problems (Diagnostics)
Badge an der Findings-View zeigt Anzahl offener Befunde

Rechtsklick auf ein Finding → "Mit LLMGui fixen" startet direkt einen /sec-fix-Prompt im Chat.