Con el Top Ten y ASVS, el equipo de BazarNube ya sabe qué riesgos vigilar y qué requisitos verificar en la aplicación. Pero en la última reunión, la SRE plantea una pregunta que ninguna de esas dos herramientas responde: "Vale, arreglamos los hallazgos de esta versión... ¿pero como organización estamos haciendo las cosas para que esto no se repita en la siguiente? ¿Tenemos siquiera un proceso, o vamos apagando fuegos?". Esa pregunta ya no es sobre una app: es sobre la madurez de la organización produciendo software seguro. La herramienta OWASP para eso es SAMM, el Software Assurance Maturity Model. En esta lección la presentamos a alto nivel; el detalle —dominios, evaluación, mejora continua— es el contenido del módulo 5.

1. Qué es SAMM y qué mide
2. SAMM frente a ASVS: organización vs aplicación
3. La idea de dominios y niveles de madurez
4. Cómo mediría BazarNube su madurez
5. Por qué la madurez importa a una startup

El OWASP SAMM (Software Assurance Maturity Model) es un modelo de madurez para el programa de seguridad de una organización. Su objetivo no es evaluar si una aplicación es segura, sino si la forma de trabajar de la empresa produce software seguro de manera repetible y mejorable.

Sus rasgos esenciales:

• Mide procesos y prácticas, no código. Pregunta cosas como: ¿hay formación en seguridad?, ¿se hace modelado de amenazas?, ¿existe gestión de vulnerabilidades?, ¿quién responde ante un incidente?
• Es un modelo de madurez. Ofrece una escala (típicamente de 0 a 3) para cada práctica, desde "no lo hacemos" hasta "lo hacemos de forma optimizada y medida".
• Sirve para hacer una foto y trazar una hoja de ruta. No se trata de "aprobar", sino de saber dónde estás y hacia dónde mejorar, paso a paso.
• Es agnóstico de tecnología y tamaño. Vale para una startup de cinco personas o para una multinacional; cada una interpreta los niveles según su realidad.

La palabra que resume SAMM es madurez: no "¿es segura esta app?", sino "¿está la organización madura para producir apps seguras de forma sostenida?".

Este es el matiz que más cuesta al principio: SAMM y ASVS suenan parecidos pero miden cosas de planos totalmente distintos. ASVS mira hacia dentro de la aplicación; SAMM mira hacia la organización que la construye.

Analogía útil: si BazarNube fuera un restaurante, ASVS sería la inspección de un plato concreto (¿está bien cocinado, sin contaminación?), mientras que SAMM sería la evaluación de la cocina como sistema (¿hay protocolos de higiene?, ¿el personal está formado?, ¿se revisan proveedores?). Puedes cocinar un plato correcto por suerte; SAMM pregunta si tu cocina lo hará bien siempre.

SAMM organiza las prácticas de seguridad en un pequeño número de dominios (grandes áreas de actividad) que cubren el ciclo de vida completo del software. Aquí solo damos la idea general; el módulo 5 los desarrolla uno a uno.

De forma esquemática, SAMM agrupa la actividad de seguridad en cinco funciones de negocio (dominios), cada una con sus prácticas:

Sobre cada práctica, SAMM aplica una escala de madurez que, de forma simplificada, se lee así:

La idea clave: no se trata de estar en nivel 3 en todo. Una startup sana puede estar en nivel 1 en la mayoría de prácticas y eso ya es un logro. SAMM no juzga: posiciona y ayuda a priorizar en qué prácticas invertir primero.

Apliquémoslo. El equipo hace una autoevaluación rápida (una versión muy simplificada de lo que el módulo 5 formaliza). Para cada práctica, se preguntan honestamente en qué nivel están hoy:

De esta simple tabla, el equipo extrae conclusiones muy accionables:

• Su madurez media es baja (entre 0 y 1), lo cual es normal y esperable en una startup joven. No es un fracaso: es el punto de partida.
• Los huecos más urgentes están en Verification (no prueban su seguridad) y Operations (no saben qué harían ante un incidente).
• Ya tienen cimientos en Design (el mapa de riesgos) e Implementation (el backlog), sobre los que construir.
• La hoja de ruta casi se dibuja sola: introducir pruebas de seguridad (adoptar ZAP, módulo 6) subiría Verification de 0 a 1; definir un plan mínimo de respuesta subiría Operations.

Fíjate en algo importante: SAMM conecta y da sentido a las herramientas anteriores. El mapa de riesgos, el backlog etiquetado con Top Ten y la checklist ASVS no son piezas sueltas: son evidencias de madurez dentro de dominios concretos de SAMM. SAMM es el marco que convierte esfuerzos aislados en un programa coherente y con dirección.

Podría parecer que un modelo de madurez es "cosa de grandes empresas". Es justo al revés: para una startup como BazarNube, SAMM es especialmente valioso porque:

• Evita depender de héroes. Si la seguridad solo funciona porque Lucía se acuerda de revisarla, el día que Lucía no esté, se cae. La madurez consiste en que las cosas ocurran por proceso, no por personas.
• Prioriza con recursos escasos. Una startup no puede hacerlo todo. SAMM ayuda a decidir qué práctica mejorar primero para el mayor impacto.
• Da una narrativa a inversores y clientes. "Tenemos un plan de madurez de seguridad y vamos por aquí" transmite mucha más confianza que "vamos arreglando lo que salta".
• Crece contigo. El mismo modelo sirve cuando eres cinco y cuando eres cincuenta; solo cambia el nivel al que aspiras.

• Confundir SAMM con ASVS. ASVS evalúa una aplicación; SAMM evalúa la organización y sus procesos. Son complementarios: uno mira el producto, el otro la fábrica.
• Querer estar en nivel 3 en todo. Es contraproducente y carísimo. La meta no es la perfección uniforme, sino un progreso equilibrado y sostenible. Nivel 1 generalizado ya es una base sólida.
• Hacer la evaluación una sola vez. SAMM es un ciclo de mejora continua: se reevalúa periódicamente para ver el avance. Una foto única no sirve de mucho.
• Ser poco honesto en la autoevaluación. Inflar los niveles para quedar bien destruye el valor del ejercicio. El objetivo es saber dónde estás de verdad, no aprobar un examen.
• Consejo: empieza pequeño. Una autoevaluación informal de media hora, honesta, ya te da una hoja de ruta útil. No necesitas el modelo completo para obtener valor el primer día.

Ejercicio 1. Clasifica cada afirmación como propia de ASVS o de SAMM: (a) "El equipo de BazarNube realiza modelado de amenazas de forma sistemática en cada proyecto"; (b) "La aplicación almacena las contraseñas con un algoritmo de hashing fuerte"; (c) "Existe un proceso definido de respuesta a incidentes con roles asignados".

Ejercicio 2. BazarNube ha detectado que su práctica de "Pruebas de seguridad" (Verification) está en nivel 0. Propón una acción concreta que la llevaría al nivel 1 y explica con qué herramienta del curso se relaciona.

Ejercicio 3. Explica en 4–5 líneas por qué una madurez media baja (entre 0 y 1) no es motivo de alarma para una startup como BazarNube, y qué debería hacer con ese dato.

Solución 1. (a) SAMM (habla de una práctica de la organización y de su regularidad, dominio Design); (b) ASVS (es un requisito verificable sobre la aplicación); (c) SAMM (describe un proceso organizativo, dominio Operations).

Solución 2. Una acción concreta: adoptar OWASP ZAP para escanear la API de BazarNube de forma regular, aunque sea manualmente al principio. Pasar de "no probamos nada" a "escaneamos con una herramienta DAST antes de cada release" eleva la práctica de Verification de nivel 0 a nivel 1. Se relaciona con ZAP, que presentamos en la lección 02-04 y desarrollamos en el módulo 6.

Solución 3. Una madurez baja es el punto de partida esperable de casi cualquier startup joven: refleja que la empresa aún no ha formalizado sus procesos de seguridad, no que haga las cosas mal. Lo importante no es la cifra, sino usarla como línea base para trazar una hoja de ruta: identificar los huecos más críticos (en BazarNube, Verification y Operations) y planificar mejoras incrementales. SAMM no penaliza estar bajo; penaliza no saber dónde estás ni hacia dónde vas.

Has conocido la tercera herramienta de la caja OWASP: SAMM, un modelo de madurez que evalúa no una aplicación, sino el programa de seguridad de la organización. Sabes que se diferencia de ASVS en el plano (organización/proceso vs aplicación/producto), que organiza la actividad en dominios (Governance, Design, Implementation, Verification, Operations) y que puntúa cada práctica en niveles de madurez 0–3. Y has visto cómo BazarNube haría una autoevaluación honesta que, lejos de alarmar, le da una hoja de ruta clara.

Con Top Ten, ASVS y SAMM, BazarNube tiene el qué (riesgos), el cuánto (requisitos verificables) y el cómo de maduro (procesos). Pero falta algo muy práctico: una herramienta que ataque activamente la aplicación para encontrar los fallos que las tablas no ven. Los tres proyectos anteriores son marcos y estándares; ahora toca una herramienta ejecutable. En la lección 02-04 presentamos OWASP ZAP, el proxy de interceptación con el que BazarNube probará su API en ejecución.