VulnHunter: Cómo Poner el Cazador de Vulnerabilidades de Capital One a Trabajar Sobre Tu Propio Repo
Por Devy · Categoría: Cybersecurity para devs + AI coding tools · Con nota estratégica de Grego
Hay una diferencia enorme entre un scanner que te tira 300 alertas y te desea suerte, y un agente que empieza donde entra el atacante, razona hacia adelante hasta el código peligroso, y antes de mostrarte nada intenta demostrar que él mismo está equivocado. VulnHunter —la herramienta que Capital One usaba internamente sobre miles de repos y acaba de liberar como open source— es lo segundo. Y lo mejor: no es un producto cerrado ni un SaaS con demo de ventas. Son tres skills de Claude Code que instalás en tu máquina y apuntás a tu propio repositorio.
En este artículo lo instalamos, lo corremos sobre un repo real y cerramos el loop completo hunt → fix → verify. Y como siempre, te digo con todas las letras qué necesitás de verdad para que funcione, porque hay un requisito que los titulares no están mencionando.
Qué es VulnHunter, en una respiración
VulnHunter es una herramienta de seguridad agéntica y open source (Apache 2.0) publicada por Capital One el 18 de julio de 2026 bajo el tag v0.1.0 “Initial Launch”. Su descripción oficial en GitHub lo resume así: “Agentic AI security tool that applies proactive, attacker-first analysis directly to source code.”
Tres ideas la separan de un SAST clásico:
Análisis attacker-first, hacia adelante. Un scanner tradicional es “sink-first”: busca patrones sospechosos en el código (un eval, una query concatenada) y trata de razonar hacia atrás si son alcanzables. VulnHunter invierte el flujo: arranca en los entry points que el atacante realmente toca —APIs, uploads de archivos, mensajes de red— y razona hacia adelante a través de la lógica de la aplicación, como haría un pentester. Encuentra el camino, no el patrón.
Falsification engine. Este es el detalle que más me gusta. Antes de mostrarte un hallazgo, VulnHunter intenta refutar su propio argumento: busca supuestos no fundamentados, saltos lógicos y condiciones que impedirían el ataque. Solo lo que sobrevive a ese escrutinio interno llega a tus ojos. Es un mecanismo explícito contra la plaga número uno de las herramientas de seguridad: el falso positivo que te hace perder la mañana.
Remediación con evidencia. No te dice “acá hay algo raro”. Mapea el camino de explotación completo, explica qué capacidad necesita el atacante y genera un cambio de código concreto para que revises.
Capital One dice haberla validado internamente sobre miles de repositorios abarcando decenas de áreas de negocio antes de abrirla. No es un experimento de laboratorio: es la herramienta que ya corría en producción en un banco.
El requisito que nadie está diciendo en voz alta
Antes de que abras la terminal con entusiasmo: VulnHunter no es un binario suelto ni self-hosted en el sentido estricto. Está construido como tres skills de Claude Code y necesita acceso al modelo Claude Opus para correr. En concreto, los requisitos son:
- Claude Code CLI, autenticado y con acceso a Claude Opus.
- Python 3.12+ (solo para el agente en runtime y el harness de benchmarking).
- Autorización para analizar el codebase objetivo (obvio, pero está escrito en la doc).
- Para la parte de fix: Git y la GitHub CLI autenticada, porque el fixer abre pull requests.
O sea: el “instalable y gratis” tiene un asterisco. El código de VulnHunter es Apache 2.0 y no pagás licencia por él, pero el motor que lo hace pensar es Claude Opus, y eso lo ponés vos. Si ya trabajás con Claude Code, no cambia nada tu setup. Si no, ese es el costo real de entrada, y prefiero que lo sepas antes de invertir diez minutos que antes de invertir dos horas.
Instalación en 10 minutos (asumiendo que ya tenés Claude Code)
1. Cloná el repo.
git clone https://github.com/capitalone/vulnhunter.git
cd vulnhunter
2. Corré el instalador.
./install.sh
El script copia las skills a ~/.claude/skills/ (usa copia directa de archivos en vez de symlinks, a propósito, para que sigan funcionando dentro de subagents). Al terminar vas a tener tres skills disponibles:
/vulnhunt— la fase de caza: identifica vulnerabilidades explotables./vulnhunter-fix— la fase de remediación: escribe tests, implementa el fix y abre un PR./vulnhunt-fix-verify— un agente de verificación independiente que valida que el fix realmente funcionó, sin confiar en los hallazgos previos.
3. Verificá que quedaron instaladas.
ls ~/.claude/skills/ | grep vulnhunt
Si ves las carpetas de las skills, estás listo.
Corriendo la caza sobre tu repo
Andá a la raíz del proyecto que querés analizar y abrí una sesión de Claude Code con Opus, dándole acceso a las carpetas de la skill:
cd /ruta/a/tu/proyecto
claude --model opus \
--add-dir ~/.claude/skills/vulnhunt \
--add-dir ~/.claude/skills/vulnhunt/phases
Dentro de la sesión, invocá la caza:
/vulnhunt
VulnHunter va a mapear los entry points de tu aplicación, razonar hacia adelante hasta los sinks peligrosos, y —clave— pasar cada candidato por el falsification engine antes de reportarlo. Lo que recibís no es una lista de sospechas: es un conjunto de hallazgos que ya sobrevivieron a un intento de refutación, cada uno con su camino de explotación explicado.
Cerrando el loop: fix y verify
Acá está la parte que convierte a VulnHunter en algo más que un reporte lindo. Con un hallazgo confirmado, pasás a la remediación:
/vulnhunter-fix
Esta skill escribe primero un test que reproduce el problema, implementa el arreglo, y abre un pull request (por eso necesitás Git y la GitHub CLI). No te deja el fix en el aire: lo deja listo para revisión con evidencia de que ataca el problema real.
Y el cierre honesto del ciclo:
/vulnhunt-fix-verify
Un agente independiente valida que el fix efectivamente cerró la vulnerabilidad. La palabra importante es “independiente”: no reutiliza el razonamiento de la fase de caza ni asume que el fixer hizo bien su trabajo. Verifica desde cero. Es la misma filosofía del falsification engine aplicada al final del loop: no te fíes de tu propio agente, hacelo probar que tiene razón.
El resultado es un ciclo completo —hunt → fix → verify— que podés correr sobre tu repo sin escribir una sola línea de pegamento.
Un caso de uso concreto: código generado por IA
Si tu equipo está shippeando código asistido por IA a velocidad de 2026, este es tu escenario. El código generado suele ser sintácticamente impecable y semánticamente confiado, que es justo la combinación donde se cuelan los problemas de autorización rota, la validación de input que se asumió y nunca se escribió, y el path traversal en el upload que “seguro el framework maneja”. Un análisis attacker-first que arranca en el entry point es precisamente lo que atrapa esa clase de bug, porque no le importa qué tan prolijo se ve el código: le importa si hay un camino desde afuera hasta algo peligroso.
Nota estratégica de Grego: por qué un banco publica capacidad ofensiva
Vale la pena detenerse en la parte rara de esta noticia. Capital One es un banco. Los bancos no son famosos por regalar sus defensas. Que uno libere —bajo Apache 2.0, sin fricción— una herramienta que razona como un atacante sobre código fuente es un movimiento que merece que lo leamos bien.
El argumento que da Capital One es que la seguridad del software moderno es un problema comunal, no propietario. Las cadenas de suministro están tan entrelazadas que una vulnerabilidad en una dependencia cascadea sobre miles de empresas a la vez. En ese mundo, guardarte tu mejor defensa bajo llave no te hace más seguro: te deja parado sobre el mismo ecosistema frágil que todos los demás. Abrirla invita a la comunidad global de seguridad a fortalecer el terreno común —y, de paso, a mejorarle la herramienta al propio banco vía contribuciones—. Es open source como estrategia de defensa colectiva, no como gesto de generosidad.
Para nosotros en Iberoamérica hay una lectura más práctica todavía. La mayoría de los equipos de la región no tiene un ingeniero de AppSec dedicado, y contratar pentesting recurrente está fuera de presupuesto para casi todos. Una herramienta de razonamiento ofensivo, madurada dentro de un banco sobre miles de repos, disponible gratis y corriendo sobre infraestructura de IA que muchos equipos ya pagan —Claude Code con Opus— baja una barrera que históricamente separó a los que podían costear seguridad seria de los que no. El costo ya no es un contrato de seis cifras: es el modelo que quizás ya tenés en tu stack.
La contracara honesta: esa dependencia de Opus también significa que VulnHunter no es “gratis” en el sentido en que lo es un linter. Corre sobre un modelo premium, y una caza sobre un repo grande consume tokens de verdad. Mi recomendación es tratarlo como lo que es —una auditoría de seguridad profunda, no un check de cada commit— y correrlo en los momentos que importan: antes de un release, sobre el código nuevo generado por IA, sobre el servicio que expone la API pública. Usado con criterio, es de las cosas más útiles que un banco le regaló a la comunidad dev en mucho tiempo.
Para llevarte
VulnHunter no es un scanner más: es un agente que caza como atacante, duda de sí mismo antes de hablarte, y cierra el loop hasta el fix verificado. Si ya vivís en Claude Code, ponerlo a trabajar sobre tu repo es cuestión de diez minutos y tres comandos. Si todavía no, el requisito de Opus es el peaje que tenés que evaluar. En cualquier caso, que un banco haya abierto esta capacidad dice algo sobre hacia dónde va la seguridad de software: hacia lo agéntico, hacia lo comunal, y hacia el lado del que defiende teniendo que pensar, por fin, como el que ataca.
Fuentes: