En la lección anterior vimos que SAMM organiza la seguridad de la organización en 5 funciones de negocio, 15 prácticas de seguridad y niveles de madurez. Ahora abrimos esa estructura. Las funciones de negocio (a veces llamadas dominios) son los grandes bloques de actividad de cualquier organización que produce software; cada una agrupa tres prácticas concretas, y cada práctica se divide en dos flujos. Conocer bien este mapa es imprescindible: es el marco sobre el que haremos la autoevaluación (05-03) y el roadmap (05-04). En esta lección recorremos las cinco funciones, sus prácticas, y repartimos las responsabilidades en BazarNube.

1. Las 5 funciones de negocio de un vistazo
2. Governance: gobernar la seguridad
3. Design: construir seguridad desde el diseño
4. Implementation: llevar la seguridad al código y al despliegue
5. Verification: comprobar que lo construido es seguro
6. Operations: mantener la seguridad en producción
7. Tabla completa: funciones → prácticas → flujos
8. Reparto de responsabilidades en BazarNube

SAMM v2 distribuye toda la actividad de aseguramiento en cinco funciones que siguen, aproximadamente, el flujo natural del software: primero se gobierna, luego se diseña, se implementa, se verifica y finalmente se opera.

Cada función tiene tres prácticas de seguridad, y cada práctica tiene dos flujos (streams, llamados A y B) que representan dos objetivos complementarios. Importante: en este módulo aprendemos a organizar y medir estas prácticas. El detalle de cómo ejecutar las que son técnicas (threat modeling, secure build, DevSecOps, concienciación...) se desarrolla en el módulo 7 (Buenas prácticas). SAMM las estructura; M7 las pone en marcha.

Cubre cómo la organización dirige, financia y da soporte a sus actividades de seguridad. Es la función más "de arriba", muy ligada a dirección.

• Strategy & Metrics: crear y promover una estrategia de seguridad y medirla. Flujos: (A) crear y promover, (B) medir y mejorar.
• Policy & Compliance: fijar políticas y estándares internos y gestionar el cumplimiento normativo (GDPR, PCI-DSS...). Flujos: (A) política y estándares, (B) gestión de cumplimiento.
• Education & Guidance: formar y concienciar a los equipos y construir cultura de seguridad. Flujos: (A) formación y concienciación, (B) organización y cultura.

Cubre cómo se definen los objetivos de seguridad y el diseño del software antes de escribir código.

• Threat Assessment: entender el riesgo de cada aplicación y modelar sus amenazas. Flujos: (A) perfil de riesgo de la aplicación, (B) threat modeling.
• Security Requirements: definir requisitos de seguridad para el software propio y para los proveedores. Flujos: (A) requisitos del software, (B) seguridad de proveedores.
• Security Architecture: diseñar con patrones y componentes seguros y gestionar la tecnología usada. Flujos: (A) diseño de arquitectura, (B) gestión de tecnología.

Cubre cómo se construye y despliega el software de forma fiable y segura.

• Secure Build: proceso de build reproducible y seguro, y gestión de dependencias. Flujos: (A) proceso de build, (B) dependencias de software.
• Secure Deployment: desplegar de forma segura y gestionar secretos. Flujos: (A) proceso de despliegue, (B) gestión de secretos.
• Defect Management: registrar, priorizar y aprender de los defectos de seguridad. Flujos: (A) seguimiento de defectos, (B) métricas y retroalimentación.

Cubre cómo la organización comprueba que el software cumple sus objetivos de seguridad. (Aquí es donde el ASVS del módulo 4 y ZAP del módulo 6 encajan como instrumentos.)

• Architecture Assessment: validar que la arquitectura cumple los objetivos y mitigar sus debilidades. Flujos: (A) validación de arquitectura, (B) mitigación de arquitectura.
• Requirements-driven Testing: probar que los controles funcionan y buscar abuso/mal uso. Flujos: (A) verificación de controles, (B) pruebas de mal uso/abuso.
• Security Testing: pruebas de seguridad escalables (automatizadas) y de comprensión profunda (manuales, pentest). Flujos: (A) baseline escalable, (B) comprensión profunda.

Cubre cómo se mantiene la seguridad del software una vez en producción.

• Incident Management: detectar y responder a incidentes de seguridad. Flujos: (A) detección de incidentes, (B) respuesta a incidentes.
• Environment Management: endurecer la configuración y aplicar parches y actualizaciones. Flujos: (A) hardening de configuración, (B) parcheo y actualización.
• Operational Management: proteger los datos y gestionar el ciclo de vida de sistemas heredados. Flujos: (A) protección de datos, (B) gestión del legado.

