Cerramos el módulo 4 con una pregunta que el ASVS no responde: "¿es capaz nuestra organización de producir aplicaciones seguras de forma repetible y de mejorar esa capacidad con el tiempo?". BazarNube ya sabe verificar su producto por niveles y con evidencias, pero eso no garantiza que el equipo tenga buenos procesos de formación, de gestión de proveedores, de respuesta a incidentes o de mejora continua. En este módulo damos ese salto: dejamos de mirar la aplicación para mirar el programa de seguridad de la organización. La herramienta para hacerlo es OWASP SAMM. En esta primera lección veremos qué es, para qué sirve, en qué se diferencia del ASVS y cómo BazarNube decide adoptarlo.

1. Qué es SAMM y qué problema resuelve
2. Propósito: medir para poder mejorar
3. Un modelo agnóstico e iterativo
4. Estructura general de SAMM a alto nivel
5. SAMM (organización) vs. ASVS (aplicación): el contraste clave
6. Para quién sirve SAMM y quién lo usa
7. Cómo BazarNube decide adoptar SAMM

SAMM son las siglas de Software Assurance Maturity Model (Modelo de Madurez del Aseguramiento de Software), un proyecto insignia de OWASP. Es un marco para evaluar, formular y mejorar la estrategia de seguridad de software de una organización de manera medible.

La palabra clave es madurez. SAMM no verifica si una aplicación concreta es segura; describe cómo de maduras son las prácticas de seguridad de la organización que construye software: si existen, si están documentadas, si se aplican de forma consistente y si se optimizan con datos.

El problema que resuelve es muy real y BazarNube ya lo vive. Tras el módulo 4 el equipo sabe verificar una app, pero:

• No hay una forma objetiva de responder "¿estamos mejorando o solo apagando fuegos?".
• El CTO no puede comparar el estado de seguridad de hoy con el de hace seis meses.
• Cada equipo hace las cosas a su manera; lo que funcionó en un proyecto no se repite en el siguiente.
• No hay un plan compartido de hacia dónde debe crecer la capacidad de seguridad.

SAMM aporta un lenguaje común y una regla de medir para responder a todo eso.

El propósito de SAMM se resume en un ciclo: evaluar → definir objetivos → mejorar → medir de nuevo. No es un certificado ni una auditoría de aprobado/suspenso; es un instrumento de gestión que persigue tres cosas:

• Evaluar el estado actual de las prácticas de seguridad de forma objetiva y repetible.
• Definir un objetivo de madurez alcanzable y alineado con el riesgo del negocio.
• Medir el progreso a lo largo del tiempo con una métrica comparable.

La idea de fondo es que no se puede mejorar lo que no se mide. Si BazarNube quiere convencer a su CTO de invertir en seguridad, necesita una foto medible de dónde está y una hoja de ruta hacia dónde quiere estar. Eso es exactamente lo que produce SAMM: un scorecard (que veremos en 05-03) y un roadmap (05-04).

Dos propiedades hacen a SAMM aplicable a casi cualquier organización:

• Agnóstico: no impone tecnología, metodología ni tamaño. Funciona igual para un equipo ágil de cinco personas que para una multinacional en cascada, con cualquier lenguaje o nube. No dice "usa esta herramienta", sino "asegúrate de que esta capacidad existe y madura". Esto encaja con el stack heterogéneo de BazarNube (React, Node/Express, Java/Spring legacy, PostgreSQL en Docker): SAMM no juzga el stack, juzga el proceso.
• Iterativo e incremental: no se adopta "de golpe". Se evalúa, se elige un objetivo modesto, se ejecuta una iteración, se reevalúa y se repite. La madurez sube por peldaños, no por saltos heroicos.

Además, SAMM está basado en riesgo: no todas las organizaciones necesitan el nivel máximo en todo. El objetivo se ajusta al perfil de riesgo del negocio, no a un ideal abstracto.

SAMM (en su versión 2) se organiza en tres piezas encajadas que iremos desgranando en las próximas lecciones:

• 5 funciones de negocio (business functions): los grandes bloques de actividad de cualquier organización que hace software: Governance, Design, Implementation, Verification y Operations.
• Prácticas de seguridad (security practices): cada función agrupa tres prácticas (15 en total). Cada práctica se divide además en dos flujos (streams) que representan dos objetivos complementarios de esa práctica.
• Niveles de madurez: cada práctica se puntúa en una escala de 0 a 3, donde 0 es "no se hace", 1 es una práctica inicial, 2 una práctica estructurada y consistente, y 3 una práctica optimizada con datos.

A alto nivel, evaluar la organización con SAMM consiste en recorrer las 15 prácticas, situar cada una en su nivel de madurez y obtener una foto completa. El detalle de las funciones y prácticas va en 05-02; el de los niveles y la evaluación, en 05-03.

Este es el punto que conecta con el módulo 4 y conviene fijar bien. ASVS y SAMM son ambos de OWASP y se complementan, pero responden a preguntas distintas:

Una metáfora útil: el ASVS es el examen del alumno; SAMM es el sistema de calidad de la escuela. Aprobar el examen (ASVS L2 hoy) no significa que la escuela forme bien de manera repetible. Una empresa puede pasar una auditoría L2 en un proyecto y, sin madurez de proceso detrás, acumular deuda de seguridad en el siguiente. Por eso son complementarios: SAMM te dice si tu organización es capaz de generar apps que pasen el ASVS de forma sistemática. Uno no sustituye al otro.

SAMM está pensado para roles que miran la seguridad de arriba, no solo desde el código:

