VulnReach

SCA runtime-aware — dimostra quali CVE sono effettivamente raggiungibili, non solo installati.

VulnReach è ora un OWASP Project ufficiale. 🎉

Demo

Passo 1 — SCA rileva 74 CVE tra le dipendenze

Passo 2 — VulnReach dimostra quali sono effettivamente raggiungibili

---

Risultati — catena di evidenze per CVE

Dashboard — 42 confermati raggiungibili su 9 repository

Supporto linguaggi: Python è completamente pronto per la produzione (taint, AST, route, runtime). Java e JavaScript dispongono di analisi funzionale del call graph e sono sperimentali. Go, C# e PHP sono nella roadmap. Consulta 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 effettivamente essere raggiunte nella tua applicazione.

---

Stato del progetto

Ultimi sviluppi (rilasciati)

• Pipeline di esecuzione parallela consapevole delle dipendenze per scansioni più rapide
• Raggiungibilità Python — pronta per la produzione (livelli taint, AST, route, runtime tutti funzionali)
• Raggiungibilità Java — call graph funzionale con parsing delle dipendenze Maven/Gradle (sperimentale)
• Raggiungibilità JavaScript — call graph funzionale con rilevamento degli entry point delle route (sperimentale)
• Annullamento della scansione — POST /scan/{id}/cancel interrompe le scansioni in corso
• Contratto di risposta di scansione stabile: summary + bucket classificati su GET /scan/{id}
• Normalizzazione condivisa della risposta di scansione tra API e modalità locale del pacchetto (parità)
• Confine runtime sicuro per impostazione predefinita:
  • il compose base viene eseguito senza mount del socket Docker
  • le scansioni dinamiche richiedono opt-in esplicito tramite VULNREACH_ALLOW_DOCKER_DAEMON=true
  • il profilo runtime utilizza un docker-socket-proxy ristretto
• Quality gate deterministici sui fixture per Java/JavaScript/Go in CI
• Accettato come OWASP Project ufficiale — owasp.community/projects/vulnreach
• Endpoint AI next-steps — POST /findings/{id}/next-steps produce indicazioni di remediation per l'analista (azioni immediate, probe di validazione, percorsi di aggiornamento, monitoraggio) per un finding deterministico. Lazy / on-demand: le scansioni non chiamano mai l'LLM e i fallimenti dell'LLM degradano in modo controllato. Il verdetto deterministico è di sola lettura. Consulta docs/api.md.

Sperimentale

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

Consulta:

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

---

Come funziona

Ogni CVE viene classificata attraverso una catena di evidenze 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 route        → il percorso di chiamata è raggiungibile da un endpoint HTTP?
5. Copertura runtime        → il codice vulnerabile è stato effettivamente eseguito?

Il risultato è una lista di finding prioritizzata con quattro livelli:

Livello	Significato
DYNAMICALLY_REACHABLE	La copertura runtime ha confermato l'esecuzione — correggi immediatamente
STATICALLY_REACHABLE	Percorso di codice dimostrato tramite AST/taint — alta priorità
UNCERTAIN	Solo segnale debole — da investigare
NOT_REACHABLE	Nessuna evidenza — sopprimi dalla coda degli avvisi

---

Avvio rapido

Con Docker Compose (consigliato)

Avviso 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 aver impostato credenziali reali e configurato CORS_ORIGINS.

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

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>

# 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

---

Funzionalità