Hasta aquí, el equipo de BazarNube ha adoptado los cuatro proyectos flagship de OWASP: el Top Ten (qué riesgos), ASVS (qué verificar), SAMM (cómo madurar) y ZAP (cómo probar en ejecución). Pero al repasar el backlog, aparecen preguntas prácticas que esos cuatro no resuelven del todo. "¿Cómo probamos manualmente y a fondo cada endpoint?" (Marc). "Cuando ZAP encuentra un XSS, ¿dónde miro el remedio exacto y bien explicado?" (Lucía). "¿Y quién nos avisa de que una librería que usamos tiene un CVE nuevo?" (la SRE). "¿Dónde practicamos sin romper nada real?" (todos). OWASP tiene un proyecto para cada una de esas preguntas. En esta lección presentamos esos otros proyectos clave que completan la caja de herramientas.

Es la última lección del módulo panorámico: aquí ampliamos la caja y aprendemos a combinar proyectos según el trabajo a realizar.

1. WSTG: la guía para probar a fondo
2. Cheat Sheet Series: las chuletas de remediación
3. Dependency-Check y el análisis de dependencias (SCA)
4. Juice Shop: practicar sin romper nada real
5. Tabla resumen: qué proyecto uso para qué
6. Cómo combinaría BazarNube varios proyectos

La OWASP Web Security Testing Guide (WSTG) es una guía metodológica y exhaustiva para probar la seguridad de aplicaciones web. Donde el Top Ten dice "existe el riesgo de inyección", la WSTG dice "así se prueba, paso a paso, si tu aplicación es vulnerable a inyección".

Rasgos clave:

• Es una metodología de testing: describe qué probar, en qué orden y cómo, agrupado por áreas (gestión de sesiones, autenticación, validación de entrada, lógica de negocio...).
• Cada prueba tiene un identificador y explica objetivo, técnica y qué buscar. Es la referencia de cabecera de los pentesters.
• Complementa a ZAP: ZAP automatiza mucho, pero la prueba manual guiada por la WSTG encuentra fallos (sobre todo de lógica de negocio) que ninguna automatización detecta.

Para BazarNube, la WSTG es el manual de campo cuando Marc quiere probar manualmente el flujo de checkout o la lógica de cupones, más allá de lo que ZAP cubre.

La OWASP Cheat Sheet Series es una colección de guías concisas y prácticas ("chuletas") sobre cómo defenderse de riesgos concretos. Si el Top Ten conciencia y la WSTG te ayuda a encontrar el fallo, las Cheat Sheets te dicen cómo arreglarlo bien.

Rasgos clave:

• Cada chuleta trata un tema (prevención de XSS, de inyección SQL, almacenamiento de contraseñas, gestión de sesiones, cabeceras de seguridad...) de forma directa y accionable, con recomendaciones concretas.
• Están escritas para desarrolladores: van al grano con el "haz esto, no hagas aquello".
• Son el complemento natural del Top Ten: cuando etiquetas un hallazgo como A03, la Cheat Sheet correspondiente te da el patrón de solución.

Para BazarNube, cuando ZAP reporta el SQL injection en /api/buscar (etiquetado A03), Lucía abre la Cheat Sheet de prevención de inyección SQL y aplica el patrón recomendado (consultas parametrizadas). Es el puente entre "detecté el problema" y "lo resolví correctamente".

En la lección 02-04 vimos que existe una familia de herramientas SCA (Software Composition Analysis) que analizan las dependencias de terceros. OWASP tiene su propia herramienta libre para esto: OWASP Dependency-Check.

¿Por qué importa tanto? Una aplicación moderna es mayoritariamente código ajeno: BazarNube arrastra cientos de paquetes npm en la API React/Node y decenas de librerías Java en el módulo legacy. Si cualquiera de ellas tiene una vulnerabilidad conocida (un CVE), la aplicación la hereda aunque tu propio código sea impecable. Esto es exactamente la categoría A06 (Componentes vulnerables y desactualizados) del Top Ten.

