El threat model del checkout que construimos en la lección anterior dejó una lista de mitigaciones convertidas en requisitos verificables. Ahora bien, un requisito que solo se comprueba cuando alguien se acuerda es un requisito frágil. La promesa de este módulo era que la seguridad pasara de fase final a propiedad continua del proceso, y esa continuidad la aporta la automatización. DevSecOps es la evolución de DevOps que integra la seguridad como responsabilidad compartida y automatizada dentro del flujo de entrega de software. En esta lección vemos cómo orquestar los controles —SAST, SCA, DAST, secret scanning, IaC y contenedores— dentro de un pipeline, y diseñamos el pipeline DevSecOps de BazarNube.

1. Qué es DevSecOps y por qué surge
2. Cultura de responsabilidad compartida
3. Security as Code
4. Los controles del pipeline seguro
5. Gates, gestión de secretos y políticas como código
6. El pipeline DevSecOps de BazarNube
7. Errores comunes y consejos
8. Ejercicios
9. Conclusión

DevOps unió desarrollo y operaciones para entregar software más rápido y con mayor frecuencia. Pero esa velocidad chocó con el modelo clásico de seguridad: una revisión manual al final, que se convertía en cuello de botella o, peor, se saltaba. DevSecOps resuelve la tensión integrando la seguridad en el flujo automatizado, no después de él. La "Sec" no es una tercera fase entre "Dev" y "Ops": es un atributo transversal de ambas.

La idea central es que si desplegamos cien veces al día, la seguridad no puede depender de una persona que revisa a mano; tiene que ejecutarse sola, en cada cambio, y dar feedback en minutos. Es el shift-left de la lección 07-01 llevado a su consecuencia operativa.

DevSecOps es, antes que herramientas, un cambio cultural. En el modelo antiguo la seguridad "pertenecía" al equipo de seguridad; en DevSecOps es responsabilidad de todos los que tocan el producto.

• El desarrollo corrige los hallazgos de seguridad como cualquier otro bug, en su propio flujo.
• Operaciones/SRE aportan endurecimiento, monitorización y respuesta.
• El equipo de seguridad pasa de "hacer" la seguridad a habilitarla: define políticas, elige herramientas, forma y asesora. Es el modelo de security champions que profundizaremos en 07-04.

El antipatrón a evitar es el "muro sobre el que se lanza": desarrollo termina y "lanza" el código a seguridad. DevSecOps derriba ese muro. Esta cultura es exactamente lo que SAMM mide en su dominio de Gobierno y en la práctica de formación.

El principio técnico que hace posible DevSecOps es security as code: expresar la seguridad —controles, políticas, configuración, infraestructura— como ficheros versionados en el repositorio, no como pasos manuales o documentos en un wiki.

Ventajas de tratar la seguridad como código:

• Versionable y auditable: cada cambio de política tiene historia en Git (quién, cuándo, por qué).
• Revisable: una política pasa por pull request como cualquier código.
• Repetible: se aplica igual en todos los entornos, eliminando el "en mi máquina funciona".
• Automatizable: el pipeline la ejecuta sin intervención.

Bajo este paraguas caen el pipeline mismo (YAML de CI), la infraestructura (Terraform), las políticas (OPA/Rego) y la configuración de los escáneres.

Un pipeline DevSecOps orquesta varias familias de herramientas, cada una cubriendo un ángulo distinto del riesgo. Aquí las presentamos a alto nivel como piezas del proceso; el catálogo concreto de herramientas lo veremos en 07-05, y el detalle de ZAP ya lo cubrimos en el módulo 6.

La lógica de colocación sigue el coste del feedback: lo más rápido y con menos falsos positivos (secretos, SAST, SCA) se ejecuta pronto y a menudo; lo más lento (DAST, que necesita la app levantada) se ejecuta después, contra un entorno desplegado.

Como vimos en 07-01, un gate impide avanzar si no se cumple un criterio. En DevSecOps los gates se codifican en el pipeline. La clave práctica es distinguir severidades: bloquear ante lo crítico, avisar ante lo demás, para no paralizar la entrega con ruido.

Un pipeline necesita credenciales (para desplegar, para acceder a registries), y ese es un punto sensible: si el propio pipeline filtra secretos, hemos abierto una brecha en el corazón del proceso. Reglas básicas:

• Nunca secretos en el YAML ni en el código: se inyectan desde un gestor de secretos (Vault, secretos del proveedor de CI, etc.).
• Mínimo privilegio y vida corta: credenciales acotadas a lo que el job necesita y, si es posible, efímeras (OIDC en vez de claves de larga duración).
• Secret scanning como red de seguridad para detectar filtraciones accidentales.

