Tenemos la línea base de BazarNube: un scorecard honesto que dice dónde está cada práctica. Pero un scorecard que se guarda en un cajón no mejora nada. El verdadero valor de SAMM aparece ahora, en el ciclo de mejora continua: fijar hacia dónde queremos ir, trazar el camino en fases realistas, priorizar por riesgo, ejecutar, medir y volver a evaluar. En esta última lección del módulo aprendemos a definir un objetivo de madurez, a construir un roadmap por iteraciones y a cerrar el ciclo. Lo aplicamos con un roadmap completo de BazarNube que lleva de su línea base a un objetivo alcanzable. Y con eso cerramos la estrategia para dar paso a las herramientas.

1. El ciclo de mejora continua de SAMM
2. Definir el objetivo de madurez (basado en riesgo)
3. Calcular brechas y priorizar
4. Construir un roadmap por iteraciones
5. Roadmap de BazarNube: de la línea base al objetivo
6. Medir el progreso y reevaluar
7. Del programa de madurez a las herramientas: puente al módulo 6

SAMM no es un proyecto con final; es un bucle que se repite indefinidamente. Cada vuelta deja a la organización un poco más madura y produce un nuevo scorecard comparable con el anterior.

Ya completamos la primera casilla (evaluar, en 05-03). Esta lección recorre el resto del bucle. La cadencia habitual es reevaluar cada 6-12 meses: suficiente para que las mejoras cuajen, sin perder el pulso.

El primer error a evitar es querer "sacar todo a 3". SAMM es basado en riesgo: el objetivo de cada práctica depende de cuánto riesgo aporta al negocio, no de un ideal. Fijar el objetivo es una conversación entre AppSec, CTO y Product.

Criterios para elegir el objetivo de cada práctica:

• Riesgo del negocio: BazarNube maneja pagos y datos personales; las prácticas ligadas a eso (protección de datos, secure deployment, incident management) piden objetivo más alto.
• Exigencias externas: clientes enterprise y PCI-DSS empujan Governance y Verification.
• Coste/beneficio: subir de 0 a 1 suele ser barato y muy rentable; de 2 a 3, caro y solo justificado donde el riesgo lo exige.
• Realismo: un objetivo alcanzable en 12 meses motiva; uno inalcanzable desmoraliza.

Para BazarNube, el comité fija un objetivo global razonable de "nivel 2 en las prácticas clave", dejando algunas en 1 (suficiente para su riesgo actual) y reservando el 3 para más adelante. No todo sube; sube lo que importa.

La brecha de una práctica es simplemente objetivo − nivel actual. Las brechas ordenan el trabajo, pero no basta con atacar la mayor: hay que cruzarlas con riesgo y esfuerzo.

Matriz de priorización sencilla:

Las mejoras 0→1 suelen ser "quick wins": baratas, rápidas y con gran salto relativo. Conviene ponerlas pronto para generar impulso y credibilidad ante dirección.

Un roadmap SAMM reparte las mejoras en fases (iteraciones), cada una con objetivos concretos, prácticas a mover, responsable y horizonte temporal. No se hace todo a la vez: cada fase es una vuelta pequeña del bucle.

Buenas prácticas al planificar el roadmap:

• Pocas prácticas por fase: 3-5 movimientos por iteración, no quince.
• Empezar por quick wins y riesgo alto: motiva y reduce lo más peligroso primero.
• Un responsable por mejora: reutiliza los owners de función (05-02).
• Acciones concretas: no "mejorar formación", sino "onboarding de seguridad obligatorio + 2 champions".
• Recordar que el "cómo" es del módulo 7: el roadmap dice qué práctica subir; ejecutar el threat modeling, el pipeline DevSecOps o el plan de concienciación es contenido del módulo 7. SAMM planifica; M7 hace.

Partimos del scorecard de 05-03. Este es el roadmap a 12 meses en tres fases. La columna "Actual → Objetivo" usa la línea base de la lección anterior.

Fase 1 (meses 0-4) — Quick wins y cultura

Fase 2 (meses 4-8) — Gobierno y verificación

Fase 3 (meses 8-12) — Consolidar operaciones y datos

Prácticas que se dejan en su nivel actual esta vuelta (objetivo = actual), por riesgo/coste: Policy & Compliance (1), Security Architecture (1), Defect Management (1). Se revisarán en el siguiente ciclo. Y las que ya están en 2 (Security Requirements, Requirements-driven Testing, herencia del módulo 4) se mantienen, no se dejan degradar.

Representación compacta del roadmap en pseudo-YAML, útil para versionarlo junto al repo:

Un roadmap sin medición es una lista de buenos deseos. Para cerrar el bucle:

• Definir la métrica de éxito por mejora: no "mejoramos el build", sino "el 100% de los servicios ejecutan SCA en CI". Medible y binario cuando sea posible.
• Revisar el avance en cada fase: al final de cada iteración, comprobar qué prácticas alcanzaron su objetivo.
• Reevaluar el scorecard completo cada 6-12 meses: repetir la autoevaluación de 05-03 y comparar con la línea base. La comparación es la métrica reina: enseña la tendencia y justifica la inversión ante dirección.
• Ajustar el siguiente ciclo: subir objetivos donde se llegó, replanificar donde no, incorporar nuevos riesgos.

