Las tres herramientas anteriores —Top Ten, ASVS y SAMM— son documentos y marcos: te dicen qué mirar, qué verificar y cómo madurar, pero ninguna ataca la aplicación por ti. En la autoevaluación SAMM, BazarNube descubrió su hueco más urgente: la práctica de pruebas de seguridad (Verification) estaba en nivel 0, porque no probaban activamente su propia aplicación. Marc lo resume bien: "Tenemos checklists preciosas, pero nadie ha intentado de verdad romper la API". Necesitan una herramienta ejecutable que golpee la aplicación en funcionamiento y les diga qué encuentra. Esa es la cuarta pieza de la caja: OWASP ZAP, el Zed Attack Proxy. En esta lección la presentamos; su instalación y uso detallado son el contenido del módulo 6.

1. Qué es ZAP
2. Qué tipo de pruebas hace: DAST (pruebas dinámicas)
3. ZAP frente a SAST y SCA: dónde encaja cada uno
4. Casos de uso de ZAP
5. Cómo probaría BazarNube su API con ZAP

OWASP ZAP (Zed Attack Proxy) es una herramienta de código abierto y gratuita para encontrar vulnerabilidades en aplicaciones web en ejecución. Es uno de los proyectos flagship de OWASP y una de las herramientas de seguridad más usadas del mundo. Tiene dos almas que conviene distinguir desde el principio:

• Un proxy de interceptación. ZAP se sitúa entre el navegador y la aplicación, de modo que todo el tráfico HTTP/HTTPS pasa por él. Esto le permite ver, pausar y modificar las peticiones y respuestas al vuelo. Es como poner una "cámara con mando a distancia" en medio de la conversación entre cliente y servidor.
• Un escáner DAST. Sobre ese tráfico, ZAP puede lanzar pruebas automatizadas que buscan vulnerabilidades conocidas (inyecciones, XSS, cabeceras faltantes, etc.).

Al ser software libre y contar con una comunidad enorme, es una elección natural para una startup como BazarNube: cero coste de licencia y capacidad de integrarse en su pipeline.

ZAP practica pruebas de tipo DAST (Dynamic Application Security Testing). La palabra clave es dinámico: ZAP prueba la aplicación mientras se está ejecutando, atacándola desde fuera, igual que haría un atacante real. No necesita ver el código fuente.

Cómo funciona, a grandes rasgos (el detalle es del módulo 6):

1. Explora (spider/crawl). ZAP recorre la aplicación para descubrir sus URLs, formularios y endpoints.
2. Ataca (active scan). Sobre lo descubierto, envía peticiones manipuladas (payloads) para ver si la aplicación reacciona de forma insegura.
3. Observa y reporta. Analiza las respuestas y genera un informe con las vulnerabilidades encontradas, su gravedad y evidencia.

La gran ventaja del enfoque dinámico: encuentra fallos tal como se manifiestan en ejecución real, incluidos problemas de configuración del servidor que un análisis del código nunca vería. Su límite: solo ve lo que puede alcanzar desde fuera; si un endpoint no se descubre, no se prueba.

ZAP no sustituye a otras herramientas de seguridad: las complementa. Para no confundirlas, conviene situar las tres grandes familias del análisis automatizado. Aquí las presentamos a alto nivel; profundizamos en la combinación en la lección 02-05 y en el módulo 7.

La idea esencial: ninguna herramienta lo ve todo. SAST ve el código pero no el comportamiento real; SCA ve las dependencias pero no tu lógica; DAST (ZAP) ve el comportamiento real pero no el código interno. Una estrategia madura las combina. Para el hueco de Verification que SAMM detectó en BazarNube, ZAP (DAST) es el punto de entrada más natural, porque prueba la aplicación tal como está desplegada, sin necesidad de instrumentar el código.

ZAP es versátil. Sus usos más habituales, de menor a mayor sofisticación:

• Exploración manual asistida. Navegar la aplicación con ZAP como proxy para inspeccionar y manipular peticiones a mano (ideal para entender cómo funciona y probar hipótesis).
• Escaneo automatizado puntual. Lanzar un active scan contra la aplicación antes de una release para obtener un informe rápido de vulnerabilidades.
• Prueba de APIs. Alimentar a ZAP con la definición de la API (por ejemplo, una especificación OpenAPI) para que pruebe sus endpoints de forma sistemática. Muy relevante para BazarNube, cuya lógica vive en una API.
• Integración en CI/CD (DevSecOps). Ejecutar ZAP automáticamente en el pipeline en cada despliegue, de modo que un fallo nuevo rompa el build. Esto conecta con el módulo 7.

Apliquémoslo al caso. La lógica de negocio de BazarNube vive en su API Node.js/Express, con un módulo legacy Java detrás. ZAP es ideal para probarla. El flujo que seguiría el equipo (detallado en el módulo 6) sería:

1. Levantar el entorno. BazarNube corre en contenedores Docker, así que la SRE despliega una copia de la API en un entorno de pruebas (nunca contra producción sin control).
2. Dar a ZAP el mapa de la API. Como la API está documentada con OpenAPI, se le pasa esa definición para que conozca todos los endpoints (/api/login, /api/pedidos/:id, /api/buscar, etc.).
3. Lanzar el escaneo. ZAP explora y ataca cada endpoint con payloads de prueba.

