VulnReach

Laufzeitbewusstes SCA – beweist, welche CVEs tatsächlich erreichbar sind, nicht nur installiert.

VulnReach ist jetzt ein offizielles OWASP-Projekt. 🎉

Demo

Schritt 1 – SCA deckt 74 CVEs in den Abhängigkeiten auf

Schritt 2 – VulnReach beweist, welche tatsächlich erreichbar sind

Befunde – Evidenzkette pro CVE

Dashboard – 42 bestätigte erreichbare über 9 Repositories

Sprachunterstützung: Python ist vollständig produktionsreif (Taint, AST, Route, Laufzeit). Java und JavaScript verfügen über eine funktionierende Call-Graph-Analyse und sind experimentell. Go, C# und PHP stehen auf der Roadmap. Siehe ROADMAP.md für Details.

VulnReach baut auf der standardmäßigen SCA-Ausgabe auf und fügt Erreichbarkeitskontext hinzu – es weist durch statische Analyse, Taint-Tracking und Live-Laufzeitabdeckung nach, welche der erkannten CVEs in Ihrer Anwendung tatsächlich erreicht werden können.

Projektstatus

Neueste Entwicklung (ausgeliefert)

• Abhängigkeitsbewusste Parallel-Runner-Pipeline für schnellere Scans
• Python-Erreichbarkeit – produktionsreif (Taint-, AST-, Routen- und Laufzeit-Ebenen voll funktionsfähig)
• Java-Erreichbarkeit – funktionierender Call-Graph mit Maven/Gradle-Abhängigkeitsanalyse (experimentell)
• JavaScript-Erreichbarkeit – funktionierender Call-Graph mit Erkennung von Routen-Einstiegspunkten (experimentell)
• Scan-Abbruch – POST /scan/{id}/cancel stoppt laufende Scans
• Stabiler Scan-Antwortvertrag: summary + klassifizierte Kategorien unter GET /scan/{id}
• Gemeinsame Normalisierung der Scan-Antwort zwischen API und lokalem Paketmodus (Parität)
• Standardmäßig sichere Laufzeitgrenze:
  • Basis-Compose läuft ohne Docker-Socket-Mount
  • Dynamische Scans erfordern ein explizites Opt-in über VULNREACH_ALLOW_DOCKER_DAEMON=true
  • Das Laufzeitprofil verwendet den eingeschränkten docker-socket-proxy
• Deterministische Fixture-Qualitätsprüfungen für Java/JavaScript/Go in CI
• Als offizielles OWASP-Projekt akzeptiert – owasp.community/projects/vulnreach
• KI-Endpunkt für nächste Schritte – POST /findings/{id}/next-steps erzeugt für Analysten bestimmte Sanierungsanleitungen (sofortige Maßnahmen, Validierungssonden, Upgrade-Pfade, Überwachung) für einen deterministischen Befund. Lazy / On-Demand: Scans rufen das LLM nie auf, und LLM-Fehler werden elegant abgefangen. Das deterministische Urteil ist schreibgeschützt. Siehe .

Experimentell

• scan.runtime.ebpf-Tracing-Modus (Linux-fokussiert, explizites Opt-in)
• KI-gestützte OpenAPI-Generierung und intelligente DAST-Abläufe

Siehe:

• docs/incubator-readiness.md
• docs/threat-model.md

So funktioniert es

Jede CVE wird über eine fünfschichtige Evidenzkette klassifiziert:

1. SCA (Trivy)              → is the package installed and vulnerable?
2. Taint analysis (tainter) → does user input flow to the vulnerable sink?
3. AST analysis             → is the vulnerable function in your call graph?
4. Route exposure           → is the call path reachable from an HTTP endpoint?
5. Runtime coverage         → was the vulnerable code actually executed?

Das Ergebnis ist eine priorisierte Befundliste mit vier Stufen:

Schnellstart

Mit Docker Compose (empfohlen)

Sicherheitshinweis – Kopieren Sie vor dem Start .env.example in .env.local und ersetzen Sie jeden CHANGE_ME-Wert durch ein starkes zufälliges Geheimnis.
Setzen Sie VulnReach nicht ohne echte Anmeldedaten und ohne Konfiguration von CORS_ORIGINS einem öffentlichen Netzwerk aus.

git clone https://github.com/ihrishikesh0896/vulnreach.git
cd vulnreach

# 1. Create your local config
cp .env.example .env.local

# 2. Fill in every CHANGE_ME — generate secrets with: openssl rand -hex 32
$EDITOR .env.local

# 3. Start the stack
docker compose up --build