Ejemplo de cómo se vería el progreso de BazarNube tras la Fase 1 (media por función):

Pequeños pasos, pero medibles y en la dirección correcta. Eso es exactamente lo que SAMM busca: no un salto heroico, sino una curva ascendente sostenida.

Con esta lección cerramos el módulo 5 y, con él, la parte estratégica y de gobierno del curso. Hagamos balance del recorrido: BazarNube aprendió a verificar su aplicación (ASVS, M4) y a medir y madurar su organización (SAMM, M5). Ya sabe qué quiere conseguir y cómo de maduro es su programa de seguridad.

Fíjate en un detalle del roadmap: varias mejoras (Fase 2, Security Testing 1→2; Fase 1, Secure Build) hablan de ejecutar pruebas de seguridad de forma sistemática. Ahí es donde la estrategia toca el suelo: para subir esas prácticas hacen falta herramientas concretas que encuentren vulnerabilidades reales en la aplicación. Hemos definido el qué y el cuánto; toca el con qué.

Ese es el salto al módulo 6, OWASP ZAP. Pasamos de la estrategia y la madurez organizativa a una herramienta concreta de prueba dinámica (DAST): ZAP, el proxy de interceptación de OWASP con el que BazarNube podrá escanear su aplicación en busca de vulnerabilidades y automatizar parte de la verificación que SAMM le pide madurar. De medir el programa, a probar la aplicación con herramientas. Empezamos por ZAP.

• Querer subir todo a 3. SAMM es basado en riesgo: sube lo que el negocio necesita y difiere el resto. Un objetivo realista motiva; uno imposible paraliza.
• Planificar sin priorizar por riesgo. La brecha más grande no siempre es la primera; hay que cruzarla con el riesgo del activo y el coste.
• Roadmap sin responsables ni métricas. Cada mejora necesita un owner y un criterio de éxito medible, o no se ejecuta ni se comprueba.
• No reevaluar. Sin repetir el scorecard y compararlo con la línea base, SAMM pierde todo su valor: se queda en foto, no en película.
• Meter demasiado en una fase. 3-5 movimientos por iteración; el exceso garantiza que nada se termine.
• Consejo: empieza cada ciclo por uno o dos quick wins (0→1). El impulso temprano y visible facilita el apoyo de dirección para lo más caro.

Ejercicio 1. Para estas tres prácticas de BazarNube, calcula la brecha y ordénalas de mayor a menor prioridad justificando con riesgo y esfuerzo: (a) Education & Guidance, actual 0, objetivo 1. (b) Security Architecture, actual 1, objetivo 1. (c) Secure Deployment (gestión de secretos), actual 1, objetivo 2, sobre un sistema que maneja pagos.

Ejercicio 2. Diseña una Fase 1 de roadmap (3 mejoras) para una organización distinta cuyo punto más débil sea Operations (todo en 0-1). Indica práctica, actual→objetivo, una acción concreta y un owner plausible.

Ejercicio 3. El CTO pregunta: "¿Cómo sabré dentro de un año si SAMM ha servido para algo?". Responde en 3-4 frases explicando qué medirías y cómo.

Solución 1. Brechas: (a) 1, (b) 0, (c) 1. Orden de prioridad: 1º (c) Secure Deployment — brecha 1 pero sobre pagos (riesgo alto), un secreto expuesto es crítico; 2º (a) Education & Guidance — brecha 1, es un quick win 0→1 barato y con gran impacto cultural; 3º (b) Security Architecture — brecha 0, ya está en su objetivo, no requiere acción este ciclo. La prioridad la marca el riesgo (c) por encima del tamaño de brecha, que en (a) y (c) es igual.

Solución 2. Ejemplo válido: (1) Incident Management 0→1: montar detección básica de incidentes con alertas y un canal de guardia — owner SRE. (2) Environment Management 1→2: definir una política de parcheo con calendario y responsables — owner SRE. (3) Operational Management 0→1: inventariar datos sensibles y aplicar backups cifrados — owner SRE/DPO. (Cualquier combinación de 3 prácticas de Operations con acciones concretas y owner plausible es correcta.)

Solución 3. "Repetiría la autoevaluación SAMM al cabo de un año y compararía el nuevo scorecard con la línea base de hoy: si las prácticas del roadmap han subido de nivel, SAMM ha servido. Además comprobaría las métricas concretas de cada mejora (p. ej. % de servicios con SCA en CI, existencia de un plan de incidentes probado). Lo que importa es la tendencia medible respecto a nosotros mismos, no una nota absoluta."

Hemos cerrado el ciclo de SAMM: evaluar → objetivo → priorizar → roadmap → ejecutar → medir → reevaluar. Con un objetivo basado en riesgo, un roadmap por fases con owners y métricas, y un compromiso de reevaluación semestral, BazarNube convierte su scorecard estático en una curva de mejora continua. Con esto termina el módulo 5: la organización ya sabe verificar su producto (ASVS) y medir y madurar su programa de seguridad (SAMM). Cierra así el bloque estratégico del curso. En el módulo 6 bajamos de la estrategia a la práctica con OWASP ZAP, la herramienta de prueba dinámica con la que BazarNube empezará a encontrar y automatizar la detección de vulnerabilidades reales en su aplicación.