A lo largo del módulo han aparecido, casi de pasada, muchos nombres propios: Semgrep marcando una inyección, gitleaks bloqueando un secreto, trivy escaneando una imagen, ZAP en staging, las Cheat Sheets como material de formación. Han ido saliendo cada uno en su contexto —el pipeline, el threat model, la capacitación— pero nunca los hemos visto juntos y ordenados. Esta última lección del módulo hace justamente eso: presenta un panorama de herramientas por categoría, cataloga los recursos de OWASP para seguir aprendiendo, y consolida todo en un stack de seguridad recomendado para BazarNube. Es el mapa que llevaremos a los ejercicios y casos de estudio del módulo 8.

1. Cómo elegir herramientas: el criterio antes que el catálogo
2. Panorama de herramientas por categoría
3. Recursos OWASP para seguir aprendiendo
4. Comunidades y cómo mantenerse al día
5. El stack de seguridad recomendado para BazarNube
6. Errores comunes y consejos
7. Ejercicios
8. Conclusión

Antes del catálogo, una advertencia que recorre todo el módulo: las herramientas son medios, no fines. Un pipeline lleno de escáneres sin proceso ni dueños genera ruido, no seguridad (lo vimos en 07-01 y 07-03). Al elegir, valora:

• Integración: ¿encaja en el pipeline y en el IDE del equipo? Una herramienta que no se integra no se usa.
• Relación señal/ruido: ¿cuántos falsos positivos genera? El ruido mata la adopción.
• Cobertura frente a tu riesgo: prioriza lo que cubre tus amenazas reales (las de tu threat model), no lo que está de moda.
• Coste total: licencia, mantenimiento y tiempo de triaje.
• Open source vs comercial: el open source (muchos proyectos OWASP) es ideal para empezar y aprender; el comercial suele añadir menos ruido, soporte y gestión centralizada a cambio de coste.

Cada categoría corresponde a un control del pipeline DevSecOps de 07-03. Los ejemplos incluyen opciones open source y comerciales; no es una lista exhaustiva ni un ranking, sino puntos de partida reconocidos.

Notas de lectura:

• OWASP ZAP es el DAST de referencia del curso; su uso lo cubrimos a fondo en el módulo 6, aquí solo lo situamos en el panorama.
• OWASP Dependency-Check y Dependency-Track son la opción OWASP para SCA: el primero escanea, el segundo gestiona el inventario de componentes (SBOM) de forma continua, muy útil contra A06.
• Semgrep destaca en SAST por su bajo ruido y por permitir escribir reglas propias fáciles de mantener (security as code).
• trivy es versátil: cubre contenedores, IaC y dependencias, lo que reduce el número de herramientas distintas a mantener.

OWASP es mucho más que el Top Ten. Estos son los recursos que conviene conocer y a los que volver:

Las Cheat Sheets merecen mención especial como recurso del día a día: cuando un desarrollador tiene que implementar autenticación, subida de ficheros o prevención de XSS, hay una hoja concisa con las recomendaciones concretas. Son el complemento natural del secure coding de 07-04.

La seguridad evoluciona constantemente: nuevas vulnerabilidades, nuevas técnicas, nuevas versiones de los propios estándares. Mantenerse al día es parte del trabajo:

• Capítulos locales de OWASP: reuniones presenciales/online, charlas y networking. Participar es una de las mejores formas de aprender y de encontrar mentores.
• Proyectos OWASP en GitHub: seguir y contribuir a los proyectos que usas.
• Boletines de vulnerabilidades: CISA KEV, avisos de los proveedores de tus dependencias, GitHub Security Advisories.
• Conferencias: OWASP Global AppSec y eventos regionales; muchas charlas quedan grabadas y en abierto.
• Formación y certificaciones: retomaremos las opciones de certificación en el módulo 9.

Un hábito sencillo y de alto retorno: dedicar un rato fijo a la semana a leer una Cheat Sheet nueva o el writeup de una vulnerabilidad reciente. La consistencia supera a los atracones.

Reuniendo todo el módulo, este es el stack que Lucía, la SRE y los champions consolidan para BazarNube. Está deliberadamente sesgado hacia open source y proyectos OWASP: cubre el riesgo real con coste contenido y encaja en el pipeline de 07-03.