Qué hace Dependency-Check, a grandes rasgos:

• Lee los manifiestos de dependencias del proyecto (package.json, pom.xml, etc.).
• Los cruza con bases de datos de vulnerabilidades conocidas (CVEs públicos).
• Genera un informe con qué componentes son vulnerables, la gravedad y a qué versión actualizar.

Para BazarNube, integrar Dependency-Check en el pipeline significa recibir una alerta automática cada vez que una de sus dependencias resulta afectada por un CVE nuevo, atacando directamente el riesgo A06 sin revisión manual.

Todo lo anterior hay que practicarlo, pero probar técnicas de ataque contra la aplicación real de BazarNube (o cualquier sistema ajeno) es peligroso e ilegal. La solución de OWASP es Juice Shop: una aplicación web deliberadamente vulnerable, moderna y realista (una tienda online, muy afín a BazarNube), creada para atacarla y aprender.

• Contiene decenas de vulnerabilidades intencionadas cubriendo el Top Ten y más.
• Es un campo de tiro seguro y legal: puedes lanzar ZAP, probar payloads y seguir la WSTG sin consecuencias.
• Es ideal para formar al equipo (dominio Governance de SAMM: formación y concienciación) y para practicar antes de tocar el entorno real.

Para BazarNube, Juice Shop es donde Marc y Lucía aprenden a usar ZAP y a reconocer vulnerabilidades antes de aplicarlo a su propia API. Se usa en el módulo 8 (ejercicios y casos).

Esta es la síntesis de todo el módulo 2. Ante una necesidad concreta, ¿qué herramienta OWASP coges?

Observa el patrón que estructura toda la caja:

• Documentos/marcos (Top Ten, ASVS, SAMM, WSTG, Cheat Sheets): te dicen qué hacer y cómo pensar.
• Herramientas ejecutables (ZAP, Dependency-Check, Juice Shop): hacen o te dejan practicar.
• Y todas hablan el mismo idioma: las categorías del Top Ten (A01–A10) son el hilo que conecta un hallazgo de ZAP, un requisito de ASVS, una chuleta de remediación y una práctica de SAMM.

La clave no es elegir una herramienta, sino orquestarlas. Así encajaría un flujo realista de BazarNube, combinando casi todos los proyectos del módulo:

Narrado como lo viviría el equipo:

1. Formación: Marc y Lucía practican en Juice Shop para aprender a atacar y a usar ZAP sin riesgo.
2. Verificación estructurada: revisan la app contra la checklist ASVS L2, etiquetando cada incumplimiento con su categoría Top Ten.
3. Detección automática: ZAP escanea la API en ejecución y Dependency-Check revisa las dependencias (A06); ambos vuelcan hallazgos al backlog.
4. Pruebas manuales: con la WSTG, prueban a fondo la lógica de negocio (checkout, cupones) que la automatización no cubre.
5. Remediación: para cada hallazgo, consultan la Cheat Sheet correspondiente y aplican el patrón de solución correcto.
6. Madurez: el mero hecho de que todo esto sea sistemático hace subir la práctica de Verification de SAMM y da a dirección una foto objetiva del progreso.

El resultado: los proyectos OWASP no son ocho herramientas sueltas, sino un sistema integrado donde el Top Ten es el lenguaje común, ASVS el criterio, SAMM el termómetro, y ZAP/Dependency-Check/WSTG/Cheat Sheets/Juice Shop las manos que ejecutan.

• Buscar "la mejor herramienta". No existe: cada proyecto resuelve una necesidad distinta. La pregunta correcta no es "¿cuál uso?", sino "¿para qué la necesito ahora?".
• Olvidar las dependencias. Muchos equipos aseguran su código a conciencia y descuidan las librerías de terceros, que son la mayor parte del software. Sin SCA (Dependency-Check), el riesgo A06 queda ciego.
• Automatizarlo todo y renunciar a la prueba manual. ZAP no ve la lógica de negocio; la WSTG guía la prueba manual que sí la ve. Ambas son necesarias.
• Practicar técnicas de ataque contra sistemas reales o ajenos. Es peligroso e ilegal. Para eso está Juice Shop: un entorno diseñado para ser atacado.
• Consejo: interioriza que las categorías del Top Ten son el pegamento de toda la caja. Si etiquetas cada hallazgo con su A0x, todo lo demás (ASVS, Cheat Sheets, informes de ZAP) encaja solo.

