nealbridges/vulnhunterEscáner de seguridad de IA agéntica que razona como un atacante sobre el código fuente, confirma fallos explotables con PoCs ejecutables e impulsa correcciones basadas en pruebas mediante habilidades de caza, corrección y verificación.
[!NOTE] Un fork mantenido de VulnHunter de Capital One (Apache-2.0) — creado para ejecutarse en cualquier harness de agentes, no solo en Claude Code. El enfoque de este fork: portabilidad entre harnesses, validación de exploits en sandbox (contenedorizada) y PoCs de impacto medido. Véase Por qué los cambios · Qué cambia este fork · Los números.
De la coincidencia de patrones a la demostrabilidad.
VulnHunter es una herramienta de seguridad con IA agéntica de código abierto que aplica un análisis proactivo, con enfoque de atacante, directamente al código fuente.
A diferencia de los escáneres SAST tradicionales y pasivos, que señalan patrones sospechosos y a menudo generan falsos positivos, VulnHunter razona como un adversario. Identifica qué defectos son realmente explotables, traza rutas de ataque potenciales y propone correcciones específicas respaldadas por evidencia.
Las cadenas de suministro de software modernas están profundamente interconectadas. Una sola vulnerabilidad en un componente de código abierto ampliamente utilizado puede propagarse a miles de empresas simultáneamente.
VulnHunter se desarrolló internamente en Capital One y se liberó como código abierto para la comunidad. Este fork da continuidad a ese trabajo — la misma metodología, reelaborada para ejecutarse en cualquier harness de agentes, con la validación de exploits en sandbox (contenedorizada) y las PoCs de impacto medido como hoja de ruta. Véase Qué cambia este fork.
Precaución por doble uso VulnHunter realiza trabajo de ciberseguridad de doble uso (descubrimiento y explotación de vulnerabilidades). Es de esperar encontrar barreras de protección: la mayoría de los modelos disponibles comercialmente aplican salvaguardas de ciberseguridad de doble uso, y un comportamiento de explotación agresivo puede activar límites de velocidad o marcas de uso. El desarrollo y las pruebas de VulnHunter se ejecutaron con modelos de pesos abiertos proporcionados por la comunidad — desriesgados, abliterados y sin censura — que son los modelos que probablemente importen para el uso organizacional en adelante. Audite únicamente código que sea de su propiedad o que esté autorizado a auditar.
[!IMPORTANT] Requisitos previos y requisitos del modelo La metodología de VulnHunter está diseñada para ejecutarse con modelos de pesos abiertos proporcionados por la comunidad — los desriesgados, abliterados y sin censura que las organizaciones pueden realmente desplegar. Se requiere un modelo de razonamiento capaz; el modelo más potente que ofrezca su harness da los mejores resultados, pero la metodología no depende del modelo de frontera de un proveedor específico. Usted proporciona su propio acceso al modelo.
| Capacidad | Upstream (Capital One) | Este fork | Estado |
|---|---|---|---|
| Portabilidad del harness | Las skills invocan específicamente Claude Code; el instalador apunta a ~/.claude/skills; las compuertas de modelo fijan Opus de forma rígida; el harness fija claude-opus-4-8 | Las skills son archivos de prompt portables entre harnesses (cualquier harness con un directorio de skills + subagentes); contrato de entorno VULNHUNT_SKILLS_DIR / VULNHUNT_AGENTS_DIR / VULNHUNT_BIN_DIR / VULNHUNT_HOST_CMD / VULNHUNT_MODEL; las compuertas de modelo se reformulan como "el modelo de razonamiento más capaz de tu harness" | Publicado |
| Instalador sin suposiciones | install.sh asume ~/.claude/skills | Directorios explícitos, respeta la semántica de GROK_HOME, escribe el lanzador vh en VULNHUNT_BIN_DIR/~/.local/bin, instala la skill vulnhunter-run + la definición del agente; equivalentes .cmd para Windows actualizados | Publicado |
Skill de operador vulnhunter-run | — (ausente) | Operador desatendido: clonar → cazar → buscar resultados → escribir/validar el manifiesto de escaneo, con reglas de parada explícitas y sin improvisación | Publicado |
| Endurecimiento de benchmark/juez | Modelo fijo + reintento básico | Modelo vía entorno, configuración de reintentos/backoff, trazado de puntos de pérdida con analyze_misses, seguimiento del historial por hallazgo | Publicado |
| Lenguaje de informe neutral respecto al harness | Prosa específica de Claude en todas las skills | Lenguaje de herramientas neutral respecto al harness (Agent → subagente, Claude CLI → sesión del harness) | Publicado |
| Validación de exploits con sandbox primero | Las pruebas de exploit pueden ser trazas estáticas; elección de runtime ad hoc | Aprovisionamiento de runtime con Docker primero; el runtime registrado por hallazgo; severidad Media+ debe ejecutarse | En progreso |
| PoCs con impacto medido | Las PoCs son documentos; el impacto se afirma | PoC ejecutable + cifra de impacto en el hallazgo (filas expuestas, solicitudes amplificadas, horas-clave varadas) | En progreso |
La metodología de VulnHunter es agnóstica al host por naturaleza: es procedimiento de prompt, no vinculación a una herramienta. El proyecto upstream creció dentro de Claude Code — una elección coherente, y el primer hogar correcto. Pero el panorama de los agent-harness se ha ampliado, y una metodología de seguridad que solo se instala en uno de ellos deja de ser una capacidad de auditoría y empieza a ser una característica de proveedor. Este fork hace cuatro cambios, cada uno con una razón.
Cada skill aquí es un archivo de prompt portable con un contrato de entorno explícito (VULNHUNT_SKILLS_DIR, VULNHUNT_AGENTS_DIR, VULNHUNT_MODEL, VULNHUNT_HOST_CMD), y las compuertas de modelo ahora piden el modelo de razonamiento más capaz de tu harness en lugar de un producto específico. Mejor significa: la misma metodología se instala en el harness que tu equipo ya ejecuta — y se vuelve comparable entre harnesses en las ejecuciones de benchmark, que es como se desarrolla este fork.
El instalador upstream copiaba las skills en ~/.claude/skills incondicionalmente. En una máquina que ejecuta dos harnesses — o un harness con un home reubicado — esa suposición instala en el lugar equivocado, silenciosamente. El instalador del fork pregunta, o toma variables de entorno, y falla de forma ruidosa con la instrucción exacta cuando falta la respuesta. Mejor significa: seguro en máquinas con múltiples harnesses, correcto con homes reubicados, ruidoso en lugar de silencioso cuando está mal configurado.
El diseño original ya exige pruebas de falsación y de explotación. Lo que dejaba abierto era cuánto esfuerzo dedicar a ejecutarlas realmente: traza estática, prueba con mocks o un servidor real en contenedor. En un benchmark de seis ejecuciones contra un único commit, esa discrecionalidad produjo entre 3 y 42 hallazgos, y veredictos opuestos sobre el mismo sink: uno demostrado contra un mock, otro descartado por una prueba contra un servidor real. Este fork añade un procedimiento de aprovisionamiento en tiempo de ejecución (Docker primero, registrado por hallazgo) y una disciplina de PoC en la que el impacto se mide —filas filtradas, amplificación ×, horas-clave varadas— en lugar de narrarse. Mejor significa: la validez de un hallazgo ya no depende de qué modelo tuvo el instinto de levantar un contenedor. (En curso — el plan de construcción está en la hoja de ruta pública; pregunta en los issues o sigue las Discussions del repositorio.)
