Al cerrar el módulo anterior dejamos a ZAP situado no como una herramienta suelta, sino como una pieza de un engranaje mayor: la verificación dinámica automatizada dentro de un proceso. Ese proceso tiene nombre propio. Un Ciclo de Vida de Desarrollo Seguro (Secure Software Development Life Cycle, S-SDLC) es la disciplina que convierte la seguridad de un evento puntual —una auditoría antes de salir a producción— en una propiedad continua del desarrollo. En este módulo tejemos todo lo aprendido: el Top Ten como catálogo de riesgos, ASVS como requisitos verificables, SAMM como medida de madurez y ZAP como verificación dinámica. Esta primera lección construye el marco donde todas esas piezas encajan, y lo aterriza en un S-SDLC concreto para BazarNube.

1. Qué es un SDLC y por qué "asegurarlo"
2. El principio shift-left
3. Seguridad en cada fase del ciclo
4. Gates de seguridad (puertas de calidad)
5. Dónde encajan ASVS, SAMM y ZAP
6. Un S-SDLC concreto para BazarNube
7. Errores comunes y consejos
8. Ejercicios
9. Conclusión

Todo software sigue un ciclo de vida, se documente o no: alguien pide algo (requisitos), alguien lo diseña, se implementa, se prueba, se despliega y se mantiene hasta que se retira. Un SDLC es simplemente hacer explícitas y repetibles esas fases. Un S-SDLC añade a cada fase actividades de seguridad, de modo que un fallo se detecte lo antes posible y no llegue a producción.

La diferencia es económica antes que técnica. El coste de corregir un defecto crece de forma abrupta según avanza el ciclo:

Asegurar el SDLC es, en el fondo, mover la detección hacia la izquierda del gráfico.

Shift-left ("desplazar a la izquierda") es la idea rectora del S-SDLC: llevar las actividades de seguridad lo más cerca posible del inicio del ciclo. En lugar de un pentest final que descubre problemas cuando ya son caros de arreglar, se siembra seguridad desde los requisitos.

Shift-left no significa abandonar las pruebas tardías. La seguridad se distribuye a lo largo de todo el ciclo; simplemente se deja de concentrar todo el esfuerzo al final. Un modelo maduro combina controles tempranos (requisitos ASVS, modelado de amenazas) con controles tardíos (DAST, monitorización en operación). A esta idea complementaria se la llama a veces shift-right: seguir observando en producción.

Aquí se define qué debe hacer el sistema y, con la misma seriedad, qué no debe permitir. Se capturan requisitos de seguridad como historias o criterios de aceptación. ASVS es la fuente natural: en lugar de "el login debe funcionar", escribimos "las contraseñas se almacenan con un algoritmo de hashing adaptativo (ASVS 2.4.1)".

• Requisitos funcionales de seguridad (autenticación, control de acceso, cifrado).
• Requisitos no funcionales (resiliencia, registro y monitorización).
• Clasificación de datos (qué es PII, qué es un secreto).

Se decide cómo se construye. Es la fase con mayor retorno de inversión en seguridad porque un fallo de diseño no se arregla con un parche. Aquí vive el modelado de amenazas (lo veremos a fondo en 07-02) y la aplicación de principios como defensa en profundidad, mínimo privilegio y fallo seguro. Recordemos que el Top Ten 2021 introdujo A04: Diseño Inseguro precisamente para dar peso a esta fase.

Escribir código sin reintroducir los riesgos del catálogo. Se apoya en:

• Guías de codificación segura y OWASP Cheat Sheets.
• Linters y SAST integrados en el editor y en los hooks de commit.
• Revisión de código con foco en seguridad.
• Uso de librerías y frameworks que ya resuelven el problema (por ejemplo, consultas parametrizadas frente a concatenación de SQL).

Verificar que los requisitos de seguridad se cumplen. Combina:

• SAST (análisis estático del código).
• SCA (análisis de dependencias de terceros).
• DAST (pruebas dinámicas sobre la app en ejecución: aquí entra ZAP).
• Pruebas manuales guiadas por la WSTG (Web Security Testing Guide).

Llevar a producción de forma segura: configuración endurecida (contra A05: Configuración de Seguridad Incorrecta), gestión de secretos fuera del código, infraestructura como código revisada y escaneo de contenedores.

La seguridad no termina en el despliegue. En operación se monitoriza (A09: Fallos de Registro y Monitorización), se gestionan vulnerabilidades nuevas en dependencias (A06: Componentes Vulnerables), se parchea y se recogen lecciones que retroalimentan los requisitos del siguiente ciclo.

