VulnReach

SCA consapevole del runtime — dimostra quali CVE sono effettivamente raggiungibili, non solo installate.

VulnReach è ora un Progetto OWASP ufficiale. 🎉

Demo

Passo 1 — Lo SCA evidenzia 74 CVE tra le dipendenze

Passo 2 — VulnReach dimostra quali sono effettivamente raggiungibili

---

Riscontri — catena di prove per ogni CVE

Dashboard — 42 raggiungibili confermate su 9 repo

Supporto linguistico: Python è completamente pronto per la produzione (taint, AST, route, runtime). Java e JavaScript hanno analisi funzionale del call graph e sono sperimentali. Go, C# e PHP sono nella roadmap. Vedi ROADMAP.md per i dettagli.

VulnReach si basa sull'output SCA standard aggiungendo il contesto di raggiungibilità — dimostrando tramite analisi statica, taint tracking e copertura runtime live quali delle CVE rilevate possono essere effettivamente raggiunte nella tua applicazione.

---

Stato del Progetto

Sviluppi Recenti (rilasciati)

• Pipeline di esecuzione parallela consapevole delle dipendenze per scansioni più rapide
• Raggiungibilità Python — pronta per la produzione (layer taint, AST, route e runtime tutti funzionanti)
• Raggiungibilità Java — call graph funzionale con parsing delle dipendenze Maven/Gradle (sperimentale)
• Raggiungibilità JavaScript — call graph funzionale con rilevamento dei punti di ingresso delle route (sperimentale)
• Cancellazione delle scansioni — POST /scan/{id}/cancel interrompe le scansioni in corso
• Contratto di risposta delle scansioni stabile: summary + bucket classificati su GET /scan/{id}
• Normalizzazione condivisa della risposta delle scansioni tra API e modalità pacchetto locale (parità)
• Boundary runtime sicuro per default:
  • il compose base viene eseguito senza montaggio del socket Docker
  • le scansioni dinamiche richiedono un opt-in esplicito tramite VULNREACH_ALLOW_DOCKER_DAEMON=true
  • il profilo runtime usa docker-socket-proxy con restrizioni
• Quality gate deterministici sui fixture per Java/JavaScript/Go in CI
• Accettato come Progetto OWASP ufficiale — owasp.community/projects/vulnreach
• Endpoint AI per i passi successivi — POST /findings/{id}/next-steps produce indicazioni di remediation orientate all'analista (azioni immediate, probe di validazione, percorsi di aggiornamento, monitoraggio) per un riscontro deterministico. Lazy / on-demand: le scansioni non chiamano mai l'LLM e i fallimenti dell'LLM degradano con grazia. Il verdetto deterministico è in sola lettura. Vedi docs/api.md.

Sperimentale

• Modalità di tracing scan.runtime.ebpf (focalizzata su Linux, opt-in esplicito)
• Generazione OpenAPI assistita da IA e flussi DAST intelligenti

Vedi:

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

---

Come funziona

Ogni CVE viene classificata attraverso una catena di prove a cinque livelli:

1. SCA (Trivy)              → il pacchetto è installato e vulnerabile?
2. Analisi taint (tainter) → l'input utente fluisce verso il sink vulnerabile?
3. Analisi AST             → la funzione vulnerabile è nel tuo call graph?
4. Esposizione della route → il percorso di chiamata è raggiungibile da un endpoint HTTP?
5. Copertura runtime       → il codice vulnerabile è stato effettivamente eseguito?

Il risultato è un elenco di riscontri prioritizzati con quattro livelli:

Livello	Significato
DYNAMICALLY_REACHABLE	La copertura runtime ha confermato l'esecuzione — correggi subito
STATICALLY_REACHABLE	Percorso del codice dimostrato tramite AST/taint — priorità alta
UNCERTAIN	Solo segnale debole — investiga
NOT_REACHABLE	Nessuna evidenza — sopprimi dalla coda di alert

---

Avvio rapido

Con Docker Compose (consigliato)

Nota di sicurezza — prima di iniziare, copia .env.example in .env.local e sostituisci ogni valore CHANGE_ME con un segreto casuale robusto.
Non esporre VulnReach su una rete pubblica senza impostare credenziali reali e configurare CORS_ORIGINS.

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

# 1. Crea la tua configurazione locale
cp .env.example .env.local

# 2. Compila ogni CHANGE_ME — genera i segreti con: openssl rand -hex 32
$EDITOR .env.local

# 3. Avvia lo stack
docker compose up --build

# Opzionale: abilita le scansioni runtime dinamiche (accesso al daemon Docker tramite socket proxy limitato)
# docker compose -f docker-compose.yml -f docker-compose.runtime.yml up --build

Esegui una scansione

Opzioni di autenticazione:

• JWT a breve durata: POST /login
• Token API a lunga durata (API key): crealo nella UI Settings -> API Keys, poi usalo come Authorization: Bearer <API_KEY>

# Ottieni un token (sostituisci con le credenziali impostate in .env.local)
TOKEN=$(curl -s -X POST http://localhost:8000/login \
  -H "Content-Type: application/json" \
  -d '{"username":"<tuo-admin-user>","password":"<tua-admin-password>"}' | jq -r .access_token)

# Avvia la scansione da una repo GitHub
curl -X POST http://localhost:8000/scan \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"repo_url":"https://github.com/tuaorg/tuaapp"}'

# Interroga i risultati
curl http://localhost:8000/scan/<scan_id> \
  -H "Authorization: Bearer $TOKEN" | jq .summary

---

Caratteristiche

• SCA filtrato per raggiungibilità — classifica ogni CVE in base alla forza delle evidenze, non solo al punteggio CVSS
• Conferma runtime — raccolta della copertura basata su Docker tramite coverage.py
• Taint tracking — traccia input utente → sink vulnerabili (SQL, subprocess, YAML, pickle)
• DAST guidato da LLM — Claude/OpenAI/Ollama genera e valida payload di exploit (opzionale)
• Gate CI/CD — policy.block_if fa fallire le build su riscontri critici confermati
• Autenticazione JWT — multiutente, accesso basato sui ruoli (admin / analyst)
• Token API (API key) — autenticazione macchina a lunga durata per curl/CI (Authorization: Bearer <API_KEY>)
• Esportazione PDF — GET /scan/{id}/export/pdf
• Nessun vendor lock-in — le funzionalità LLM predefiniscono provider: none; Ollama supportato per l'uso offline

---

Nella pratica