• Dirección técnica (CTO, CISO): para tener una foto ejecutiva del riesgo de proceso y justificar inversión.
• Responsables de seguridad / AppSec: para dirigir la evaluación, mantener el scorecard y diseñar el roadmap.
• Líderes de equipo (como Lucía): para entender qué prácticas les tocan y cómo madurarlas.
• Product y negocio: para entender que la seguridad es una capacidad que se construye por fases, con coste y retorno.
• Auditores y clientes: como marco compartido para hablar de madurez, no solo de cumplimiento.

Es habitual que una persona actúe de facilitador de la evaluación (en BazarNube, el rol AppSec que el alumno encarna) entrevistando a los responsables de cada función.

Con el módulo 4 recién cerrado, el CTO de BazarNube plantea la pregunta incómoda en un comité: "El pentest salió razonablemente bien, pero ¿cómo sé que no volveremos a tropezar con lo mismo dentro de seis meses?". Nadie tiene una respuesta medible. Esa es la señal de que hace falta SAMM.

El equipo decide adoptarlo con un enfoque realista:

1. Motivación: pasar de "verificamos la app" a "sabemos si nuestra organización mejora". Dar al CTO una métrica comparable en el tiempo.
2. Alcance inicial: toda la unidad de producto de BazarNube (los equipos de Lucía y Marc, la SRE y las funciones de organización), no un solo proyecto.
3. Facilitador: el rol AppSec (tú) dirige la primera autoevaluación entrevistando a los responsables de cada función.
4. Cadencia: una autoevaluación ahora (línea base) y reevaluaciones semestrales.
5. Entregables esperados: un scorecard inicial (05-03) y un roadmap por iteraciones hacia un objetivo de madurez (05-04).

Con esta decisión, BazarNube deja de medir solo su producto y empieza a medir su capacidad de producir productos seguros.

• Confundir SAMM con ASVS. SAMM mide la organización y sus procesos; ASVS verifica la aplicación. Usar uno esperando lo del otro lleva a conclusiones falsas.
• Tratar SAMM como una certificación de aprobado/suspenso. No lo es: es un instrumento de mejora continua. La cifra importa por su tendencia, no por si "aprueba".
• Aspirar al nivel 3 en todo desde el principio. SAMM es basado en riesgo e iterativo; el objetivo se ajusta al negocio y se sube por peldaños.
• Evaluar solo con el equipo técnico. Funciones como Governance u Operations dependen de dirección, SRE y negocio; hay que entrevistar a esos roles.
• Adoptar SAMM sin un facilitador claro. Sin alguien que dirija la evaluación y mantenga el scorecard, el ejercicio se diluye.
• Consejo: empieza por una autoevaluación honesta aunque duela. Una línea base baja pero real es mucho más útil que una foto optimista.

Ejercicio 1. Para cada afirmación, indica si corresponde a SAMM o a ASVS y por qué: (a) "El módulo de pagos cumple el requisito V9.1.1 de TLS". (b) "Nuestra práctica de formación de desarrolladores está en madurez 1". (c) "Queremos comparar nuestro estado de seguridad de enero con el de julio". (d) "El pentester verificó los controles de autorización de la app".

Ejercicio 2. El CTO de BazarNube dice: "Ya pasamos la verificación ASVS L2, ¿para qué necesitamos SAMM?". Redacta una respuesta breve (3-4 frases) que explique la diferencia y por qué son complementarios.

Ejercicio 3. Enumera las 5 funciones de negocio de SAMM y, sin desarrollarlas aún, escribe en una frase qué gran área de la organización crees que cubre cada una.

Solución 1. (a) ASVS: verifica un requisito técnico concreto de la aplicación. (b) SAMM: describe la madurez de una práctica de la organización en la escala 0–3. (c) SAMM: comparar el estado en el tiempo es medir madurez de proceso, no verificar un producto. (d) ASVS: verificación técnica de los controles de una app concreta.

Solución 2. "El ASVS L2 nos dice que esta aplicación cumple hoy; no nos dice si sabemos repetirlo en el próximo proyecto ni si mejoramos con el tiempo. SAMM mide la madurez de nuestros procesos (formación, diseño, respuesta a incidentes...) con una métrica comparable semestre a semestre. Son complementarios: SAMM asegura que nuestra organización es capaz de producir apps que pasen el ASVS de forma sistemática, no por suerte."

Solución 3. Governance (gobierno: estrategia, políticas y formación), Design (diseño: amenazas, requisitos y arquitectura de seguridad), Implementation (construcción: build seguro, despliegue y gestión de defectos), Verification (verificación: revisión de arquitectura y pruebas de seguridad), Operations (operación: incidentes y gestión del entorno). Cualquier redacción razonable que asocie cada función a su área es válida; el detalle exacto llega en la próxima lección.

SAMM es el instrumento con el que BazarNube pasa de verificar su aplicación (ASVS, módulo 4) a medir y madurar el programa de seguridad de su organización. Es un modelo agnóstico (no impone tecnología), iterativo (se sube por peldaños) y basado en riesgo (el objetivo se ajusta al negocio), estructurado en 5 funciones de negocio, 15 prácticas de seguridad y niveles de madurez de 0 a 3. Frente al ASVS, que responde "¿es segura esta app?", SAMM responde "¿sabemos producir apps seguras de forma repetible?". Con la decisión de adoptarlo tomada, en la próxima lección abrimos la caja: recorreremos las 5 funciones de negocio y sus prácticas de seguridad una a una, y veremos quién es responsable de cada una en BazarNube.