Anunciamos ExploitHunter.app
Un entorno de trabajo de seguridad de código abierto que mantiene el alcance, las aprobaciones, las herramientas y las pruebas en un solo proyecto.
Tabla de contenidos
- El ciclo es deliberadamente aburrido
- La evidencia es el producto
- Ocho modelos, un objetivo
- El benchmark detectó el benchmark
- Enruta los modelos según la tarea
- Dónde encaja junto a deepsec, VulnHunter y compañía
- Ejecútalo en local. Úsalo con responsabilidad.
- Qué viene después
Las herramientas de seguridad tienen un problema de papeleo.
Encuentran una línea sospechosa, te entregan una etiqueta de gravedad y después te dejan demostrar discretamente si importa. El hallazgo es «alto». La evidencia son tres grep con una gabardina puesta.
Los agentes de IA pueden acortar ese flujo. También pueden convertir una instrucción vaga, un navegador y un shell en un montón mucho más rápido de actividad no verificada.
ExploitHunter.app empieza donde termina el escáner. Dale un objetivo autorizado y una meta. El agente identifica las rutas accesibles, maneja un navegador, ejecuta herramientas de terminal y de seguridad, comprueba una hipótesis y guarda las respuestas, capturas de pantalla y transcripciones que respaldan el hallazgo. Después convierte esa evidencia en un informe con citas.
Es de código abierto y local-first. Puedes alternar entre modelos alojados y locales sin repartir el objetivo, las aprobaciones, el historial y la evidencia entre proyectos separados.
No es un escáner con un chatbot pegado encima. Es un banco de trabajo que recuerda qué intentó el agente y qué obtuvo a cambio.
Hablar de seguridad sale barato. Lo útil es ejecutar la comprobación autorizada, conservar las pruebas y entregarte el siguiente paso.
El ciclo es deliberadamente aburrido
Un proyecto de ExploitHunter recorre la misma secuencia cada vez:
authorize target → plan → request approval → probe → save evidence → prioritize → report
El orden importa porque el agente tiene alcance real.
La autorización del objetivo forma parte del estado del proyecto, no del contexto conversacional. No vive en un mensaje de chat donde «sí, adelante» pueda adquirir nuevos significados tres turnos después. Los escaneos activos, las pruebas de credenciales, los comandos de shell y las escrituras de archivos están todos detrás de una compuerta de aprobación. Las aprobaciones de comandos de alto impacto están vinculadas a una intención, un proyecto y un objetivo. De forma predeterminada, solo pueden usarse una vez.
Las compuertas de aprobación no son letra pequeña debajo del discurso del producto. Son lo que hace razonable conectar un agente con herramientas reales. Limitan la deriva de alcance, hacen que las revisiones dependan menos de la memoria y le dan al equipo algo mejor que «lo dijo la IA».
La evidencia es el producto
La respuesta final del modelo no es la unidad duradera del trabajo de seguridad. La evidencia sí.
Cierra la aplicación. Cambia de modelo. Vuelve mañana. La investigación sigue teniendo memoria.
ExploitHunter conserva el historial de proyectos e hilos, pero el registro duradero es el flujo de evidencia: qué se probó, con qué aprobación, contra qué objetivo autorizado y qué respuesta se obtuvo. La sonda, la respuesta, la transcripción de comandos, la captura de pantalla y el artefacto de respaldo se almacenan junto con el hallazgo. El informe cita el trabajo en lugar de parafrasear el párrafo final del modelo.
Después, los hallazgos pueden alimentar el seguimiento de la remediación, el análisis de variantes, el trabajo sobre rutas de ataque y un informe que un revisor pueda comprobar línea por línea.
También hay un beneficio egoísta: depurar deja de ser algo místico. Cuando el agente pasa algo por alto, abusa de las herramientas, se inventa una conclusión o no guarda un artefacto, el fallo queda visible en el registro. Corregimos el producto en lugar de discutir con una captura de una burbuja de chat.
Ocho modelos, un objetivo
Como cada ejecución deja un registro, comparar modelos deja de ser un ejercicio basado en impresiones.
Di a ocho rutas de modelo la misma tarea difícil de Juice Shop y las ejecuté a través del flujo real de la aplicación de ExploitHunter. Mismo objetivo. Mismas herramientas. Mismo contrato de evidencia. Si una ejecución no podía demostrar qué modelo se había ejecutado o no podía conservar su salida, no obtenía una fila. A los benchmarks puede gustarles la ambigüedad. A las facturas, rara vez.
| Ruta del modelo | Juez | Coste | Tiempo de ejecución | Llamadas a herramientas | Lectura | |---|---:|---:|---:|---:|---| | Kimi K3 | 10.0/10 | $0.220184 | 223.4s | 8.0 | La mayor calidad al menor precio de los dos modelos con puntuación perfecta | | Claude Opus 4.8 | 10.0/10 | $1.633301 | 115.9s | 8.0 | La misma calidad que Kimi, casi el doble de rápido y con un coste 7,4 veces mayor | | DeepSeek V4 Flash | 9.33/10 | $0.058695 | 395.5s | 32.0 | La mejor puntuación entre las dos rutas que no fueron perfectas | | GPT-5.6 Luna | 8.67/10 | $0.016304 | 52.2s | 3.3 | El mejor resultado en coste y velocidad | | GPT-5.6 Terra | 8.0/10 | $0.124046 | 107.5s | 6.0 | Supera a Sol en precio y velocidad con la misma puntuación | | GPT-5.6 Sol | 8.0/10 | $0.368514 | 229.6s | 10.0 | Capaz, pero Terra lo domina en este corte | | Qwen 3.6 Flash | 5.5/10 | $0.085678 | 96.9s | 16.5 | El ajuste más barato mejoró la eficiencia, pero la calidad sigue por detrás | | GPT OSS 120B | 5.0/10 | $0.062529 | 36.6s | 4.3 | Rápido y barato, pero demasiado volátil para ser la ruta predeterminada |
Léelo como una política de enrutamiento, no como un podio.
Luna es el punto de partida eficiente. DeepSeek compra otros dos tercios de punto del juez por aproximadamente 3,6 veces el coste, 7,6 veces el tiempo de ejecución y 9,6 veces las llamadas a herramientas. Kimi llega a 10/10 sin pagar la factura de Opus. Opus alcanza la misma puntuación unos 108 segundos antes por $1.41 adicionales. GPT OSS sigue siendo un experimento supervisado, y Terra presenta un caso más sólido que Sol en esta tarea.
Solo Luna, DeepSeek y Kimi están en esa frontera. Las demás rutas no son inútiles. Necesitan una justificación que vaya más allá de la puntuación bruta y el coste: Opus compra velocidad, Terra satisface una restricción de familia de modelos sin pagar la factura de Sol, y GPT OSS es lo bastante barato como para explorarlo bajo supervisión.
La versión larga, con la metodología, los presupuestos de herramientas, los controles negativos y las formas en que los modelos hacen el ridículo cuando la respuesta ya está en una transcripción de comandos, está en Los agentes de seguridad necesitan enrutadores de modelos, no rankings de modelos.
El benchmark detectó el benchmark
El resultado más importante no fue una victoria de un modelo. Fue un fallo del evaluador.
El primer informe de recuperación del archivo dio a Kimi 5/10 y a GLM 9/10. La tarea había salido bien. Ambos agentes recuperaron harbor-lantern-47, y una comprobación independiente en el host con unzip -t -P demostró que esa contraseña funcionaba y que las alternativas no.
El juez había aplicado una auditoría de herramientas prohibidas de Raw-Cybench a una tarea nativa de ExploitHunter en la que era obligatorio guardar evidencias. Penalizó exactamente el comportamiento que el harness exigía. Misma salida del modelo. Misma traza almacenada. Rúbrica equivocada.
Al eliminar la auditoría irrelevante, Kimi pasa de 5/10 a 10/10. GLM se mantiene en 9/10. Las puntuaciones corregidas se escribieron de vuelta en las trazas originales de Langfuse como browser-e2e-llm-judge-corrected, y una comprobación de solo lectura de la API, realizada el 17 de julio, confirmó ambos valores en los ID de traza persistidos.
Ese salto de cinco puntos explica por qué ExploitHunter almacena trazas, evidencias, versiones del evaluador, costes, tokens, presupuestos de herramientas y fallos del harness, en lugar de reducir una evaluación a una única cifra heroica. Si el benchmark no puede mostrar su trabajo, no es más que otro modelo haciendo una afirmación con demasiada seguridad.
Enruta los modelos según la tarea
ExploitHunter no se limita a admitir una lista larga de proveedores de modelos. Los trata como un banquillo.
Una pasada de reconocimiento, una comprobación de explotación, un flujo en el navegador, la síntesis de evidencias y una propuesta de corrección son tareas de seguridad. No son la misma tarea para un modelo.
VulnHunter de Capital One apuesta de forma coherente por un flujo de análisis de código optimizado para Claude/Claude Code. ExploitHunter apuesta por otra cosa: mantener estables el alcance del proyecto, las aprobaciones, las herramientas y las evidencias, mientras la ruta del modelo cambia según el trabajo.
Un reconocimiento web amplio puede beneficiarse de un modelo barato y rápido, con un presupuesto de herramientas ajustado. Un laboratorio local restringido puede favorecer la privacidad y la inferencia sin conexión. Una validación difícil o un informe final pueden justificar una ruta de frontera más lenta. ExploitHunter mueve el trabajo entre esos carriles mientras el objetivo, el historial, las aprobaciones, las herramientas y los artefactos permanecen en su sitio.
El modelo adecuado es una decisión de enrutamiento, no un logotipo en una pantalla de configuración.
ExploitHunter admite proveedores alojados, además de Ollama y LM Studio. Puedes ejecutarlo como servicio local de Node o como aplicación de escritorio Electron. Deja vacías las claves de API alojadas y un modelo local compatible mantendrá el trabajo candidato fuera de los proveedores de pago. Usa una ruta alojada cuando la velocidad o un problema más difícil lo justifiquen. Mantén el trabajo sensible en local cuando ese límite importe más que ahorrar unos segundos por ejecución.
No hay ninguna victoria moral en enviar cada tarea de seguridad al modelo más caro disponible. Solo hay una factura.
Dónde encaja junto a deepsec, VulnHunter y compañía
ExploitHunter es deliberadamente más amplio que un harness de análisis de código. Toma un candidato, lo lleva hasta un objetivo en ejecución, lo investiga con herramientas de navegador y terminal, conserva las pruebas y después entrega un hallazgo verificado al sistema que debería corregirlo.
Varios proyectos cubren ahora distintas partes de ese flujo. Bien. Los equipos de seguridad necesitan herramientas que se pasen el trabajo unas a otras, no otra categoría de ganador único.
| Herramienta | En qué destaca | En qué se diferencia ExploitHunter | |---|---|---| | Vercel deepsec | Un harness centrado en el código: descubrimiento estático de candidatos, investigación con agentes de programación, revalidación, enriquecimiento y distribución opcional a gran escala en sandboxes. | Deepsec encaja en el análisis de repositorios y el seguimiento orientado a pull requests. ExploitHunter pone en el centro un proyecto de investigación autorizado que puede incluir una aplicación en ejecución, un navegador, un laboratorio de red, una terminal, evidencias persistentes y aprobaciones explícitas del operador. | | Capital One VulnHunter | Análisis del código desde la perspectiva del atacante, falsación estructurada de hallazgos y propuestas centradas de corrección del código. | El solapamiento es real: las evidencias y la reducción de falsos positivos deberían ser requisitos básicos. ExploitHunter está menos atado a un harness de programación o a una única ruta de modelo, y se centra más en coordinar la investigación antes de proponer un cambio de código. | | GitHub Security Lab Taskflow Agent | Flujos declarativos habilitados para MCP, especialmente la clasificación de alertas de CodeQL y el análisis de variantes. GitHub afirma que ha ayudado a encontrar aproximadamente 30 vulnerabilidades reales. | Es la base adecuada cuando la entrada es un flujo repetible de análisis de código. ExploitHunter es el banco de trabajo para investigaciones exploratorias que usan herramientas, donde el alcance, las aprobaciones y las evidencias deben sobrevivir a una investigación más larga. | | OpenHands Vulnerability Fixer | Convertir la salida de Trivy u otras herramientas en correcciones priorizadas, pruebas y pull requests. | Una fábrica de correcciones. ExploitHunter está antes en el ciclo: establecer que el hallazgo es real, registrar por qué y entregar un problema bien respaldado al sistema de corrección. | | Assay | Aplicación de políticas sin conexión, repetición determinista y paquetes de evidencias criptográficas para llamadas de herramientas de agentes. | Complementario, no un competidor. Es el tipo de control de ejecución con denegación predeterminada que los espacios de trabajo de investigación agéntica deberían poder utilizar por debajo de su propia capa de aprobación. |
Una pila útil probablemente incluya más de uno de estos componentes: un escáner de código plantea candidatos, un taskflow clasifica patrones recurrentes, un espacio de investigación verifica los casos peligrosos y un agente de corrección convierte el trabajo verificado en un parche revisable. Las transferencias importan más que coronar una mascota de la seguridad.
Ejecútalo en local. Úsalo con responsabilidad.
ExploitHunter tiene licencia MIT, es de código abierto y está pensado para realizar trabajo que tienes autorización para ejecutar. El repositorio incluye un objetivo local de Juice Shop reforzado y laboratorios de red multiservicio, para que puedas ejercitar el flujo completo sin apuntar un agente a algo que no te pertenece.
git clone https://github.com/justsml/ExploitHunter.app.git
cd ExploitHunter.app
pnpm install
cp .env.example .env
pnpm dev
Después, abre http://localhost:3210.
Elige una ruta de modelo, autoriza un objetivo que te pertenezca o que tengas permiso explícito para probar y dale al agente un objetivo. Deja que planifique el trabajo, aprueba las acciones que realmente pretendes ejecutar y observa cómo se acumulan las pruebas en lugar de desaparecer en el historial del chat.
Esa es la versión aburrida de la seguridad agéntica.
También es la versión que quiero de mi lado cuando empiece la parte interesante.
Qué viene después
El próximo trabajo no consiste en hacer una afirmación más grande sobre el hacking autónomo. Consiste en volver más fiable el ciclo de investigación: mejores informes de ejecuciones repetidas, validación más estricta de las pruebas, mayor cobertura de modelos locales, visibilidad más clara de las aprobaciones y un camino más rápido desde un hallazgo verificado hasta un parche que una persona quiera integrar.
Los agentes de seguridad no necesitan espacio ilimitado para improvisar. Necesitan alcance suficiente para sorprendernos, límites firmes alrededor de ese alcance y pruebas cuando afirman haber tenido éxito.
Eso es ExploitHunter: un solo lugar desde el que dirigir los modelos, las herramientas, los laboratorios, las aprobaciones, las pruebas y el seguimiento hacia el mismo problema.
Ahora apúntalo a algo que tengas permiso para romper.