Auditamos OWASP NodeGoat con un inspector de seguridad en Claude Code: qué encontró y qué no

Un inspector de seguridad armado como agente de Claude Code encontró 4 de los 5 defectos que escribimos de antemano en OWASP NodeGoat, más 21 hallazgos fuera de esa lista que verificamos a mano, y dejó 6 sin confirmar. Es una sola corrida sobre un solo repositorio, así que no es una tasa de acierto: es una muestra con las cifras a la vista para que juzgues tú si te sirve. Todo está publicado en un repositorio de muestra.

Datos tomados de ese repositorio, con la corrida del 25 de octubre de 2026.

El caso

OWASP NodeGoat es una aplicación Node.js pública, hecha a propósito para ser vulnerable y servir de práctica (licencia Apache-2.0). Elegimos el commit c5cb68a y definimos el alcance: app/, config/ y server.js.

Antes de ver el resultado del inspector, leímos el código y escribimos la verdad de referencia: cinco defectos que comprobamos a mano.

• Un eval() sobre lo que el usuario escribe en el formulario de contribuciones.
• Una consulta $where de MongoDB armada con un parámetro sin validar (en dos líneas distintas del mismo archivo).
• Una redirección abierta en /learn.
• Un secreto escrito en el código versionado.

Escribir la lista antes es lo que da sentido a la comparación: si la armas después, siempre aciertas.

Qué encontró

Medida	Resultado
Defectos de la verdad de referencia encontrados	4 de 5
Hallazgos totales	31
Fuera de la verdad y verificados a mano	21
Sin confirmar	6

El que faltó es la segunda consulta $where. El inspector la miró: en el backlog la anota como rama que usa el valor ya convertido a entero y la juzga no explotable con texto. Nosotros la habíamos contado como defecto; es una diferencia de criterio, no un olvido, y por eso la dejamos a la vista en lugar de ajustar la lista.

«Verificado a mano» significa algo acotado: la línea citada existe y contiene lo que el inspector describe. No probamos cada explotación. Los 6 hallazgos sin confirmar no entraron al backlog.

De los hallazgos verificados salieron 23 ítems de backlog, agrupando los que apuntan al mismo defecto (por ejemplo, el SSRF y la respuesta sin escapar de una misma ruta son un solo ítem). Los cinco más graves, todos prioridad P0, fueron:

1. eval() sobre campos del formulario de contribuciones: ejecución de JavaScript en el servidor.
2. $where con el parámetro threshold concatenado.
3. Una ruta que descarga la dirección que el usuario le pasa (SSRF).
4. Asignaciones pedidas por el id de la URL y no por el de la sesión.
5. Contraseñas guardadas y comparadas en texto plano.

Cada ítem trae descripción, archivo y línea, criterios de aceptación y el riesgo de tocarlo. Puedes leer los 23 en el backlog completo.

Qué NO demuestra

• No es una tasa de acierto. Una corrida, un repositorio.
• NodeGoat es famoso y probablemente está en el entrenamiento del modelo; además trae comentarios que marcan los defectos. Es el caso fácil. Un proyecto real, sin esas pistas, puede dar otro resultado.
• No se probó cada explotación, solo que la línea existe y dice lo descrito.
• Solo se probó con Claude Code. Un asistente distinto puede comportarse distinto.
• Un inspector de seguridad no reemplaza una auditoría profesional ni una prueba de penetración.

Cómo repetirlo en tu proyecto

Sin comprar nada, puedes hacer una versión simple de este método:

1. Escribe tu verdad de referencia antes. Si conoces defectos de tu código, anótalos con archivo y línea antes de pedirle nada al agente.
2. Dale un solo criterio. Un subagente que solo revisa seguridad, con herramientas de solo lectura, es más fácil de acotar y de verificar que un «revisa todo». Esto lo explicamos en subagentes para diseñadores.
3. Exige archivo y línea en cada hallazgo, y verifica una muestra a mano. Lo que no puedes verificar se queda fuera del backlog.
4. Pídele que busque a los hermanos: cuando encuentre una forma de defecto, que busque la misma forma en el resto del código y anote cuáles revisó y por qué los descartó.
5. No dejes que toque nada sin tu OK. Primero informe, después cambios.

Si quieres que esto corra solo

El inspector de esta muestra es parte de Kaizora, un sistema de agentes de mejora continua que instalas en tu repositorio: revisa seguridad, SEO, código, UX, accesibilidad, rendimiento y negocio, anota lo que encuentra en un backlog priorizado y deja un informe HTML. Por defecto solo observa; tú decides si le das permiso para cambiar algo. Es de pago, US$ 20 de lanzamiento al 25 de octubre de 2026, y la muestra de NodeGoat es el informe real, para que lo veas antes de decidir. Ver Kaizora en Gumroad. Kaizora no tiene afiliación con OWASP ni con Anthropic, y solo Claude Code está probado en ejecución real.