El incidente de la lección anterior fue el punto de inflexión. BazarNube entendió, del modo más caro, que apagar fuegos uno a uno no es una estrategia de seguridad: mientras un IDOR causaba una fuga, seguían vivos la SQLi del buscador, el SSRF de importación y una configuración sin cabeceras. Este caso de estudio final narra la transformación: cómo BazarNube pasa de un estado inicial inseguro y reactivo a uno maduro y proactivo, aplicando de forma integrada todo lo que hemos recorrido en el curso —Top Ten remediado, ASVS como requisitos verificables, SAMM como hoja de ruta, ZAP en el pipeline, threat modeling en el diseño y DevSecOps como pegamento—. No es una lección de conceptos nuevos, sino la síntesis de todos: el momento en que las piezas dejan de estudiarse por separado y funcionan como un programa. Al ser la última lección del módulo práctico, cierra también el arco de BazarNube y prepara la evaluación final del módulo 9.

1. El punto de partida: BazarNube en estado inseguro
2. La estrategia: de reactivo a proactivo con SAMM
3. El roadmap de transformación por fases
4. Métricas de mejora: antes y después
5. La foto final: el programa de seguridad de BazarNube
6. Errores comunes y consejos
7. Ejercicios
8. Conclusión

Antes de la transformación, la situación de BazarNube era la de tantas aplicaciones que crecen rápido sin seguridad incorporada. Un diagnóstico honesto:

Este estado no es una caricatura: es el que hizo posible el incidente de 08-03. La transformación consiste en subir cada una de estas filas de forma ordenada y sostenible.

El error habría sido lanzarse a "arreglarlo todo" sin orden. BazarNube usó OWASP SAMM (módulo 5) como brújula: primero una evaluación de madurez para saber dónde estaba, luego un objetivo realista a 12 meses, y una hoja de ruta de mejora incremental por dominios. La idea rectora, ya vista en 05-04, es que la madurez se construye por niveles, no por saltos heroicos.

El objetivo no fue "nivel 3 en todo" (irreal y probablemente innecesario), sino un nivel 2 consistente en los dominios críticos, alineado con la decisión de 07-05 de apuntar a ASVS L2, el nivel adecuado para una aplicación que maneja pagos. Coherencia entre estándares: SAMM dice cómo de maduro es el programa, ASVS dice qué debe cumplir el producto.

La transformación se organizó en tres fases trimestrales, cada una construyendo sobre la anterior.

Prioridad: eliminar el riesgo crítico existente y ganar visibilidad.

• Remediar los hallazgos críticos y altos del backlog (BZN-134, BZN-101, BZN-140, BZN-131...) con los controles de 08-02.
• Introducir la monitorización de anomalías que faltó en el incidente (03-11): alertas de tasa por usuario.
• Poner ZAP en modo baseline en el pipeline (06-04) para no introducir regresiones nuevas.
• Quick win cultural: un taller de secure coding (07-04) con el equipo, usando el propio incidente como caso.

Prioridad: que la seguridad deje de depender de héroes y pase a ser parte del flujo.

• Integrar el stack DevSecOps completo (07-03, 07-05): gitleaks, Semgrep (SAST), Dependency-Check (SCA), trivy, con gates definidos.
• Adoptar ASVS L2 como catálogo de requisitos verificables; cada historia sensible lleva sus requisitos como criterios de aceptación (M4).
• Introducir threat modeling (07-02) en el diseño de toda funcionalidad nueva con datos o dinero, empezando por el checkout.
• Nombrar Security Champions por equipo (07-04) para escalar el conocimiento.

Prioridad: consolidar, medir y mejorar de forma continua.

• ZAP autenticado/full-scan nocturno contra staging (06-04), con hallazgos al backlog ya mapeados.
• Métricas de seguridad en un panel: tiempo de remediación, cobertura de escaneo, hallazgos por severidad.
• Reevaluación SAMM para confirmar el paso a nivel 2 y fijar el objetivo del año siguiente.
• Programa de formación continuo y participación en la comunidad OWASP (07-05).

La transformación solo es creíble si se mide. Estas son las métricas que BazarNube siguió, con valores ilustrativos del antes y el después de los doce meses:

El salto más significativo no es una cifra concreta, sino el cambio de naturaleza: la seguridad pasó de medirse después del problema (número de incidentes) a medirse antes (cobertura, requisitos verificados, tiempo de remediación). Se pasó de contar incendios a medir la prevención.

Un programa de seguridad no se sostiene solo con buena ingeniería: necesita presupuesto y respaldo de la dirección, y eso exige hablar el idioma del negocio. BazarNube justificó la inversión no apelando al miedo, sino comparando el coste de la mejora con el coste de no hacerla, que el incidente de 08-03 había vuelto tangible.

La clave está en presentar la seguridad como reducción de un riesgo cuantificado, no como un gasto técnico abstracto. Cada iniciativa del roadmap se asoció a un riesgo concreto del backlog o del incidente, de modo que la dirección pudiera ver qué compraba con cada euro. Esa traducción es, a menudo, lo que separa un programa que sobrevive al primer recorte de uno que no.