Las reglas de seguridad se expresan como código evaluable. Por ejemplo, con Open Policy Agent (OPA) se puede exigir que ninguna imagen se despliegue sin haber pasado el escaneo, o que ningún bucket sea público.

BazarNube parte de un CI que solo ejecutaba tests unitarios. La SRE y Lucía diseñan una evolución por etapas, mapeando cada control con la mitigación del threat model del checkout que quedaba pendiente de automatizar.

Estrategia de adopción (evita el rechazo del equipo):

1. Semana 1-2: secret scanning bloqueante (alto valor, bajo ruido) y el resto en modo aviso.
2. Mes 1: SAST y SCA bloqueantes solo para severidad crítica/alta, tras haber limpiado los hallazgos existentes.
3. Mes 2: DAST en staging y gate de release agregado.
4. Continuo: subir el listón conforme baja la deuda, alineado con el objetivo de madurez de SAMM.

El resultado es que las mitigaciones que en 07-02 eran "requisitos en el backlog" pasan a ser comprobaciones que el pipeline ejecuta en cada cambio, sin depender de que alguien se acuerde.

• Encender todos los gates a la vez. El equipo se encuentra el build roto por decenas de hallazgos preexistentes y pierde la confianza en el proceso. Introduce controles en modo aviso, limpia la deuda y luego bloquea.
• Fatiga de alertas. Mil hallazgos de baja severidad entierran los tres que importan. Prioriza por severidad, suprime falsos positivos conocidos y ajusta las reglas.
• Secretos en el pipeline. Poner un token directamente en el YAML es una brecha esperando a ocurrir. Usa siempre el gestor de secretos y credenciales de vida corta.
• Automatizar sin cultura. Un pipeline perfecto no sirve si desarrollo ignora los hallazgos por no ser "su" trabajo. La responsabilidad compartida es el prerrequisito.
• Consejo: mide el tiempo de feedback. Si el pipeline de seguridad tarda 40 minutos, la gente lo evita. Paraleliza jobs y mueve lo lento (DAST) a una fase posterior para que el feedback rápido llegue en minutos.

Ejercicio 1. Ordena estos controles de más temprano a más tardío en el pipeline y justifica: DAST, secret scanning, SCA.

Ejercicio 2. Un desarrollador de BazarNube quiere desplegar urgente y el gate de release bloquea por una vulnerabilidad "High" en una dependencia. ¿Qué opciones legítimas hay y cuál es el antipatrón?

Ejercicio 3. Explica por qué el secret scanning es un buen candidato a primer gate bloqueante en términos de la relación valor/ruido, conectándolo con la gestión de secretos en CI.

Solución 1. Orden: secret scanning → SCA → DAST. El secret scanning es el más barato y rápido (analiza texto, casi sin falsos positivos) y se ejecuta ya en pre-commit. El SCA analiza el árbol de dependencias en CI, rápido y determinista. El DAST es el más tardío porque necesita la aplicación desplegada y en ejecución en staging, por lo que solo puede correr tras el build y el deploy. El orden sigue el principio de dar el feedback más rápido cuanto antes.

Solución 2. Opciones legítimas: (a) actualizar la dependencia a una versión parcheada —lo ideal—; (b) si no hay parche, evaluar si la vulnerabilidad es explotable en el contexto y aplicar una mitigación compensatoria; (c) solicitar una excepción formal, aprobada por un responsable (el CTO en BazarNube), registrada y con caducidad. El antipatrón es desactivar el gate o subir el umbral "temporalmente" sin registro: esa excepción se vuelve permanente y erosiona todo el proceso.

Solución 3. El secret scanning tiene una relación valor/ruido excelente: un token o clave filtrada es prácticamente inequívoco (bajísimo falso positivo) y su impacto es máximo (una credencial expuesta es un incidente inmediato, potencialmente en el propio pipeline). Como además la gestión de secretos en CI es un punto especialmente sensible, detectar filtraciones accidentales de forma bloqueante protege el corazón del proceso sin ralentizar el trabajo legítimo, lo que lo hace ideal como primer gate.

DevSecOps convierte los controles de seguridad en comprobaciones automáticas, versionadas y de responsabilidad compartida, orquestadas dentro del pipeline de entrega. Hemos visto sus familias de controles, la gestión de secretos y las políticas como código, y hemos diseñado el pipeline de BazarNube con una estrategia de adopción realista que automatiza las mitigaciones del threat model. Pero ninguna herramienta ni pipeline sustituye al criterio de las personas que escriben el código y aprueban los pull requests: el eslabón decisivo sigue siendo humano. En la siguiente lección, 07-04, abordamos ese factor humano: cómo la capacitación y concienciación —secure coding, security champions, gamificación— sostiene toda la cultura que DevSecOps presupone.