Tema 16
DevSecOps integra seguridad en el flujo de desarrollo y operación. Su objetivo es detectar riesgos temprano, automatizar controles repetibles y generar feedback útil sin convertir seguridad en un bloqueo tardío.
En modelos tradicionales, seguridad suele intervenir al final: una revisión previa a producción, una auditoría puntual o un reporte de vulnerabilidades cuando el cambio ya está avanzado. Ese enfoque llega tarde y genera fricción.
DevSecOps propone integrar seguridad en todo el ciclo de vida: planificación, diseño, desarrollo, revisión, build, pruebas, despliegue y operación. La seguridad deja de ser una etapa aislada y se convierte en una práctica continua.
El objetivo no es que cada desarrollador sea especialista en seguridad, sino que el proceso facilite decisiones seguras, controles automáticos y correcciones tempranas.
DevSecOps es la integración de prácticas de seguridad dentro de DevOps. Combina colaboración entre equipos, automatización, políticas claras y responsabilidad compartida.
Incluye:
Shift left significa mover controles hacia etapas tempranas: diseño, desarrollo y revisión de código. Shift right significa observar lo que ocurre en producción y aprender del comportamiento real.
| Enfoque | Qué hace | Ejemplos |
|---|---|---|
| Shift left | Detecta problemas antes de construir o desplegar | Threat modeling, SAST, SCA, secret scanning, IaC scanning |
| Shift right | Detecta riesgos en ejecución y operación real | Runtime security, logs, alertas, DAST, monitoreo de comportamiento |
| Feedback loop | Convierte hallazgos en mejoras del proceso | Corrección de templates, reglas de pipeline, capacitación puntual |
Cada etapa del SDLC tiene controles adecuados. No todo debe esperar al pipeline ni todo puede resolverse con análisis estático.
| Etapa | Control | Objetivo |
|---|---|---|
| Planificación | Requisitos de seguridad y clasificación de datos | Entender riesgo antes de diseñar |
| Diseño | Threat modeling y revisión de arquitectura | Identificar amenazas y controles necesarios |
| Desarrollo | Guías seguras, linters, secret scanning y revisión | Evitar defectos y filtraciones tempranas |
| Build | SCA, SAST, escaneo de imagen y SBOM | Validar artefactos y dependencias |
| Deploy | Policy as code, firma, controles de entorno | Desplegar solo cambios aprobados |
| Operación | Monitoreo, alertas, DAST y respuesta | Detectar y corregir riesgo real |
Threat modeling consiste en analizar cómo puede ser atacado un sistema antes de construirlo o cambiarlo. No necesita ser un proceso pesado; puede ser una conversación estructurada con decisiones documentadas.
Preguntas útiles:
El repositorio es el punto de entrada del cambio. Protegerlo evita que código, configuración o secretos inseguros entren al flujo.
Controles recomendados:
La automatización permite ejecutar controles de forma consistente. Pero no todo control debe bloquear: algunos informan, otros generan tickets y otros impiden avanzar.
| Tipo | Uso | Ejemplo |
|---|---|---|
| Informativo | Educar o dar visibilidad | Comentario en pull request con recomendaciones |
| Advertencia | Señalar problema no bloqueante | Dependencia media sin explotación conocida |
| Bloqueante | Impedir riesgo inaceptable | Secreto detectado o vulnerabilidad crítica explotada |
| Remediación automática | Corregir patrones repetibles | Crear PR para actualizar dependencia |
Un gate es una condición que debe cumplirse para avanzar. Los gates deben ser pocos, claros y defendibles. Si bloquean demasiado por hallazgos de baja calidad, los equipos buscarán evitarlos.
Buenos candidatos para bloqueo:
DevSecOps funciona mejor cuando el feedback es rápido, específico y accionable. Un reporte genérico de seguridad semanas después del cambio tiene poco valor práctico.
Un buen feedback debe indicar:
El objetivo es reducir tiempo de corrección y mejorar criterio técnico del equipo.
Security champions son referentes de seguridad dentro de equipos de desarrollo o plataforma. No reemplazan al equipo de seguridad, pero acercan criterio y prácticas al trabajo diario.
Responsabilidades posibles:
En DevSecOps siempre existirán casos donde no se puede corregir de inmediato. La excepción debe ser un mecanismo controlado, no un bypass informal.
Debe incluir:
Las métricas deben mostrar si el proceso reduce riesgo y mejora velocidad de corrección. Medir solo cantidad de hallazgos puede incentivar comportamientos incorrectos.
Métricas útiles:
Una forma efectiva de escalar DevSecOps es ofrecer caminos seguros por defecto. Los equipos no deberían resolver desde cero cada integración, pipeline o despliegue.
Ejemplos:
DevSecOps puede generar evidencia automáticamente: quién aprobó, qué se escaneó, qué versión se desplegó, qué vulnerabilidades se aceptaron y qué controles se ejecutaron.
Esto mejora cumplimiento porque reduce dependencia de capturas manuales y auditorías tardías. La evidencia nace del flujo de trabajo.
DevSecOps funciona cuando seguridad se vuelve parte del sistema de entrega. Controles tempranos, feedback rápido, automatización, excepciones gobernadas y métricas útiles permiten reducir riesgo sin bloquear innecesariamente la velocidad de desarrollo.
En el próximo tema estudiaremos la seguridad en pipelines CI/CD: permisos, runners, artefactos, aprobaciones y entornos.