Ya conocemos la rejilla de SAMM: 5 funciones, 15 prácticas y 2 flujos por práctica. Ahora toca medir. La evaluación de madurez es el corazón de SAMM: convierte una intuición ("creo que estamos flojos en pruebas de seguridad") en un dato comparable ("Security Testing está en madurez 1"). En esta lección explicamos qué significan los niveles 0 a 3, cómo se hace una autoevaluación práctica por práctica mediante preguntas, cómo se construye un scorecard y cómo interpretarlo. Y lo aplicamos: haremos la autoevaluación real de BazarNube con su scorecard completo, que será la línea base para el roadmap de la próxima lección.

1. Los niveles de madurez: de 0 a 3
2. Cómo se puntúa: flujos, preguntas y respuestas
3. El proceso de autoevaluación paso a paso
4. Anatomía de un scorecard
5. Autoevaluación de BazarNube: scorecard completo
6. Interpretar los resultados

Cada práctica de SAMM se sitúa en una escala común de cuatro peldaños. La idea es la misma para las 15 prácticas: describe cuánto y cómo de bien se hace algo, no si está "bien" o "mal".

Claves para no equivocarse al puntuar:

• Los niveles son acumulativos: para estar en 2 hay que cumplir lo de 1; para estar en 3, lo de 2.
• La escala mide cobertura y consistencia, no esfuerzo. Hacer algo heroico una vez sigue siendo nivel 1.
• SAMM admite puntuaciones fraccionarias (p. ej. 1.5) cuando una práctica se cumple parcialmente o solo en algunos equipos. Es normal y útil.
• El objetivo no es llegar a 3 en todo. El nivel deseable depende del riesgo del negocio (lo veremos en 05-04).

SAMM aporta un toolbox (una hoja de cálculo oficial) con preguntas de evaluación para cada práctica. Cada práctica tiene dos flujos, y cada flujo se explora con preguntas cuya respuesta se gradúa. El resultado de las respuestas determina el nivel de la práctica.

Las respuestas suelen seguir una escala tipo:

• No (no se hace) → aporta 0.
• Sí, parcialmente / para algunos equipos → aporta un valor intermedio.
• Sí, para la mayoría → aporta más.
• Sí, plenamente y de forma consistente → aporta el máximo.

Ejemplo de preguntas para la práctica Education & Guidance (Governance):

Con respuestas mayoritariamente "No" o "a veces", esta práctica se sitúa en madurez 0-1. La lógica es la misma para las 15 prácticas: se responden las preguntas de sus dos flujos y se deriva el nivel.

Una autoevaluación SAMM bien hecha sigue estos pasos:

1. Definir el alcance: qué parte de la organización se evalúa (en BazarNube, toda la unidad de producto).
2. Elegir facilitador: alguien que dirige y mantiene la neutralidad (el rol AppSec).
3. Recoger evidencias: no puntuar de memoria; buscar pruebas (pipelines, políticas, tickets, actas).
4. Entrevistar a los owners: cada función tiene su responsable (05-02); se le pregunta sobre sus prácticas.
5. Responder las preguntas de cada flujo con honestidad.
6. Asignar el nivel de cada práctica (0-3, admitiendo fracciones).
7. Consolidar todo en un scorecard.

Regla de oro: evaluar con evidencias, no con optimismo. Si nadie puede enseñar la política, la política no existe a efectos de madurez.

El scorecard es el entregable de la evaluación: una tabla con las 15 prácticas, su nivel actual y (más tarde) su objetivo. Suele añadir una columna de evidencia y otra de comentario. Su valor es doble: da una foto ejecutiva y sirve de línea base para medir progreso en la siguiente evaluación.

Un scorecard mínimo tiene estas columnas:

• Función y Práctica: la fila que se evalúa.
• Nivel actual (0-3): el resultado de la autoevaluación.
• Evidencia: en qué se basa la puntuación.
• Objetivo y Brecha: se rellenan al planificar (05-04).

Aplicamos todo lo anterior. Tras entrevistar a Lucía (Design/Implementation), a la SRE (Operations), al CTO (Governance) y con el AppSec facilitando Verification, este es el scorecard de línea base de BazarNube (nivel actual, escala 0-3):

Puntuación media por función (promedio simple de sus tres prácticas):

Los números solo valen si se leen bien. Del scorecard de BazarNube se extrae:

