DevOps y DevSecOps

Cómo cambia la gestión de un proyecto cuando desarrollo y operación se organizan como un flujo continuo y automatizado, cómo se mide ese flujo (DORA), y cómo se integra la seguridad en cada paso en vez de dejarla para el final.

1. Qué es DevOps

DevOps = desarrollo + operaciones. Sus ideas, según las diapositivas:Tema 2, diap. 90. Kim, Humble, Debois y Willis (2016), The DevOps Handbook.

• Integrar personas, procesos y herramientas.
• Automatizar el ciclo build → test → release → deploy → operate.
• Reducir el tiempo entre una modificación y su entrega fiable.
• Feedback continuo entre desarrollo y operación.
• Responsabilidad compartida sobre el software en producción.

El problema que resuelve: tradicionalmente, desarrollo quería cambiar (sacar funcionalidades) y operación quería estabilidad (que nada cambie para que nada se rompa). Desarrollo "tiraba el software por encima del muro" y operación sufría las consecuencias. Las entregas eran grandes, poco frecuentes y arriesgadas. DevOps rompe el muro: el mismo equipo (o equipos que colaboran de verdad) es responsable de construir y de operar ("you build it, you run it").

Un marco útil para recordar sus pilares (ampliación) es CALMS: Cultura (responsabilidad compartida, sin culpables), Automatización, Lean (flujo, lotes pequeños, eliminar esperas), Medición (DORA), Sharing (compartir conocimiento).Ampliación. CALMS: Jez Humble, a partir de CAMS de Damon Edwards y John Willis. Fíjate en que la C va primero: comprar herramientas sin cambiar la cultura no es DevOps.

2. El ciclo DevOps

El famoso "infinito" de la diap. 91: la mitad Dev y la mitad Ops enlazadas por un bucle de feedback.Tema 2, diap. 91.

Fíjate: es un PDCA (lección 11) que gira muy rápido, en días u horas en vez de meses.

Las cuatro prácticas técnicas

Automatización + integración continua + entrega continua, más:Tema 2, diap. 92. Humble y Farley (2010), Continuous Delivery.

• CI · integración continua: integrar cambios frecuentemente (al menos a diario) en la rama principal y validarlos automáticamente (build + pruebas). Evita el "infierno de la integración": cuanto más tiempo vive una rama separada, más doloroso es integrarla.
• CD · entrega continua / despliegue continuo: mantener el software preparado para ser entregado (entrega continua) o desplegarlo automáticamente (despliegue continuo). La diferencia está en un único paso:
  Entrega continua: commit → build → test → [listo para producción] → (decisión humana) → producción Despliegue continuo: commit → build → test → producción automáticamente, sin intervención
  Con entrega continua, desplegar es una decisión de negocio (p. ej., esperar a la feria); con despliegue continuo, cada cambio que pasa las pruebas llega a producción.
• Infraestructura como código (IaC): gestionar la infraestructura (servidores, redes, bases de datos) mediante código versionado y automatizado (p. ej., Terraform). Ventajas: reproducible (el entorno de pruebas es idéntico al de producción), revisable (cambios en PR), recuperable (recrear todo tras un desastre).
• Observabilidad: obtener información del sistema mediante logs (qué pasó), métricas (cuánto, con qué frecuencia) y trazas (por dónde pasó una petición entre servicios). Permite saber por qué falla algo, no sólo que falla.

3. DevOps y la gestión del proyecto

DevOps cambia la forma de gestionar el proyecto:Tema 2, diap. 93.

Consecuencias para lo que has visto en el curso:

• Riesgo (lección 13): despliegues pequeños = menor impacto; rollback = contingencia; observabilidad = KRIs en producción.
• Calidad (lección 15): el control de calidad es continuo y automático, no una fase.
• Gobernanza (lección 17): los controles pasan a ser gates en el pipeline y las evidencias se generan solas.
• Cierre (lección 11): el proyecto termina, pero el producto sigue en un flujo continuo; el cierre marca el fin del desarrollo inicial.
• Progreso: se mide por software funcionando en producción, no por % de tareas.

Las métricas DORA

El programa de investigación DORA (DevOps Research and Assessment), resumido en el libro Accelerate, identificó cuatro métricas que predicen el rendimiento de entrega de software:Tema 2, diap. 93. Forsgren, Humble y Kim (2018), Accelerate. dora.dev.

El hallazgo clave de la investigación: velocidad y estabilidad no son un trade-off. Los equipos de mejor rendimiento son a la vez los más rápidos y los más estables, porque desplegar a menudo obliga a lotes pequeños, automatización y recuperación rápida. El objetivo, en palabras de las diapositivas: entregar cambios rápidamente sin sacrificar estabilidad ni calidad.

