Construye un agente escáner de seguridad con Claude Code para OWASP

Las auditorías de seguridad no son un interés secundario para mí. Fundé xCyberSecurity, y las auditorías al estilo OWASP de apps Laravel, sitios WordPress y cuentas de AWS son trabajo facturable que llevo años haciendo. El agente de este post es ese flujo de trabajo codificado en Claude Code, y la tesis de todo este artículo es esta: un escáner de seguridad con IA vive o muere por su arquitectura, no por el prompting. En concreto, debes separar la metodología (una skill) de la ejecución (sub-agents con contexto limpio), porque la calidad de la auditoría se degrada exactamente en proporción a lo llena que está la ventana de contexto cuando el auditor llega a tu código.

Por qué falla un único gran prompt de "escanea mi repo"

La versión ingenua es una sesión y una instrucción: audita este código base frente al OWASP Top 10. El patrón de fallo es predecible: las primeras categorías reciben un análisis cuidadoso, pero a medida que el contexto se llena con el contenido de archivos de pasadas anteriores, el modelo empieza a leer por encima las últimas. El formato del informe también varía entre ejecuciones, lo que importa más de lo que la gente cree: una auditoría que no puedes comparar con un diff frente a la del mes pasado es algo puntual, no un proceso de seguridad.

Los auditores humanos tienen el mismo modo de fallo, y por eso las firmas de auditoría reales usan checklists y revisores nuevos para cada dominio. La solución se corresponde punto por punto.

La arquitectura: una skill para las reglas, sub-agents para la lectura

La skill es la metodología del auditor sénior, escrita una sola vez. La mía contiene cuatro secciones:

1. Alcance y mapeo de categorías. El OWASP Top 10 mapeado a lo que significa concretamente cada categoría en los stacks que audito. Las categorías abstractas producen hallazgos abstractos; la skill las traduce.
2. Una rúbrica de severidad. Crítica, alta, media, baja, con definiciones ligadas a la explotabilidad y al radio de impacto, para que la severidad se asigne por regla y no por intuición. Esta es la sección por la que los clientes realmente pagan, y fue la que más iteraciones necesitó.
3. Un formato de informe fijo. Hallazgo, archivo y línea, categoría, severidad, fragmento de evidencia, remediación, confianza. En cada ejecución, la misma forma, para que las ejecuciones sean comparables a lo largo del tiempo.
4. Reglas estrictas. Solo lectura, siempre: el escáner nunca edita código. Informar de todo, incluidos los hallazgos de baja confianza, marcados como tales, porque un paso de triaje posterior puede filtrar el ruido pero no puede recuperar un hallazgo que nunca se reportó. Nunca reproducir los secretos descubiertos en el cuerpo del informe; solo indicar su ubicación.

Los sub-agents son donde se va el presupuesto de tokens. La sesión orquestadora despacha un sub-agent por categoría (o por módulo, en códigos base grandes), cada uno con un contexto limpio que lee a fondo los archivos relevantes y devuelve solo hallazgos estructurados. El orquestador nunca ve el contenido en bruto de los archivos, solo los hallazgos, que fusiona, deduplica y ordena. Es el mismo patrón de contexto limpio que hace que los sistemas de agentes sean asequibles en general, aplicado a un dominio donde la lectura superficial no es un problema de costes sino de corrección.

Lo que comprueba la skill, porque yo lo compruebo a mano

El valor de codificar tu propio flujo de trabajo, en lugar de descargar el prompt de seguridad genérico de otra persona, es que las comprobaciones llevan consigo tu historial de encargos. Las mías incluyen:

• Laravel: mass assignment por un $fillable demasiado permisivo o $guarded = [], DB::select en bruto con cadenas interpoladas, falta de autorización en el route model binding (el clásico IDOR), APP_DEBUG=true en configuraciones de producción, validación que vive en los controladores en lugar de en Form Requests, donde el siguiente endpoint se la salta, y queue jobs que confían en sus payloads.
• WordPress: comprobaciones de nonce ausentes en acciones que cambian el estado, comprobaciones de capacidades confundidas con comprobaciones de autenticación, acceso directo a archivos sin guardas ABSPATH, y $wpdb->query con entradas sin preparar en plugins personalizados, que es por donde realmente comprometen los sitios de los clientes.
• AWS IAM: acciones comodín sobre recursos comodín, usuarios con contraseñas de consola y sin MFA, y access keys más antiguas que el desarrollador que las creó.