• Governance es el punto más débil (0.7), arrastrado por Education & Guidance en 0. Tiene sentido: BazarNube ha invertido en verificar el producto (módulo 4) pero no en gobierno ni cultura. Es una brecha típica de equipos que empiezan por lo técnico.
• Design destaca (1.3) gracias a Security Requirements en 2, herencia directa del trabajo con ASVS. Verás que las dos prácticas más maduras (Security Requirements y Requirements-driven Testing, ambas en 2) son precisamente las que tocó el módulo 4. Coherencia del hilo: verificar la app subió esas dos prácticas, pero dejó el resto plano; justo lo que anticipábamos en 05-01.
• Verification es desigual: fuerte en pruebas dirigidas por requisitos (2) pero con Architecture Assessment en 0. Se prueba lo que se pidió, pero no se revisa el diseño.
• Operations es homogénea en 1: se hacen las cosas, pero de forma informal y reactiva, con el legacy como lastre.

Lecturas transversales útiles:

• Un 2 aislado no salva una función: Design tiene una práctica en 2 y dos en 1; la media engaña si no se mira el detalle.
• Los ceros son prioridad de atención, no necesariamente lo primero a arreglar: hay que cruzarlos con el riesgo (05-04).
• Comparar contra uno mismo, no contra un ideal: el valor de este scorecard aparecerá al reevaluar dentro de seis meses y ver la tendencia.

Importante: un scorecard no es una nota de aprobado/suspenso. Es un punto de partida honesto. Y BazarNube ahora lo tiene.

• Puntuar de memoria o con optimismo. Sin evidencia, la práctica no cuenta. Un scorecard inflado es peor que uno bajo pero real.
• Confundir "lo hicimos una vez" con nivel 2. Un acto heroico y puntual es nivel 1; el 2 exige consistencia y documentación.
• Olvidar que los niveles son acumulativos. No se puede reclamar 3 si no se cumple lo de 1 y 2.
• Mirar solo la media por función. Oculta prácticas en 0. Hay que leer práctica a práctica.
• Tratar la nota como un juicio. SAMM mide para mejorar; el número existe para compararlo consigo mismo en el tiempo.
• Consejo: usa el toolbox oficial de SAMM (la hoja de cálculo con las preguntas). Ahorra discusiones y hace la evaluación repetible entre semestres.

Ejercicio 1. Clasifica cada situación en su nivel de madurez (0, 1, 2 o 3): (a) "Cada equipo revisa dependencias como quiere, algunos no lo hacen". (b) "No existe ningún proceso de gestión de incidentes". (c) "Hay un procedimiento de respuesta a incidentes documentado, probado y con métricas que se revisan cada trimestre". (d) "Todos los equipos siguen el mismo estándar documentado de revisión de código".

Ejercicio 2. En el scorecard de BazarNube, Education & Guidance está en 0 y Security Requirements en 2. Explica por qué esa diferencia es coherente con lo que BazarNube ha hecho en los módulos anteriores.

Ejercicio 3. Elige una práctica de BazarNube que esté en nivel 1 y redacta una pregunta de evaluación cuya respuesta ayudaría a decidir si podría subir a 2. Indica qué respuesta correspondería a un 2.

Solución 1. (a) Nivel 1: se hace de forma inconsistente y depende de cada equipo. (b) Nivel 0: la práctica no existe. (c) Nivel 3: documentado, probado y medido con revisión periódica. (d) Nivel 2: consistente y documentado en toda la organización, pero sin la parte de medición/optimización que caracteriza al 3.

Solución 2. BazarNube dedicó el módulo 4 a verificar el producto con ASVS, convirtiendo requisitos de seguridad en criterios de aceptación: eso maduró Security Requirements hasta 2. Pero nunca invirtió en gobierno ni cultura: no hay plan de formación ni champions, así que Education & Guidance sigue en 0. Es la brecha esperada de un equipo que empieza por lo técnico y aún no ha madurado la organización, exactamente la motivación de adoptar SAMM.

Solución 3. Ejemplo con Secure Build (nivel 1): pregunta — "¿Se ejecuta un análisis de dependencias (SCA) de forma automática y obligatoria en el pipeline de todos los servicios, tanto npm como Maven?". Un 2 correspondería a "Sí, en todos los servicios de forma consistente y documentada"; un "solo en algunos" o "manual" seguiría siendo 1.

Ya sabemos medir: los niveles 0 a 3 describen cobertura y consistencia, la autoevaluación se hace con preguntas por flujo y evidencias, y el scorecard consolida la foto. La línea base de BazarNube revela un patrón claro: fuerte donde tocó el ASVS (requisitos y pruebas dirigidas en 2), débil en gobierno y cultura (Education & Guidance en 0), y homogéneamente inicial en operaciones. Pero una foto no mejora nada por sí sola. En la última lección del módulo daremos el paso que da sentido a todo: fijar un objetivo de madurez, construir un roadmap por iteraciones que lleve a BazarNube de esta línea base a su objetivo, priorizar las mejoras por riesgo y establecer el ciclo de reevaluación que convierte SAMM en mejora continua.