Al cabo de un año, todas las piezas del curso operan juntas y de forma continua. Esta es la arquitectura del programa maduro, donde cada elemento estudiado ocupa su lugar:

Nótese el bucle: la monitorización de producción retroalimenta el threat modeling (lo que ocurre de verdad ajusta lo que imaginamos que podía ocurrir), y SAMM mide el conjunto para guiar la mejora del año siguiente. La seguridad ha dejado de ser una fase o un proyecto para convertirse en una propiedad continua del sistema y del equipo, tal como prometía el cierre del módulo 6 y consolidaba el 7.

• Querer llegar al máximo nivel de golpe. Apuntar a "ASVS L3 y SAMM 3 en todo" en un trimestre agota al equipo y fracasa. La madurez es incremental; un nivel 2 sólido supera a un nivel 3 sobre el papel.
• Comprar herramientas sin proceso ni dueños. Un pipeline lleno de escáneres sin gates ni responsables genera ruido, no seguridad (07-01, 07-05). Primero el proceso y las personas.
• No medir. Sin métricas de antes y después, la transformación es una opinión. Lo que no se mide no se puede mejorar ni defender ante la dirección.
• Descuidar la cultura. El mejor pipeline falla si el equipo ve la seguridad como un freno. Los champions y la formación (07-04) sostienen todo lo demás.
• Consejo: empieza por la fase 1 (detener la hemorragia) aunque el plan completo no esté cerrado. Reducir el riesgo crítico y ganar visibilidad genera la confianza y el margen para construir el resto sin prisas.

Ejercicio 1. Priorización. BazarNube tiene recursos para una sola iniciativa el primer mes: (a) integrar SAST, (b) remediar los 9 hallazgos críticos/altos, o (c) formar a los champions. Justifica tu elección en términos de reducción de riesgo inmediata.

Ejercicio 2. Métricas. La dirección pide "una métrica" para saber si la seguridad mejora. Propón la que elegirías, explica qué captura y qué se te escapa al reducir todo a un solo número.

Ejercicio 3. Coherencia de estándares. Explica con tus palabras la diferencia de propósito entre SAMM y ASVS en este caso, y por qué BazarNube necesita ambos y no puede sustituir uno por el otro.

Solución 1. La elección de mayor reducción de riesgo inmediata es (b) remediar los 9 hallazgos críticos/altos: son vulnerabilidades explotables ahora mismo en producción (una ya causó el incidente de 08-03), así que cerrarlas elimina riesgo real y presente. SAST (a) y champions (c) son inversiones en prevenir fallos futuros, valiosísimas a medio plazo, pero no reducen el riesgo del código ya desplegado. La secuencia correcta es la del roadmap: primero detener la hemorragia (b), luego construir el proceso (a) y la cultura (c).

Solución 2. Una buena candidata es el tiempo medio de remediación de vulnerabilidades críticas/altas: captura a la vez que las encuentras (hay algo que remediar) y que reaccionas rápido (proceso funcionando), y correlaciona bien con el riesgo real. Lo que se escapa: no dice cuántas vulnerabilidades no estás detectando (cobertura), ni la calidad del diseño, ni la cultura. Por eso un solo número orienta pero no basta; conviene acompañarlo de cobertura de escaneo y requisitos ASVS verificados. Reducir la seguridad a una métrica invita a optimizar esa métrica en vez de la seguridad.

Solución 3. SAMM mide y guía la madurez del programa: cómo de bien la organización hace seguridad (procesos, actividades, gobierno) —es una brújula de mejora organizativa—. ASVS define qué debe cumplir el producto: requisitos técnicos verificables sobre la aplicación concreta —es una lista de verificación del artefacto—. BazarNube necesita ambos porque responden a preguntas distintas: SAMM dice "¿estamos organizados para producir software seguro?" y ASVS dice "¿este software es seguro?". Un programa maduro (SAMM alto) sin requisitos verificados (ASVS) puede tener buenas intenciones y productos inseguros; y al revés, cumplir ASVS en una app sin un programa detrás no es sostenible ni se repite en la siguiente. Se complementan, no se sustituyen.

Con este caso de estudio cerramos el módulo práctico y el arco completo de BazarNube. Hemos visto la aplicación recorrer el camino entero: de un backlog lleno de vulnerabilidades del Top Ten y un incidente evitable, a un programa de seguridad maduro donde el threat modeling siembra los requisitos ASVS, DevSecOps los verifica en cada cambio, ZAP vigila en el pipeline y en producción, la monitorización detecta en minutos y SAMM guía la mejora continua año tras año. Ese es el destino al que apuntaba todo el curso desde la primera lección: la seguridad como propiedad continua del proceso y de la cultura, no como una fase ni un heroísmo puntual. Has aplicado, sobre un caso concreto, cada estándar y herramienta de OWASP que hemos estudiado. Ahora toca demostrar y consolidar lo aprendido: en el módulo 9, el último del curso, abordamos la evaluación final que verifica tus conocimientos y las vías de certificación para acreditarlos profesionalmente. Llegas a él con lo más importante ya conseguido: no solo saber qué es cada pieza, sino haberla usado.