Y una advertencia esencial: medir para mejorar el flujo, no para medir a las personas. Si las métricas se usan para evaluar o comparar individuos, se manipulan (desplegar cambios triviales para subir la frecuencia) y dejan de servir (ley de Goodhart: "cuando una medida se convierte en objetivo, deja de ser una buena medida").

Nota de actualización (ampliación): dora.dev lista hoy cinco métricas, agrupadas en rendimiento (throughput: lead time, frecuencia de despliegue, tiempo de recuperación de un despliegue fallido) e inestabilidad (tasa de fallo de cambios y la nueva tasa de retrabajo de despliegues, despliegues no planificados para arreglar incidentes). Para el examen, usa las cuatro de las diapositivas.

4. DevSecOps

DevSecOps es la integración proactiva de la seguridad en el flujo de trabajo de DevOps, de modo que las actividades de seguridad sean componentes intrínsecos (no fases separadas) del ciclo de vida del software.Tema 2, diap. 94. Tres principios:

• "Shift left" (desplazar a la izquierda): incluir la seguridad desde el diseño y el desarrollo temprano. "Izquierda" porque en una línea temporal del ciclo de vida, el diseño está a la izquierda y la producción a la derecha. Es el coste del error creciente (lección 1) aplicado a vulnerabilidades.
• Automatización: escanear código, dependencias y configuraciones en cada etapa.
• Colaboración: desarrollo, operaciones y seguridad trabajando juntos (no un equipo de seguridad que "aprueba" al final).

Y su relación con CI/CD: CI automatiza la construcción y las pruebas del código (ahí entran SAST, SCA, secretos); CD automatiza el despliegue en entornos de prueba y producción (ahí entran DAST, escaneo de configuración, y los gates que bloquean).

La seguridad en cada fase del ciclo

Las diapositivas muestran dos versiones del ciclo con controles de seguridad en cada fase: la del Departamento de Defensa de EE. UU. y la del propio profesor (UMA).Tema 2, diap. 95-96. Reorganizado por fases:

Tipos de herramientas

Cómo distinguir SAST y DAST en una pregunta: SAST = Static = código, sin ejecutar, temprano (izquierda). DAST = Dynamic = aplicación ejecutándose, más tarde (derecha). Se complementan: SAST encuentra el fallo en la línea de código pero da falsos positivos; DAST confirma que es explotable pero no dice dónde está en el código. SCA es distinta: no mira tu código, sino el de otros que usas (supply chain, lección 12). Un complemento natural de la SCA es el SBOM (Software Bill of Materials): el inventario de componentes que el temario de riesgos pide mantener.

Un ejemplo sencillo

El de las diapositivas, una aplicación web con una vulnerabilidad XSS (Cross-Site Scripting):Tema 2, diap. 98.

1. SAST detecta el fallo durante el pull request.
2. El desarrollador corrige el código.
3. El flujo CI/CD bloquea el despliegue hasta que se resuelve (un gate).

Resultado: la vulnerabilidad se mitiga en minutos y no llega a producción. Compáralo con el modelo antiguo: un pentest semanas después del despliegue, un informe, un parche urgente, quizá una brecha y una notificación en 72 horas (RGPD, lección 17).

Beneficios

Según las diapositivas:Tema 2, diap. 99. Fuente citada: GitHub · DevSecOps.

• Velocidad y seguridad: detección temprana de vulnerabilidades (la diapositiva cita un ahorro de un 80 % de costes frente a detectarlas en producción; tómalo como orden de magnitud, la idea robusta es que cuanto antes, más barato).
• Cumplimiento: automatización de auditorías (p. ej., RGPD, HIPAA): las evidencias salen del pipeline (lección 17).
• Resiliencia: menor riesgo de brechas por ataques a la cadena de suministro.

5. Conclusiones

Las tres ideas con las que cierran las diapositivas:Tema 2, diap. 100.

1. DevOps no es un proceso como tal, sino una forma de organizar el desarrollo y la operación como un flujo continuo.
2. DevSecOps no es "DevOps + unos escáneres de seguridad", sino una cultura de seguridad continua que busca proteger sin frenar la innovación.
3. DevOps y DevSecOps no sustituyen a otras metodologías de análisis, diseño, modelado, etc., sino que las integran en el ciclo de desarrollo. (Sigues necesitando requisitos, arquitectura, ADRs, gestión de riesgos… todo lo del curso.)

Referencias para implantarlo de forma gradual: OWASP DevSecOps Maturity Model (DSOMM), NIST SP 800-204 (seguridad en arquitecturas de microservicios y sus pipelines CI/CD) y BSIMM (modelo de madurez basado en lo que hacen realmente las empresas).

Práctica

Repaso espaciado · lecciones 13, 15, 17

Para profundizar

Resúmenes imprimibles: Tema 2 · Glosario.