VulnReach

SCA consciente del runtime: demuestra qué CVEs son realmente alcanzables, no solo instaladas.

VulnReach es ahora un Proyecto OWASP oficial. 🎉

Demo

Paso 1: el SCA detecta 74 CVEs en las dependencias

Paso 2: VulnReach demuestra cuáles son realmente alcanzables

Hallazgos: cadena de evidencia por CVE

Panel: 42 confirmados como alcanzables en 9 repos

Soporte de lenguajes: Python está totalmente listo para producción (taint, AST, rutas, runtime). Java y JavaScript tienen análisis de grafo de llamadas funcional y son experimentales. Go, C# y PHP están en la hoja de ruta. Consulta ROADMAP.md para más detalles.

VulnReach se basa en la salida estándar del SCA añadiendo contexto de alcanzabilidad: demuestra mediante análisis estático, seguimiento de taint y cobertura de runtime en vivo cuáles de los CVEs detectados pueden alcanzarse realmente en tu aplicación.

Estado del proyecto

Desarrollo más reciente (publicado)

• Pipeline de ejecución paralela consciente de dependencias para escaneos más rápidos
• Alcanzabilidad en Python: lista para producción (capas de taint, AST, rutas y runtime totalmente funcionales)
• Alcanzabilidad en Java: grafo de llamadas funcional con análisis de dependencias Maven/Gradle (experimental)
• Alcanzabilidad en JavaScript: grafo de llamadas funcional con detección de puntos de entrada por rutas (experimental)
• Cancelación de escaneos: POST /scan/{id}/cancel detiene escaneos en curso
• Contrato de respuesta de escaneo estable: summary + buckets clasificados en GET /scan/{id}
• Normalización compartida de la respuesta de escaneo entre la API y el modo local del paquete (paridad)
• Límite de runtime seguro por defecto:
  • el compose base se ejecuta sin montar el socket de Docker
  • los escaneos dinámicos requieren aceptación explícita mediante VULNREACH_ALLOW_DOCKER_DAEMON=true
  • el perfil de runtime usa docker-socket-proxy restringido
• Controles de calidad deterministas de fixtures para Java/JavaScript/Go en CI
• Aceptado como Proyecto OWASP oficial: owasp.community/projects/vulnreach
• Endpoint de próximos pasos con IA: POST /findings/{id}/next-steps produce orientación de remediación orientada a analistas (acciones inmediatas, sondas de validación, rutas de actualización, monitorización) para un hallazgo determinista. Perezoso / bajo demanda: los escaneos nunca llaman al LLM y los fallos del LLM degradan de forma controlada. El veredicto determinista es de solo lectura. Consulta .

Experimental

• Modo de trazado scan.runtime.ebpf (centrado en Linux, aceptación explícita)
• Generación de OpenAPI asistida por IA y flujos DAST inteligentes

Consulta:

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

Cómo funciona

Cada CVE se clasifica mediante una cadena de evidencia de cinco capas:

1. SCA (Trivy)              → ¿el paquete está instalado y es vulnerable?
2. Análisis de taint (tainter) → ¿el input del usuario fluye hacia el sink vulnerable?
3. Análisis AST             → ¿la función vulnerable está en tu grafo de llamadas?
4. Exposición de rutas      → ¿la ruta de llamada es alcanzable desde un endpoint HTTP?
5. Cobertura de runtime     → ¿el código vulnerable se ejecutó realmente?

El resultado es una lista de hallazgos priorizada con cuatro niveles:

Inicio rápido

Con Docker Compose (recomendado)

Aviso de seguridad: antes de empezar, copia .env.example a .env.local y reemplaza cada valor CHANGE_ME con un secreto aleatorio seguro.
No expongas VulnReach en una red pública sin establecer credenciales reales y configurar CORS_ORIGINS.

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

# 1. Crea tu configuración local
cp .env.example .env.local

# 2. Rellena cada CHANGE_ME: genera secretos con: openssl rand -hex 32
$EDITOR .env.local