Este es el mapa completo de SAMM v2, la referencia que usaremos en el resto del módulo:

Son 5 funciones × 3 prácticas = 15 prácticas, cada una con 2 flujos. Cuando en la próxima lección puntuemos la madurez, lo haremos práctica a práctica sobre esta misma rejilla.

Un error clásico es dejar todo SAMM en manos del equipo técnico. Muchas prácticas dependen de dirección, SRE o negocio. En BazarNube el rol AppSec (tú) facilita, pero cada función tiene un responsable (owner) que rinde cuentas:

Observaciones para BazarNube:

• El stack legacy Java/Spring eleva el peso de Environment Management (parcheo) y Secure Build (dependencias): es donde más deuda se acumula.
• Education & Guidance (Governance) y Security Testing (Verification) son transversales: afectan a todos los equipos y suelen ser las primeras en quedarse sin dueño claro.
• Que una función tenga owner no significa que trabaje sola: el AppSec coordina y el resto colabora. El owner es quien responde por su madurez.

Recuerda: aquí solo asignamos y encuadramos las prácticas. Cómo se hace un threat model, cómo se monta un pipeline DevSecOps o cómo se diseña un plan de concienciación es contenido del módulo 7.

• Dejar todo SAMM en el equipo técnico. Governance y Operations dependen de dirección y SRE; sin sus responsables, esas funciones quedan sin madurar.
• Confundir función con práctica. La función es el bloque grande (p. ej. Design); la práctica es la actividad concreta (p. ej. Threat Assessment). La madurez se puntúa por práctica.
• Ignorar los dos flujos de cada práctica. Una práctica puede estar madura en un flujo y verde en el otro (p. ej. build seguro pero dependencias sin control); mirar solo uno da una foto falsa.
• Intentar desarrollar aquí las prácticas técnicas. El "cómo" de threat modeling, secure build o DevSecOps es del módulo 7; en SAMM solo las organizamos.
• Asignar prácticas sin owner que rinda cuentas. Sin responsable, una práctica no se evalúa ni mejora.
• Consejo: memoriza primero las 5 funciones y su orden (Govern-Design-Implement-Verify-Operate); las 15 prácticas se recuerdan mucho mejor colgadas de su función.

Ejercicio 1. Coloca cada práctica en su función de negocio: (a) Secure Deployment, (b) Threat Assessment, (c) Incident Management, (d) Education & Guidance, (e) Security Testing.

Ejercicio 2. En BazarNube, ¿qué función de negocio y qué práctica cubren cada situación? (a) La SRE define cada cuánto se aplican parches al servidor Java legacy. (b) El CTO aprueba el presupuesto anual de seguridad. (c) Lucía revisa las dependencias npm con CVE antes de un build. (d) Se organiza un curso de codificación segura para los desarrolladores.

Ejercicio 3. Elige una práctica cualquiera de la tabla y explica con tus palabras qué cubriría cada uno de sus dos flujos. ¿Por qué crees que SAMM separa cada práctica en dos flujos en lugar de puntuarla como un todo?

Solución 1. (a) Implementation, (b) Design, (c) Operations, (d) Governance, (e) Verification.

Solución 2. (a) Operations → Environment Management (flujo de parcheo y actualización). (b) Governance → Strategy & Metrics (estrategia y su promoción/financiación). (c) Implementation → Secure Build (flujo de dependencias de software). (d) Governance → Education & Guidance (flujo de formación y concienciación).

Solución 3. Ejemplo con Secure Build: el flujo A (proceso de build) cubre que el pipeline sea reproducible, íntegro y sin pasos manuales inseguros; el flujo B (dependencias) cubre que se conozcan e inventaríen las librerías y se detecten/actualicen las vulnerables. SAMM separa en dos flujos porque una práctica puede madurar de forma desigual: se puede tener un build impecable y, a la vez, no controlar las dependencias. Dos flujos dan una foto más fina y evitan que un aspecto fuerte esconda uno débil.

Ya tenemos el mapa completo de SAMM: 5 funciones de negocio (Governance, Design, Implementation, Verification, Operations), 15 prácticas de seguridad y 2 flujos por práctica, con un responsable asignado en BazarNube para cada función. Este marco es la rejilla sobre la que vamos a medir. Recuerda que aquí solo hemos encuadrado las prácticas; el detalle de ejecución de las técnicas llega en el módulo 7. En la próxima lección damos el paso decisivo: introducimos los niveles de madurez (0 a 3), aprendemos a hacer una autoevaluación práctica por práctica y construimos el primer scorecard real de BazarNube.