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 agente, no solo Claude Code. El enfoque de este fork: portabilidad entre harnesses, validación de exploits en sandbox (containerizada) y PoCs de impacto medido. Ver 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 análisis proactivo con enfoque atacante primero directamente sobre el 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 prospectivas 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 por miles de empresas simultáneamente.
VulnHunter fue desarrollado internamente en Capital One y liberado como código abierto para la comunidad. Este fork lleva ese trabajo hacia adelante — la misma metodología, reelaborada para ejecutarse en cualquier harness de agente, con validación de exploits en sandbox (containerizada) y PoCs de impacto medido como hoja de ruta. Ver Qué cambia este fork.
Precaución de doble uso VulnHunter realiza trabajo de ciberseguridad de doble uso (descubrimiento y explotación de vulnerabilidades). Espere barreras de seguridad: la mayoría de los modelos disponibles comercialmente aplican salvaguardas cibernéticas de doble uso, y el comportamiento agresivo de explotación puede activar límites de velocidad o marcas de uso. El desarrollo y las pruebas de VulnHunter se ejecutaron sobre 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 el futuro. Audite únicamente código que posea o que esté autorizado a auditar.
[!IMPORTANT] Requisitos previos y requisitos de modelo La metodología de VulnHunter está construida para ejecutarse sobre modelos de pesos abiertos proporcionados por la comunidad — los desriesgados, abliterados y sin censura que las organizaciones realmente pueden 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 entre harnesses | Las skills invocan Claude Code específicamente; el instalador apunta a ~/.claude/skills; las compuertas de modelo fijan Opus; 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 reformuladas a "el modelo de razonamiento más capaz de su harness" | Entregado |
| Instalador sin adivinanzas | 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 + definición de agente; equivalentes .cmd de Windows actualizados | Entregado |
Skill de operador vulnhunter-run | — (ausente) | Operador desatendido: clonar → cazar → encontrar resultados → escribir/validar el manifiesto de escaneo, con reglas de parada explícitas y sin improvisación | Entregado |
| Endurecimiento de benchmark/juez | Modelo fijo + reintento básico | Modelo vía entorno, configuración de reintento/backoff, trazado de puntos de pérdida del pipeline analyze_misses, seguimiento de historial por hallazgo | Entregado |
| Lenguaje de informe neutral respecto al harness | Prosa específica de Claude en todas las skills | Lenguaje de herramienta neutral respecto al harness (Agent → subagente, Claude CLI → sesión del harness) | Entregado |
| 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 de impacto medido | Las PoCs son documentos; el impacto se afirma | PoC ejecutable + número de impacto en el hallazgo (filas expuestas, solicitudes amplificadas, horas-clave varadas) | En progreso |
La metodología de VulnHunter es agnóstica respecto 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 harnesses de agentes se ha ampliado, y una metodología de seguridad que se instala en solo 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 su harness en lugar de un producto específico. Mejor significa: la misma metodología se instala en cualquier harness que su equipo ya ejecute — 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 ruidosamente con la instrucción exacta cuando falta la respuesta. Mejor significa: seguro en máquinas con múltiples harnesses, correcto bajo homes reubicados, ruidoso en lugar de silencioso cuando está mal configurado.
El diseño original ya exige falsificación y pruebas de exploit. Lo que dejaba abierto era cuán duro trabajar para ejecutarlas realmente: traza estática, prueba simulada o un servidor containerizado real. En un benchmark de seis ejecuciones contra un único commit, esa discrecionalidad produjo desde 3 hasta 42 hallazgos — y veredictos opuestos sobre el mismo sink, uno probado contra un mock, otro cerrado por una prueba contra un servidor real. Este fork añade un procedimiento de aprovisionamiento de runtime (Docker primero, registrado por hallazgo) y una disciplina de PoC donde el impacto se mide — filas filtradas, amplificación ×, horas-clave varadas — no se narra. Mejor significa: la validez de un hallazgo ya no depende de qué modelo tuvo el instinto de levantar un contenedor. (En progreso — el plan de construcción está en la hoja de ruta pública; pregunte en issues o siga las Discussions del repositorio.)