Ejercicio 1. Empareja cada necesidad de BazarNube con el proyecto OWASP más adecuado: (a) "quiero una guía paso a paso para probar manualmente la lógica del carrito"; (b) "ZAP marcó un XSS y necesito el patrón de remediación correcto"; (c) "quiero saber si alguna librería npm tiene un CVE"; (d) "necesito un entorno para que el equipo practique ataques sin riesgo".

Ejercicio 2. Explica en 3–4 líneas por qué Dependency-Check (SCA) es imprescindible aunque BazarNube haga revisiones de código muy rigurosas de su propio código.

Ejercicio 3. Diseña, en 5–6 pasos, un flujo de trabajo que combine al menos cuatro proyectos OWASP del módulo para llevar un hallazgo desde su detección hasta su corrección verificada, indicando qué aporta cada uno.

Solución 1. (a) WSTG (metodología de testing paso a paso, ideal para lógica de negocio); (b) Cheat Sheet Series (guías de remediación concretas); (c) Dependency-Check (SCA sobre dependencias y CVEs, riesgo A06); (d) Juice Shop (aplicación deliberadamente vulnerable para practicar).

Solución 2. Porque la mayor parte del software que ejecuta BazarNube no es código propio, sino cientos de dependencias de terceros. Una revisión impecable del código propio no detecta una vulnerabilidad conocida (CVE) en una librería npm o Java que la aplicación hereda. Dependency-Check cruza automáticamente esas dependencias con bases de datos de vulnerabilidades y avisa, cubriendo el riesgo A06 que la revisión manual de código propio deja ciego.

Solución 3. Un flujo posible: (1) Juice Shop — el equipo se forma practicando ataques sin riesgo; (2) ASVS — se revisa la app contra la checklist L2 y aparece un requisito de control de acceso como "REVISAR"; (3) ZAP — un escaneo dinámico confirma un IDOR en /api/pedidos/:id, que se vuelca al backlog etiquetado como A01 (Top Ten); (4) Cheat Sheet Series — se consulta la chuleta de control de acceso/autorización para aplicar el patrón correcto (verificar propiedad del recurso en servidor); (5) se corrige el código; (6) se re-escanea con ZAP para verificar que el hallazgo desaparece y se marca el requisito ASVS como CUMPLE, lo que a su vez sube la práctica de Verification de SAMM. Aportes: Top Ten (lenguaje/priorización), ASVS (criterio verificable), ZAP (detección y verificación), Cheat Sheets (remediación), SAMM (madurez), Juice Shop (formación).

Has completado la caja de herramientas de OWASP. Más allá de los cuatro flagship (Top Ten, ASVS, SAMM, ZAP), conoces ahora WSTG (metodología de testing exhaustiva), la Cheat Sheet Series (remediación accionable), Dependency-Check (SCA para el riesgo A06 de componentes vulnerables) y Juice Shop (entorno seguro para practicar). Y, lo más importante, has aprendido a combinarlos: no son piezas sueltas, sino un sistema integrado donde las categorías del Top Ten actúan de lenguaje común que conecta detección, verificación, remediación y madurez.

Con esto cerramos el módulo 2: BazarNube ya tiene elegida su caja de herramientas y sabe para qué sirve cada una. Pero conocerlas por encima no basta; toca empuñar la primera y a fondo. En el módulo 3 nos sumergimos en el OWASP Top Ten 2021 en profundidad, recorriendo una a una las categorías A01 a A10 (más XSS y XXE): qué son exactamente, cómo se ven en el código de BazarNube y cómo se remedian. El vocabulario que hoy solo hemos nombrado se convertirá, categoría a categoría, en conocimiento operativo.