Nada de esa lista es exótico. Esa es la cuestión. Las auditorías fallan por cobertura y consistencia, no por falta de ingenio, y un agente es implacable precisamente con las cosas aburridas que los humanos se saltan en el archivo número cuarenta.

Probarlo contra una app construida para fallar

Un escáner nuevo no se apunta primero al código de un cliente. Construye una app deliberadamente vulnerable como objetivo de prueba y siémbrala con los clásicos: hashing de contraseñas con MD5, SQL concatenado con cadenas en un endpoint de búsqueda, un IDOR en una ruta de visualización, una API key hardcodeada en un archivo de configuración, ausencia de rate limiting en el login y stack traces detallados en modo producción.

Detectar los problemas sembrados es la condición para aprobar, pero los resultados informativos están en los extremos. Vigila un tipo concreto de falsos positivos: código que es seguro pero feo, como una entrada que se validó antes en la cadena de una forma que el sub-agent de la categoría no podía ver. Haz que los sub-agents informen de la suposición detrás de cada hallazgo ("supone que $request->input llega a esta consulta sin validar"), lo que convierte un falso positivo de ruido en algo que se descarta en un segundo. Luego comprueba la consistencia: ejecuciones repetidas sobre el mismo commit deberían producir informes sustancialmente idénticos, que es la propiedad que hace que el agente sea apto para CI.

Integrarlo en el flujo de trabajo

Dos puntos de integración se ganan su sitio. Un escaneo pre-commit o pre-merge se ejecuta limitado al diff, solo con las categorías relevantes para los archivos modificados, lo bastante barato como para ejecutarlo en cada PR. Un escaneo completo programado se ejecuta semanalmente contra main con el barrido completo de categorías, y su informe se compara con un diff frente al de la semana anterior. Los hallazgos nuevos deberían avisar a un humano; los hallazgos desaparecidos deberían verificarse como realmente corregidos y no como ocultados por accidente. Si ejecutas agentes con este nivel de acceso al repo, la parte de permisos y onboarding de la seguridad de agentes merece tanta reflexión como la parte del escaneo; un escáner con acceso de escritura es en sí mismo un hallazgo.

Dónde falla esto, con honestidad

El agente no entiende tu lógica de negocio. Puede ver que a una ruta le falta una comprobación de autorización; no puede saber que la intención era "los usuarios solo pueden ver las facturas de su propia organización a menos que sean revendedores". La autorización de la lógica de negocio sigue siendo trabajo humano, informado por el mapa del agente. No prueba el comportamiento en tiempo de ejecución, así que complementa en lugar de sustituir a los escáneres de dependencias y a las herramientas DAST; lee código, y los sistemas en ejecución fallan de formas que la revisión de código no puede ver. Y no firma el informe. Cuando los hallazgos van a un cliente, un humano que puede defender cada línea pone su nombre en él. El mío.

Tampoco se lo daría a alguien que nunca ha auditado nada, porque la skill codifica un criterio que tienes que poseer antes de poder codificarlo. Un agente como este hace que las auditorías sean más rápidas y consistentes. No las hace posibles; eso lo hacen años de hacerlas a mano.

¿Quieres la auditoría, no la construcción?

Si lo que realmente necesitas es que auditen tu app Laravel, tu sitio WordPress o tu cuenta de AWS, eso es literalmente lo que hago, con este agente como primera pasada y mis ojos como segunda. La parte de seguridad de mis servicios cubre auditorías de código al estilo OWASP hasta la remediación, y cada encargo termina con el formato de informe comparable mediante diff descrito arriba, no con un PDF de capturas de pantalla. Tráeme un código base; yo traeré el escáner y la firma.