DevSecOps: la seguridad como un requisito más en el flujo de diseño, desarrollo y entrega de aplicaciones

Alejandro de Fuenmayor    12 mayo, 2020

Hace ya años que DevOps dejó de ser el acrónimo de moda en los departamentos de sistemas de información y desarrollo de aplicaciones. La adopción de metodologías ágiles y la automatización de los despliegues coordinados se ha convertido en parte de las rutinas y tareas habituales en cualquier proyecto TIC. Incluso ya hemos escrito de AIOps en este blog.

Decía Paulo Coelho que “lo que ocurre dos veces ocurrirá, invariablemente, una tercera vez”. Y efectivamente en esta fiesta del DevOps faltaba un invitado.

“Ese invitado” -la seguridad- realmente no lo estaba y llegaba al final de la celebración para recoger y pagar los platos rotos. Era el encargado de reventar los calendarios de entrega y echar abajo la planificación, pero es lo que toca cuando uno aparece en escena en el último momento y además es una pieza importante del puzle. O, mejor dicho, es lo que ocurre si quedan muchas piezas que poner para garantizar la seguridad de una nueva aplicación. Pocos serán los valientes (de “locos” podemos calificarlos) capaces de pasar a producción una aplicación sin el sello del equipo de seguridad.

Respecto a este tema hay un gran debate en el mercado sobre la necesidad de especialización o no de los perfiles técnicos y sobre cómo los desarrolladores full-stack están cambiando el paradigma del enfoque de desarrollo de nuevas aplicaciones.

DevSecOps: una nueva filosofía de trabajo

No hace falta un doctorado en Harvard para vislumbrar que el acrónimo DevSecOps supone la inclusión en esta forma de trabajar de un nuevo miembro en el equipo. A los desarrolladores (Dev) y al equipo de operaciones (Ops), se suma el departamento de seguridad (Sec).

La seguridad, en este modelo de trabajo mejorado, deja de ser una barrera o alto en el camino, para formar parte de las paradas necesarias del viaje, implica el trabajo codo con codo del equipo de seguridad con el resto de la organización.

DevSecOps supone, así, un cambio en la filosofía de trabajo, de forma que la responsabilidad de las tareas de seguridad se extiende al resto del equipo Dev y Ops. La seguridad pasa a ser una actividad que se ejecuta con responsabilidad compartida e imbricada a lo largo del proceso de desarrollo y despliegue.

Entrega rápida de la aplicación con la seguridad como parte del flujo 

Invitar a los equipos de seguridad desde el principio en los proyectos DevOps implica incorporar la seguridad de la información a los procesos, así como nuevas herramientas y establecer un plan para su automatización.

El objetivo inicial de la filosofía de trabajo DevOps no se debe ver alterado por la incorporación de una nueva área, en este caso la de seguridad. El fin debe seguir siendo garantizar la entrega rápida, y ahora también segura, del código, mientras se atajan los problemas tradicionales entre el desarrollo y la seguridad. Una de las máximas de DevSecOps es descentralizar la seguridad, de forma que se convierta en un requisito más en el flujo de diseño, desarrollo y entrega de la aplicación.

Para ello, el departamento de seguridad tiene como nuevo objetivo conseguir que todas las personas del equipo dispongan de las habilidades necesarias, para trabajar con un alto nivel de competencia e independencia en lo que a los criterios de seguridad se refiere, en un corto período de tiempo. De esta forma la seguridad pasa a ser responsabilidad de todas las áreas involucradas en el proyecto.

El equipo de seguridad, por su parte, se convierte en un actor más dentro del proceso de integración y entrega continua de software, que debe identificar errores en la aplicación y crear peticiones para solventarlos, que irán a la lista de trabajos pendientes del equipo de desarrollo u operaciones para resolverlos de cara al nuevo lanzamiento de la aplicación.

Retos del departamento de seguridad en DevSecOps

Uno de los retos principales a los que se enfrenta el departamento de seguridad con esta nueva filosofía de trabajo es la automatización de los procesos y herramientas para no convertirse en un cuello de botella, en vez de un facilitador, en el desarrollo de aplicaciones.

Para cumplir con los objetivos es necesario seleccionar las herramientas adecuadas para integrar la seguridad de manera permanente y centralizada, así como formar al equipo de seguridad en metodologías ágiles.

Según Gartner, ya el año pasado más del 70 por ciento de las iniciativas DevSecOps incorporó de forma automatizada el proceso de gestión de vulnerabilidades de seguridad y escaneo de la configuración para componentes de código abierto y paquetes comerciales. Representa una mejora significativa si se compara con tres años atrás, cuando menos de un 10 por ciento de las empresas analizadas llevaban a cabo estas actividades.

Recomendaciones de Gartner para afrontar con éxito DevSecOps

Las recomendaciones de los analistas para afrontar con éxito este nuevo enfoque son claras. A continuación, os dejo las de Gartner para sacar el máximo partido y no morir en el intento:

  • Se trata de adaptar herramientas y procesos a los desarrolladores, y no al revés.
  • No intentéis eliminar todas las vulnerabilidades durante el ciclo de desarrollo.
  • Identificad y eliminad primero las vulnerabilidades de código abierto conocidas.
  • Adaptad los análisis de pruebas estáticos y dinámicos de código (SAST vs DAST) al nuevo contexto de trabajo.
  • Hay que capacitar a los desarrolladores, pero no esperéis que se conviertan en expertos en seguridad.
  • Adoptad un modelo de Security Champions (un grupo de especialistas de seguridad distribuidos por el resto de departamentos) e implementad una herramienta sencilla para la recogida de requisitos de seguridad.
  • Aplicad la misma filosofía de análisis de código para los despliegues automatizados, vía secuencias de comandos o de infraestructura como código.
  • Implementad un proceso de control de versiones del código y los componentes que lo forman.
  • Implementad un proceso de gestión de secretos y dotadlo de la herramienta adecuada.
  • Incorporad al proceso de diseño el concepto de infraestructura inmutable.
  • Revisad cómo se manejan los incidentes de prestación de servicios, incluyendo en el proceso la gestión de la seguridad.
  • Y, por último, incluid el aprovisionamiento de acceso dinámico para los desarrolladores.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *