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 docs/api.md.

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:

Stufe	Bedeutung
DYNAMICALLY_REACHABLE	Ausführung durch Laufzeitabdeckung bestätigt – sofort beheben
STATICALLY_REACHABLE	Codepfad über AST/Taint nachgewiesen – hohe Priorität
UNCERTAIN	Nur schwaches Signal – untersuchen
NOT_REACHABLE	Keine Evidenz – aus der Alarmwarteschlange entfernen

---

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