Evidencia primero de pruebas autónomas de seguridad web para objetivos controlados y autorizados. Con laboratorios reproducibles, pistas de auditoría, informes y evaluación comparativa XBEN.
Ravage es una CLI basada en evidencia para evaluar una aplicación web en ejecución que posees o para la que tienes autorización explícita de prueba. Combina reconocimiento y validación deterministas con un bucle de ataque opcional guiado por modelos, manteniendo el alcance, la autenticación, el registro de tráfico y la evidencia dentro de límites controlados por código.
Ravage es un alfa de investigación previa a la versión 1.0. Usa entornos desechables y un acuerdo de reglas de enfrentamiento por escrito. Las pruebas de seguridad pueden cambiar el estado de la aplicación; Ravage no corrige hallazgos ni implementa soluciones.
Inicio rápido · Autenticación · Resultados · Capacidades · Documentación
El primer escaneo normal no necesita clave de modelo, navegador, demonio de Docker ni escáner externo.
git clone https://github.com/duriantaco/ravage.git
cd ravage
scripts/bootstrap.sh
source .venv/bin/activate
ravage doctor
El bootstrap crea .venv e instala el espacio de trabajo. Usa
scripts/bootstrap.sh --dev para dependencias de desarrollo,
--browser para soporte de navegador, o
--install-browser para instalar también Chromium.
Inicia tu aplicación primero. Este ejemplo asume que está escuchando en
http://127.0.0.1:3000.
Crea un informe de compromiso con alcance y un archivo de entorno privado:
ravage init http://127.0.0.1:3000 \
--brief ravage-brief.yaml \
--env-file .env.ravage \
--description "Evaluación autorizada de mi aplicación de desarrollo local."
Revisa ravage-brief.yaml. Verifica el objetivo, las rutas dentro del alcance,
las exclusiones, el presupuesto de solicitudes, el límite de velocidad, los objetivos y los criterios de éxito.
Ejecuta un escaneo de superficie sin modelo:
ravage doctor --workflow scan --brief ravage-brief.yaml
ravage scan ravage-brief.yaml --probe surface_map --report
El comando imprime el directorio de ejecución. Copia esa ruta y úsala como
RUN_DIR en los comandos de inspección a continuación.
Agrega una clave de proveedor compatible, como OPENAI_API_KEY, a
.env.ravage. Ravage lee este archivo directamente; no lo cargues desde el shell.
ravage doctor --workflow attack --brief ravage-brief.yaml
ravage attack ravage-brief.yaml --allow-paid-models --report
--allow-paid-models es un reconocimiento explícito de que la ejecución
puede generar cargos del proveedor. La selección de modelos, los proveedores locales y los perfiles
reproducibles están documentados en Proveedores de modelos.
Agrega una identidad de prueba dedicada al informe:
ravage auth add ravage-brief.yaml \
--identity user \
--type form \
--login /login \
--health /account \
--marker Logout \
--env-file .env.ravage
Completa las referencias de secretos generadas, verifica la sesión y luego ataca con la identidad seleccionada:
ravage auth check ravage-brief.yaml --identity user
ravage attack ravage-brief.yaml \
--identity user \
--allow-paid-models \
--report
Se admiten inicio de sesión por formulario, tokens de portador y encabezados estáticos fijos. Las credenciales gestionadas permanecen dentro del propietario HTTP autenticado; los canales de proceso, Python y comandos están bloqueados cuando se selecciona una identidad. Consulta Autenticación para la configuración y las limitaciones.
La ejecución remota es de cierre seguro ante fallos y requiere una bandera explícita. Comienza con un escaneo de superficie de bajo impacto:
ravage init https://staging.example.test \
--brief ravage-brief.yaml \
--env-file .env.ravage \
--description "Evaluación autorizada de mi aplicación de staging."
ravage doctor --workflow scan \
--brief ravage-brief.yaml \
--authorized-remote-target
ravage scan ravage-brief.yaml \
--probe surface_map \
--authorized-remote-target \
--report
Para una ejecución remota guiada por modelos:
ravage attack ravage-brief.yaml \
--authorized-remote-target \
--allow-paid-models \
--report
Los ataques remotos autorizados usan por defecto la política de bajo ruido para toda la ejecución: HTTP nativo medido únicamente, ritmo inferior a 1 RPS, un límite físico de solicitudes, almacenamiento en caché y deduplicación conservadores de GET/HEAD, retroceso adaptativo, reintentos limitados y corte de circuito. El registro duradero sobrevive a la reanudación. Los detalles están en Arquitectura.
Ravage distingue observaciones, hallazgos candidatos y vulnerabilidades confirmadas. Una bandera CTF es una posible prueba, no un requisito. En una aplicación ordinaria, una ejecución puede ser útil y exitosa sin encontrar ninguna bandera; las vulnerabilidades confirmadas aún se escriben en el informe.
Una vez que comienza una ejecución de ataque, su artefacto canónico privado legible por máquina es
RUN_DIR/report.json, incluidas las ejecuciones incompletas.
--report también escribe RUN_DIR/report.md.
ravage observe RUN_DIR
ravage audit verify RUN_DIR
ravage report RUN_DIR --brief ravage-brief.yaml
Para HTTP estructurado capturado por el grafo del agente:
ravage traffic list RUN_DIR
ravage traffic show RUN_DIR REQUEST_ID
El informe incluye referencias de evidencia, calidad del registro de solicitudes, estado de finalización y la razón por la que se detuvo una ejecución incompleta. Nunca trates una afirmación de modelo no validada como un hallazgo confirmado.
Las habilidades de conocimiento pueden guiar la priorización, pero no pueden agregar herramientas, ampliar el alcance ni confirmar hallazgos. Comienza con:
ravage skills list builtin
ravage skills validate builtin
El Laboratorio de mejora ingiere la estructura de ejecuciones anteriores saneada, evalúa parches candidatos en espacios de trabajo independientes, archiva versiones aceptadas y rechazadas, y requiere evidencia de no regresión coincidente antes de la promoción. Es un componente auxiliar: no muta el checkout del código fuente ni se promueve silenciosamente.
Los artefactos pasivos orbitales y de paquetes se pueden inspeccionar por separado:
ravage satcom inspect orbit.tle --format tle --output orbit-report.json
ravage satcom inspect capture.bin \
--format ccsds-space-packets \
--direction auto \
--output packet-report.json
El soporte SATCOM es análisis y parseo pasivo, no un transmisor de radio ni un sistema de control de naves espaciales.
scripts/bootstrap.sh --dev
source .venv/bin/activate
python -m pytest -m "not integration" -q
python -m ruff check --select E9,F .
python scripts/qa/check_docs.py
python scripts/qa/check_release.py
Las pruebas de integración respaldadas por Docker y las comparaciones XBEN congeladas son compuertas de lanzamiento separadas. Lee Evaluación comparativa antes de interpretar los resultados de casos; una bandera afortunada no es evidencia de una mejora confiable.
Usa ravage --help y ravage COMMAND --help para las
opciones exactas en tu checkout.
Licencia Apache 2.0. Consulta LICENSE, DISCLAIMER y SECURITY.md.
| Capacidad | Punto de entrada | Notas |
|---|
| Reconocimiento y sondas deterministas | ravage scan | No requiere modelo |
| Evaluación guiada por modelos | ravage attack | Limitada por evidencia y alcance |
| Autenticación gestionada | ravage auth | Formulario, portador, encabezado estático |
| Inspección y reproducción de tráfico | ravage traffic | Artefactos con alcance |
| Habilidades de conocimiento | ravage skills, ravage code-bug | Consultivo |
| Inspección pasiva SATCOM | ravage satcom inspect | Sin transmisión |
| Evaluación XBEN | ravage xben | Entorno de investigación basado en Docker |
| Laboratorio de mejora | scripts/improvement_lab.py | Archivo aislado |