VulnReach

Laufzeitbewusste 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 Abhängigkeiten auf

Schritt 2 — VulnReach beweist, welche davon tatsächlich erreichbar sind

---

Findings — Evidenzkette pro CVE

Dashboard — 42 bestätigt erreichbar über 9 Repos

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

VulnReach baut auf der Standard-SCA-Ausgabe auf und ergänzt Erreichbarkeitskontext — es beweist durch statische Analyse, Taint-Tracking und Live-Runtime-Abdeckung, welche der erkannten CVEs in Ihrer Anwendung tatsächlich erreichbar sind.

---

Projektstatus

Neueste Entwicklung (ausgeliefert)

• Abhängigkeitsbewusste parallele Runner-Pipeline für schnellere Scans
• Python-Erreichbarkeit — produktionsreif (Taint-, AST-, Route-, Runtime-Ebenen alle funktional)
• Java-Erreichbarkeit — funktionaler Call Graph mit Maven/Gradle-Abhängigkeitsanalyse (experimentell)
• JavaScript-Erreichbarkeit — funktionaler Call Graph mit Erkennung von Route-Einstiegspunkten (experimentell)
• Scan-Abbruch — POST /scan/{id}/cancel stoppt laufende Scans
• Stabiles Scan-Response-Contract: summary + klassifizierte Buckets bei GET /scan/{id}
• Gemeinsame Scan-Response-Normalisierung über API und Package-Local-Modus (Parität)
• Secure-by-default Runtime-Grenze:
  • Basis-Compose läuft ohne Docker-Socket-Mount
  • Dynamische Scans erfordern explizites Opt-in via VULNREACH_ALLOW_DOCKER_DAEMON=true
  • Runtime-Profil verwendet eingeschränkten docker-socket-proxy
• Deterministische Fixture-Qualitätsgates für Java/JavaScript/Go in CI
• Als offizielles OWASP-Projekt akzeptiert — owasp.community/projects/vulnreach
• AI-Next-Steps-Endpunkt — POST /findings/{id}/next-steps erzeugt analystenorientierte Remediation-Hinweise (sofortige Maßnahmen, Validierungsproben, Upgrade-Pfade, Monitoring) für einen deterministischen Finding. Lazy / On-Demand: Scans rufen niemals das LLM auf, und LLM-Fehler degradieren graceful. Das deterministische Urteil ist read-only. Siehe docs/api.md.

Experimentell

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

Siehe:

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

---

Funktionsweise

Jede CVE wird durch 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 Finding-Liste mit vier Stufen:

Stufe	Bedeutung
DYNAMICALLY_REACHABLE	Runtime-Abdeckung bestätigte Ausführung — sofort beheben
STATICALLY_REACHABLE	Codepfad über AST/Taint bewiesen — hohe Priorität
UNCERTAIN	Nur schwaches Signal — untersuchen
NOT_REACHABLE	Keine Evidenz — aus der Alert-Queue unterdrücken

---

Schnellstart

Mit Docker Compose (empfohlen)

Sicherheitshinweis — kopieren Sie vor dem Start .env.example nach .env.local und ersetzen Sie jeden CHANGE_ME-Wert durch ein starkes zufälliges Secret.
Stellen Sie VulnReach nicht in einem öffentlichen Netzwerk bereit, ohne echte Anmeldedaten zu setzen und CORS_ORIGINS zu konfigurieren.

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

Einen Scan ausführen

Auth-Optionen:

• Kurzlebiges JWT: POST /login
• Langlebiger API-Token (API-Key): in der UI unter Settings -> API Keys erstellen, 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

• Erreichbarkeitsgefilterte SCA — klassifiziert jede CVE nach Evidenzstärke, nicht nur nach CVSS-Score
• Runtime-Bestätigung — Docker-basierte Coverage-Erfassung via coverage.py
• Taint-Tracking — verfolgt Benutzereingaben → verwundbare Sinks (SQL, subprocess, YAML, pickle)
• LLM-gesteuertes DAST — Claude/OpenAI/Ollama generiert und validiert Exploit-Payloads (optional)
• CI/CD-Gates — policy.block_if lässt Builds bei bestätigten kritischen Findings fehlschlagen; Auslösen und Gaten via curl — siehe docs/ci-cd-gating.md
• JWT-Auth — Multi-User, rollenbasierter Zugriff (Admin / Analyst)
• API-Tokens (API-Keys) — langlebige Maschinen-Auth für curl/CI (Authorization: Bearer <API_KEY>)
• PDF-Export — GET /scan/{id}/export/pdf
• Kein Vendor-Lock-in — LLM-Funktionen standardmäßig auf provider: none; Ollama für Offline-Nutzung unterstützt

---

In der Praxis

Scan-Ziel: multi-tier-dvpa — eine absichtlich verwundbare Python/Django-Anwendung mit 72 rohen CVEs über 11 Pakete.