# 3. Inicia la pila
docker compose up --build

# Opcional: habilita escaneos de runtime dinámicos (acceso al daemon de Docker mediante proxy de socket restringido)
# docker compose -f docker-compose.yml -f docker-compose.runtime.yml up --build

Ejecutar un escaneo

Opciones de autenticación:

• JWT de corta duración: POST /login
• Token de API de larga duración (API key): créalo en la interfaz Settings -> API Keys y úsalo como Authorization: Bearer <API_KEY>

# Obtén un token (reemplaza con las credenciales que configuraste en .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)

# Inicia el escaneo desde un repositorio de GitHub
curl -X POST http://localhost:8000/scan \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"repo_url":"https://github.com/yourorg/yourapp"}'

# Consulta los resultados
curl http://localhost:8000/scan/<scan_id> \
  -H "Authorization: Bearer $TOKEN" | jq .summary

Características

• SCA filtrado por alcanzabilidad: clasifica cada CVE según la fuerza de la evidencia, no solo la puntuación CVSS
• Confirmación en runtime: recopilación de cobertura basada en Docker mediante coverage.py
• Seguimiento de taint: rastrea el input del usuario hasta los sinks vulnerables (SQL, subprocess, YAML, pickle)
• DAST dirigido por LLM: Claude/OpenAI/Ollama generan y validan payloads de explotación (opcional)
• Compuertas CI/CD: policy.block_if hace fallar las builds ante hallazgos críticos confirmados
• Autenticación JWT: multiusuario, acceso basado en roles (admin / analista)
• Tokens de API (API keys): autenticación de máquina de larga duración para curl/CI (Authorization: Bearer <API_KEY>)
• Exportación PDF: GET /scan/{id}/export/pdf
• Sin dependencia de proveedor: las funciones de LLM usan provider: none por defecto; Ollama es compatible para uso sin conexión

En la práctica

Objetivo del escaneo: multi-tier-dvpa, una aplicación Python/Django intencionalmente vulnerable con 72 CVEs brutos en 11 paquetes.

El 46 % de los hallazgos se sacó de la cola indiferenciada de "corregir todo" y se trasladó a una lista de acciones priorizada. En un servicio de producción típico (donde muchas dependencias transitivas nunca se invocan), esta cifra asciende al 70–90 %.

Metodología completa, detalle de la cadena de evidencia y desglose por paquete: docs/benchmark.md

Documentación

Uso

• USAGE_PACKAGE.md: instalación del paquete/CLI, dependencias, inicio y uso
• USAGE_UI.md: instalación de la UI/servidor, dependencias, inicio y uso

Operadores / Despliegue

• docs/deployment.md: configuración de Docker Compose, variables de entorno, notas de producción
• docs/configuration.md: referencia completa de configuración de scan.yml
• docs/api.md: endpoints REST y esquemas

Arquitectura / Seguridad

• docs/architecture.md: diseño del pipeline y modelo de ejecución
• docs/threat-model.md: límites de confianza, STRIDE, casos de abuso
• docs/incubator-readiness.md: estado de preparación para OSS/OWASP
• docs/DAST.md: conceptos y flujo de DAST

Colaboradores

• ROADMAP.md: características planificadas, limitaciones conocidas, estado de soporte de lenguajes
• docs/development.md: internals, agentes, almacenamiento, puntos de extensión
• OWASP.md: notas del proyecto OWASP
• SECURITY.md: divulgación de vulnerabilidades y rotación de claves
• CONTRIBUTING.md: proceso de contribución
• CHANGELOG.md: historial de versiones

Requisitos

• Python 3.11+
• PostgreSQL 13+
• Docker + Docker Compose v2 (para análisis dinámico)
• trivy en PATH (instalación)
• jq (usado en los ejemplos de inicio rápido: instalación)

Opcionales (todos se omiten con elegancia si no están presentes):

• semgrep: pip install semgrep
• tainter: pip install tainter (análisis de flujo taint; consulta la guía de desarrollo)

Licencia

Apache 2.0: consulta LICENSE.