Un gate es un punto de control donde el trabajo no avanza a la siguiente fase si no cumple un criterio de seguridad. Es el mecanismo que hace que el S-SDLC tenga "dientes": sin gates, las buenas prácticas son opcionales y se saltan bajo presión de plazos.

Un buen gate distingue entre bloqueante (rompe el build) y de aviso (informa pero deja pasar). Empezar con demasiados gates bloqueantes genera rechazo del equipo; se introducen de forma progresiva, en línea con la madurez que mide SAMM.

Las piezas que hemos estudiado no compiten: cada una responde a una pregunta distinta del proceso.

Una forma útil de recordarlo: el Top Ten educa, ASVS especifica, SAMM mide y ZAP comprueba. El S-SDLC es el hilo que las conecta.

BazarNube tenía seguridad "al final": una revisión apresurada antes de cada release. El objetivo es distribuirla. Esta es la tabla maestra que Lucía y la SRE proponen al CTO, mapeando cada fase con una actividad y su artefacto OWASP de apoyo:

Y el gate de release que acuerdan, expresado como criterio del pipeline:

El detalle de por qué cada nivel de ASVS aplica a cada activo, y de cómo el threat model alimenta estos requisitos, se desarrolla en las siguientes lecciones. Lo esencial ahora es ver el esqueleto: cada fase tiene una actividad, un dueño y un artefacto, y hay gates que impiden avanzar sin cumplir.

• Confundir S-SDLC con "comprar herramientas". Un pipeline lleno de escáneres sin gates ni dueños genera ruido, no seguridad. El proceso y las personas van primero.
• Gates todo-o-nada desde el día uno. Bloquear el build por cualquier hallazgo medio frustra al equipo y empuja a saltarse el control. Introduce gates de forma gradual: primero informativos, luego bloqueantes para lo crítico.
• Olvidar la fase de operación. Muchos programas mueren en el despliegue. Los componentes vulnerables (A06) aparecen después de salir a producción; sin gestión continua, el S-SDLC caduca.
• No asignar responsables. "La seguridad es de todos" acaba siendo "de nadie". Cada actividad de la tabla necesita un dueño nombrado.
• Consejo: empieza por una fase donde el retorno sea alto y visible —normalmente diseño (threat modeling) o el gate de commit (SAST + secretos)— y expande desde ahí. Un S-SDLC se construye por iteraciones, igual que se sube de nivel en SAMM.

Ejercicio 1. Clasifica cada actividad en su fase del S-SDLC: (a) escaneo de la imagen Docker antes de publicarla, (b) escribir el criterio "el usuario no puede ver pedidos de otro usuario", (c) ejecutar ZAP contra el entorno de staging, (d) dibujar un diagrama de flujo de datos del checkout.

Ejercicio 2. BazarNube quiere su primer gate bloqueante. Dispone de SAST, SCA, secret scanning y DAST. ¿Cuál convertirías en bloqueante primero y por qué? Justifica en términos de ruido/valor.

Ejercicio 3. Explica, con el modelo de coste relativo, por qué mover el modelado de amenazas de la fase de pruebas a la de diseño ahorra dinero.

Solución 1.

• (a) Despliegue. (b) Requisitos. (c) Pruebas. (d) Diseño.

Solución 2. El candidato más razonable es el secret scanning: tiene muy baja tasa de falsos positivos (una clave AWS o un token es inequívoco), su impacto es altísimo (un secreto filtrado es un incidente inmediato) y bloquear no ralentiza el trabajo legítimo. SAST y DAST generan más ruido y conviene rodarlos primero en modo aviso antes de bloquear. Así se maximiza valor y se minimiza fricción, ganando la confianza del equipo para gates más estrictos.

Solución 3. Un fallo de diseño detectado en pruebas cuesta del orden de 10x corregirlo, porque implica rehacer código y pruebas ya escritas; detectado en diseño cuesta 1x, porque solo se cambia un diagrama o una decisión de arquitectura antes de escribir una línea. El modelado de amenazas en diseño evita construir sobre una base insegura, mientras que en pruebas solo confirma un problema ya materializado.

Un S-SDLC transforma la seguridad de un control final en una propiedad distribuida a lo largo de todo el ciclo, sostenida por el principio shift-left y por gates que impiden avanzar sin cumplir. Hemos visto cómo el Top Ten, ASVS, SAMM y ZAP encajan cada uno en su fase, y hemos esbozado el S-SDLC de BazarNube fase a fase. La fase con mayor retorno es el diseño, y su actividad estrella es el modelado de amenazas: la disciplina de anticipar qué puede salir mal antes de construirlo. Es exactamente lo que desarrollamos a fondo en la siguiente lección, 07-02, retomando la introducción que dejamos pendiente en 03-05.