DevSecOps - Seguridad en el pipeline de desarrollo
Lectura de 2 min aprox.
DevSecOps es un enfoque que unifica el desarrollo de software (Dev), la seguridad (Sec) y las operaciones (Ops), integrando la seguridad en cada etapa del ciclo de vida del desarrollo. Tradicionalmente, el modelo dominante era de tipo «guardián», en el que el equipo de seguridad inspeccionaba el producto justo antes del lanzamiento, pero DevSecOps ejecuta automáticamente comprobaciones de seguridad en cada fase de diseño, codificación, pruebas y despliegue. Es un concepto que se sustenta en dos pilares: el cambio cultural de que «la seguridad es responsabilidad de todos» y la integración de herramientas en la canalización de CI/CD.
Evolución a partir de DevOps
DevOps eliminó el muro entre el desarrollo y las operaciones y aumentó drásticamente la velocidad de los lanzamientos. Sin embargo, cuanto mayor era la velocidad, más se convertían las revisiones de seguridad en un cuello de botella, lo que generó un nuevo desafío. En un entorno que despliega varias veces por semana, no es realista intercalar una revisión de seguridad manual en cada lanzamiento. El concepto de «shift left» (desplazamiento a la izquierda) nació para resolver este problema.
El desplazamiento a la izquierda significa mover la verificación de seguridad hacia el «lado izquierdo» (etapas más tempranas) del proceso de desarrollo. Cuanto antes se detecta un problema, menor es el costo de corregirlo, y reduce considerablemente el riesgo de que se descubra una vulnerabilidad crítica justo antes del lanzamiento y se produzcan reprocesos.
Integración de la seguridad en la canalización de CI/CD
En la práctica de DevSecOps, las herramientas de seguridad se integran en cada etapa de la canalización de CI/CD. El mecanismo ejecuta automáticamente las comprobaciones de seguridad con solo que un desarrollador suba el código, sin requerir ninguna acción especial.
La diferencia entre SAST, DAST y SCA
Analiza el código fuente o el bytecode sin ejecutarlo. Detecta violaciones de codificación segura y patrones de inyección SQL y XSS. Puede ejecutarse desde las primeras etapas del desarrollo, pero tiende a generar muchos falsos positivos (false positives).
Simula ataques desde el exterior contra una aplicación en ejecución. Puede descubrir vulnerabilidades realmente explotables, pero no puede identificar la ubicación en el código fuente. Suele ejecutarse en un entorno de preproducción (staging).
Detecta vulnerabilidades conocidas y violaciones de licencias en las bibliotecas de dependencias. Su importancia se ha disparado como medida contra los ataques a la cadena de suministro. npm audit, Dependabot y Snyk son ejemplos representativos.
Relación con el SBOM
Un SBOM (Software Bill of Materials, lista de materiales de software) es un inventario completo de todos los componentes contenidos en un software. Impulsada por la Orden Ejecutiva 14028 de EE. UU. de 2021, se aceleró la tendencia a hacer obligatoria la entrega de SBOM para el software adquirido por el gobierno. En una canalización de DevSecOps, el SBOM se genera automáticamente en tiempo de compilación y, en coordinación con las herramientas de SCA, se identifican al instante los componentes vulnerables. También desde la perspectiva del cumplimiento normativo, el SBOM es un activo importante que agiliza la identificación del alcance del impacto cuando ocurre un incidente.
El papel del campeón de seguridad
El éxito de DevSecOps requiere no solo la adopción de herramientas, sino también una transformación de la cultura organizacional. Un campeón de seguridad es un punto de contacto de seguridad ubicado dentro de cada equipo de desarrollo. En lugar de un ingeniero de seguridad dedicado, es un desarrollador que adquiere conocimientos de seguridad y actúa como asesor interno del equipo.
«Tras colocar un campeón de seguridad en cada equipo, las consultas al equipo de seguridad se redujeron en un 40% y la velocidad de corrección de vulnerabilidades se triplicó. El mayor cambio fue que los propios desarrolladores empezaron a considerar la seguridad como algo propio.»
Incorporar comprobaciones desde una perspectiva de seguridad en la etapa de revisión de código también es un papel importante del campeón. La creación de un marco de seguridad para una startup se explica en la lista de verificación de seguridad para startups, y la auditoría de seguridad de código abierto se explica en la auditoría de seguridad de código abierto. Para conocer la realidad de los ataques a la cadena de suministro, consulta también la explicación de los ataques a la cadena de suministro.libros prácticos sobre DevSecOps (Amazon) te permitirán profundizar aún más.
Conceptos erróneos comunes
El concepto erróneo más común es que «DevSecOps está completo una vez que se adoptan las herramientas». Aunque se integren SAST y DAST en la CI/CD, sin una cultura y un proceso para corregir las vulnerabilidades detectadas, las alertas simplemente se ignorarán. También es errónea la idea de que «DevSecOps es tarea del equipo de seguridad»; la esencia reside precisamente en una estructura en la que desarrolladores, operadores y responsables de seguridad colaboran como tres partes. Integrar la seguridad en el proceso de desarrollo como «parte de la calidad» es el ideal al que aspira DevSecOps.
¿Te resultó útil este artículo?