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 .

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:

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

Target di scansione: multi-tier-dvpa — un'applicazione Python/Django intenzionalmente vulnerabile con 72 CVE grezze su 11 pacchetti.

Il 46% dei riscontri è stato spostato fuori dalla coda indifferenziata "correggi tutto" in un elenco di azioni prioritizzate. In un tipico servizio di produzione (dove molte dipendenze transitive non vengono mai chiamate), questa cifra sale al 70–90%.

Metodologia completa, dettaglio della catena di prove e ripartizione a livello di pacchetto: docs/benchmark.md

Documentazione

Utilizzo

• USAGE_PACKAGE.md — installazione pacchetto/CLI, dipendenze, avvio, utilizzo
• USAGE_UI.md — installazione UI/server, dipendenze, avvio, utilizzo

Operatori / Deployer

• docs/deployment.md — configurazione Docker Compose, variabili d'ambiente, note di produzione
• docs/configuration.md — riferimento completo alla configurazione scan.yml
• docs/api.md — endpoint REST e schemi

Architettura / Sicurezza

• docs/architecture.md — progettazione della pipeline e modello di esecuzione
• docs/threat-model.md — trust boundary, STRIDE, casi di abuso
• docs/incubator-readiness.md — stato di preparazione OSS/OWASP
• docs/DAST.md — concetti e flusso DAST

Contributori

• ROADMAP.md — funzionalità pianificate, limitazioni note, stato del supporto linguistico
• docs/development.md — dettagli interni, agenti, storage, punti di estensione
• OWASP.md — note sul progetto OWASP
• SECURITY.md — divulgazione delle vulnerabilità e rotazione delle chiavi
• CONTRIBUTING.md — processo di contribuzione
• CHANGELOG.md — cronologia delle release

Requisiti

• Python 3.11+
• PostgreSQL 13+
• Docker + Docker Compose v2 (per l'analisi dinamica)
• trivy nel PATH (installazione)
• jq (usato negli esempi di avvio rapido — installazione)

Opzionali (tutti vengono saltati con grazia se assenti):

• semgrep — pip install semgrep
• tainter — pip install tainter (analisi del flusso taint; vedi guida allo sviluppo)

Licenza

Apache 2.0 — vedi LICENSE.