Este stack no es definitivo ni universal: es el punto de partida coherente para este producto y esta madurez. Conforme BazarNube suba de nivel en SAMM, incorporará piezas (gestión centralizada, quizá una herramienta comercial de menor ruido) y retirará las que no aporten. La herramienta correcta es la que tu equipo usa, entiende y mantiene.

• Comprar herramientas antes que definir el proceso. Un escáner caro sin dueños ni gates es dinero tirado. Primero el S-SDLC y las personas (07-01, 07-04), luego las herramientas.
• Solapar herramientas que hacen lo mismo. Tres SAST distintos triplican el ruido y el triaje sin triplicar el valor. Elige una por categoría y domínala antes de sumar otra.
• Ignorar el mantenimiento. Las herramientas necesitan actualizar reglas y bases de CVE; una desactualizada da falsa sensación de seguridad.
• Perseguir la última moda. Elige por tu riesgo real (tu threat model), no por lo que se anuncia en la última conferencia.
• Consejo: empieza con el stack open source mínimo que cubra tus controles críticos, mídelo, y solo entonces evalúa si un producto comercial reduce lo suficiente el ruido o el esfuerzo como para justificar su coste.

Ejercicio 1. Asigna la herramienta adecuada a cada necesidad: (a) detectar una clave AWS en un commit, (b) encontrar una librería de Node con un CVE crítico, (c) comprobar que un bucket de Terraform no es público, (d) atacar el login de staging.

Ejercicio 2. BazarNube tiene presupuesto para una herramienta comercial. ¿Qué criterio usarías para decidir en qué categoría invertirlo, y qué preguntarías antes de comprar?

Ejercicio 3. Un compañero propone añadir un segundo SAST "para tener más cobertura". Argumenta a favor o en contra en términos de señal/ruido y mantenimiento.

Solución 1.

• (a) gitleaks (secret scanning).
• (b) OWASP Dependency-Check (SCA).
• (c) trivy o Checkov (IaC scanning).
• (d) OWASP ZAP (DAST).

Solución 2. El criterio es dónde el open source deja más valor sin capturar para el riesgo de BazarNube: normalmente donde el ruido o el esfuerzo de triaje sean mayores, o donde falte gestión centralizada. Antes de comprar preguntaría: ¿reduce de verdad los falsos positivos frente a lo que ya tengo?, ¿se integra en mi pipeline e IDE?, ¿cuál es el coste total (licencia + mantenimiento + triaje)?, ¿aporta gestión/reporting que hoy me falta? Se compra por reducción medible de ruido o esfuerzo, no por marca.

Solución 3. En contra, en general: un segundo SAST solapa gran parte de la cobertura del primero pero duplica el ruido (dos colas de falsos positivos que triar) y el mantenimiento (dos motores de reglas que actualizar), erosionando la adopción por fatiga de alertas. Es preferible profundizar en un SAST —afinar y escribir reglas propias— antes que sumar otro. Solo tendría sentido un segundo si cubriera un lenguaje o clase de fallo que el primero demostrablemente no cubre.

Con este panorama de herramientas por categoría, el catálogo de recursos OWASP y el stack recomendado para BazarNube, cerramos el módulo de buenas prácticas. A lo largo de estas cinco lecciones hemos ensamblado el proceso completo: un S-SDLC que distribuye la seguridad por fases, el modelado de amenazas que la siembra en el diseño, DevSecOps que la automatiza en el pipeline, la capacitación que sostiene el factor humano, y ahora las herramientas y recursos que lo hacen posible. La seguridad ha dejado de ser una fase final para convertirse en una propiedad continua del proceso y de la cultura, tal como prometía el cierre del módulo 6. Todo ello descansa sobre lo aprendido antes: el Top Ten como catálogo, ASVS como requisitos, SAMM como madurez y ZAP como verificación. Llega el momento de ponerlo en práctica. En el módulo 8 dejamos la teoría y trabajamos con las manos: dos ejercicios prácticos y dos casos de estudio donde aplicarás, sobre BazarNube, todo lo que has integrado en estas lecciones.