# Optional: enable dynamic runtime scans (Docker daemon access via restricted socket proxy)
# docker compose -f docker-compose.yml -f docker-compose.runtime.yml up --build

Scan ausführen

Authentifizierungsoptionen:

• Kurzlebiges JWT: POST /login
• Langlebiges API-Token (API-Schlüssel): In der Benutzeroberfläche unter Settings -> API Keys erstellen und dann als Authorization: Bearer <API_KEY> verwenden

# Get a token (replace with the credentials you set in .env.local)
TOKEN=$(curl -s -X POST http://localhost:8000/login \
  -H "Content-Type: application/json" \
  -d '{"username":"<your-admin-user>","password":"<your-admin-password>"}' | jq -r .access_token)

# Start scan from a GitHub repo
curl -X POST http://localhost:8000/scan \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"repo_url":"https://github.com/yourorg/yourapp"}'

# Poll for results
curl http://localhost:8000/scan/<scan_id> \
  -H "Authorization: Bearer $TOKEN" | jq .summary

Funktionen

• Nach Erreichbarkeit gefiltertes SCA – klassifiziert jede CVE nach Evidenzstärke, nicht nur nach CVSS-Score
• Laufzeitbestätigung – Docker-basierte Erfassung der Abdeckung über coverage.py
• Taint-Tracking – verfolgt Benutzereingaben zu verwundbaren Senken (SQL, subprocess, YAML, pickle)
• LLM-gesteuertes DAST – Claude/OpenAI/Ollama erzeugt und validiert Exploit-Payloads (optional)
• CI/CD-Gates – policy.block_if lässt Builds bei bestätigten kritischen Befunden fehlschlagen
• JWT-Authentifizierung – Mehrbenutzerzugriff mit rollenbasierter Berechtigung (Admin / Analyst)
• API-Tokens (API-Schlüssel) – langlebige Maschinen-Authentifizierung für curl/CI (Authorization: Bearer <API_KEY>)
• PDF-Export – GET /scan/{id}/export/pdf
• Keine Herstellerbindung – LLM-Funktionen sind standardmäßig auf provider: none gesetzt; Ollama wird für den Offline-Betrieb unterstützt

In der Praxis

Scan-Ziel: multi-tier-dvpa – eine absichtlich verwundbare Python/Django-Anwendung mit 72 rohen CVEs in 11 Paketen.

46 % der Befunde wurden aus der undifferenzierten „alles beheben“-Warteschlange in eine priorisierte Maßnahmenliste verschoben. In einem typischen Produktionsdienst (in dem viele transitive Abhängigkeiten nie aufgerufen werden) steigt dieser Wert auf 70–90 %.

Vollständige Methodik, Details zur Evidenzkette und Aufschlüsselung auf Paketebene: docs/benchmark.md

Dokumentation

Verwendung

• USAGE_PACKAGE.md – Installation von Paket/CLI, Abhängigkeiten, Start, Verwendung
• USAGE_UI.md – Installation von UI/Server, Abhängigkeiten, Start, Verwendung

Betreiber / Bereitsteller

• docs/deployment.md – Docker-Compose-Einrichtung, Umgebungsvariablen, Hinweise für den Produktionsbetrieb
• docs/configuration.md – vollständige scan.yml-Konfigurationsreferenz
• docs/api.md – REST-Endpunkte und Schemas

Architektur / Sicherheit

• docs/architecture.md – Pipeline-Design und Ausführungsmodell
• docs/threat-model.md – Vertrauensgrenzen, STRIDE, Missbrauchsfälle
• docs/incubator-readiness.md – OSS/OWASP-Bereitschaftsstatus
• docs/DAST.md – DAST-Konzepte und -Ablauf

Mitwirkende

• ROADMAP.md – geplante Funktionen, bekannte Einschränkungen, Status der Sprachunterstützung
• docs/development.md – Interna, Agents, Speicherung, Erweiterungspunkte
• OWASP.md – Notizen zum OWASP-Projekt
• SECURITY.md – Offenlegung von Schwachstellen und Schlüsselrotation
• CONTRIBUTING.md – Beitragsprozess
• CHANGELOG.md – Versionshistorie

Anforderungen

• Python 3.11+
• PostgreSQL 13+
• Docker + Docker Compose v2 (für dynamische Analysen)
• trivy im PATH (installieren)
• jq (wird in den Schnellstart-Beispielen verwendet – installieren)

Optional (alles wird elegant übersprungen, wenn nicht vorhanden):

• semgrep – pip install semgrep
• tainter – pip install tainter (Taint-Flow-Analyse; siehe Entwicklungsleitfaden)

Lizenz

Apache 2.0 – siehe LICENSE.