De forma ilustrativa, así se vería un fragmento de informe de ZAP sobre la API de BazarNube (formato simplificado; la herramienta real y su salida se ven en el módulo 6):

Observa la potencia de esto y cómo cierra el ciclo con las herramientas anteriores:

• Cada hallazgo de ZAP se vuelca al backlog y se etiqueta con su categoría Top Ten (A03, A05, A01), el vocabulario que fijamos en 02-01.
• Cada hallazgo puede cruzarse con la checklist ASVS de 02-02: el IDOR confirma que el requisito de control de acceso estaba realmente incumplido, no era una sospecha.
• El simple hecho de ejecutar ZAP con regularidad hace subir la práctica de Verification de SAMM (02-03) de nivel 0 a nivel 1.

Así, ZAP no es una herramienta aislada: es el motor de detección activa que alimenta de evidencias reales a todo el sistema (Top Ten + ASVS + SAMM) que BazarNube ha ido montando.

• Escanear producción sin permiso ni control. ZAP ataca de verdad: un active scan puede crear datos basura, disparar acciones o degradar el servicio. Se ejecuta contra entornos de pruebas o con autorización y ventana controlada.
• Creer que ZAP encuentra "todo". DAST solo ve lo alcanzable desde fuera y lo que sabe reconocer. No detecta fallos de lógica de negocio profundos ni sustituye a SAST/SCA ni a la revisión humana.
• Escanear solo la superficie web y olvidar la API. En apps modernas como BazarNube, la lógica está en la API. Hay que darle a ZAP la definición de la API (OpenAPI) para que la cubra; si no, se prueba solo una fracción.
• Ejecutarlo una vez y archivar el informe. El valor está en la repetición: integrarlo en el pipeline para detectar regresiones. Un escaneo aislado envejece en días.
• Consejo: empieza con un escaneo manual/exploratorio para entender la app antes de automatizar. Comprender el tráfico con el proxy te enseña más sobre tu propia aplicación de lo que imaginas.

Ejercicio 1. Clasifica cada herramienta como SAST, DAST o SCA: (a) analiza el código Java del módulo de facturación en busca de patrones inseguros sin ejecutarlo; (b) revisa el package.json de la API en busca de librerías con CVEs conocidos; (c) ataca /api/buscar con payloads mientras la aplicación corre.

Ejercicio 2. La SRE propone añadir ZAP al pipeline de CI/CD para que se ejecute en cada despliegue a staging. Explica en 3–4 líneas qué práctica de SAMM mejora esto y por qué es preferible a un escaneo manual esporádico.

Ejercicio 3. Un compañero dice: "Con ZAP ya no necesitamos ASVS ni revisiones de código, porque ZAP encuentra las vulnerabilidades". Rebate esta afirmación con dos argumentos.

Solución 1. (a) SAST (análisis estático del código fuente, sin ejecutarlo); (b) SCA (análisis de composición: dependencias de terceros y sus vulnerabilidades conocidas); (c) DAST (análisis dinámico de la aplicación en ejecución; es lo que hace ZAP).

Solución 2. Mejora la práctica de pruebas de seguridad del dominio Verification de SAMM, y ayuda también al despliegue seguro (Implementation/DevSecOps). Es preferible al escaneo esporádico porque lo convierte en sistemático y repetible: cada release se prueba automáticamente, se detectan regresiones de inmediato y la práctica sube de nivel de madurez (de "ad hoc" a "definido"), en lugar de depender de que alguien se acuerde de lanzarlo.

Solución 3. (1) ZAP es DAST: solo ve lo alcanzable desde fuera y lo que sabe reconocer; no detecta muchos fallos de lógica de negocio, ni problemas en código no expuesto, ni componentes vulnerables (eso es SCA). (2) ASVS y las revisiones de código cumplen una función distinta y complementaria: verificar requisitos y razonar sobre el diseño y el código interno, cosas que un escáner dinámico no hace. La seguridad madura combina SAST, DAST, SCA y verificación manual; ninguna herramienta las reemplaza a todas.

Has conocido la cuarta herramienta de la caja OWASP: ZAP, un proxy de interceptación y escáner DAST de código abierto que prueba la aplicación en ejecución, desde fuera, como un atacante real. Sabes situarlo frente a SAST (código) y SCA (dependencias) —se complementan, no se sustituyen— y has visto sus casos de uso, desde la exploración manual hasta la integración en CI/CD. Y, sobre todo, has visto cómo BazarNube probaría su API con ZAP y cómo cada hallazgo cierra el ciclo: se etiqueta con Top Ten, se cruza con ASVS y hace madurar su SAMM.

Con ZAP completamos los cuatro proyectos flagship que vertebran este curso (Top Ten, ASVS, SAMM, ZAP), cada uno con su módulo dedicado más adelante. Pero la caja de herramientas de OWASP tiene mucho más que ofrecer: guías de testing, chuletas de remediación, escáneres de dependencias y aplicaciones para practicar. En la lección 02-05, la última del módulo, presentamos esos otros proyectos clave que BazarNube combinará con los cuatro grandes para tener una estrategia completa.