Aplicar prácticas de DevOps durante la programación y desarrollo de software permite conseguir que el ciclo de vida de este sea mucho más rápido y eficiente. Además, la planificación, coordinación e implicación de los diferentes equipos y roles (desarrollo, operaciones, seguridad…) desde el principio y a lo largo de todo el proceso, facilita adaptarse mejor a las necesidades de cada cliente, aumentar su confianza y mejorar la calidad de los productos.

Este marco de trabajo es, sin duda, clave para una organización que quiere sacarle el máximo partido a la era digital, destacar frente a la competencia y alcanzar sus objetivos de negocio ahorrando costes.

Sin embargo, la complejidad de las aplicaciones de software puede suponer la presencia de determinadas vulnerabilidades en cualquier fase del ciclo del proceso, las cuales pueden poner en riesgo la seguridad y actividad de la organización.

Para evitarlo, es de vital importancia no caer en una serie de malas prácticas que, con más frecuencia de la deseada, suelen cometerse. A continuación, detallamos cuáles son los 10 fallos de seguridad más habituales durante el ciclo DevOps, qué impacto pueden tener en una organización y qué solución podría adoptarse:

1. Mecanismos de control de flujo insuficientes:

Los procesos de integración continua (CI) y entrega contigua (CD) permiten enviar el código desde un entorno a producción de forma muy rápida.

Ejemplo de impacto: abuso de reglas de fusión en el CI, generando código malicioso no revisado.

Ejemplo de solución: evite enviar implementaciones a producción sin revisión adicional.

2. Gestión inadecuada de identidad y acceso:

Los procesos de entrega de software consisten en múltiples sistemas conectados entre sí.

Ejemplo de impacto: una de las múltiples identidades del ecosistema CD/CI puede generar la escalada de privilegios hasta tomar el control de los sistemas.

Ejemplo de solución: audite todas las identidades y monitorice el comportamiento anómalo.

3. Abuso de la cadena de dependencia:

La gestión de dependencias y paquetes externos aumentan exponencialmente en todos los desarrollos a medida.

Ejemplo de impacto: robo masivo de credenciales y realización de movimientos laterales.

Ejemplo de solución: almacene internamente todos los paquetes externos en repositorios revisados.

4. Ejecución de tuberías envenenadas (PPE):

Un atacante con acceso a los sistemas de control de fuentes puede manipular el proceso de construcción inyectando comandos ejecutables en la compilación.

Ejemplo de impacto: envenenar la cadena CI, logrando el robo de credenciales.

Ejemplo de solución: ejecutar en un nodo aislado las canalizaciones que ejecuten código no revisado.

5. PBAC insuficiente (controles de acceso basados en tuberías):

Los nodos de ejecución tienen acceso a sistemas del entorno de ejecución, lo que permite abusar del privilegio para realizar movimientos laterales.

Ejemplo de impacto: exposición de datos confidenciales y movimientos laterales del entorno CI.

Ejemplo de solución: uso de nodos compartidos para canalizaciones del mismo nivel de confidencialidad.

6. Higiene de credenciales insuficiente:

Los entornos CD/CI están construidos con múltiples sistemas que se comunican y autentican entre sí, lo que supone un desafío a la protección de las credenciales.

Ejemplo de impacto: obtención de credenciales para el acceso a recursos de alto valor.

Ejemplo de solución: mapeo continuo de las credenciales que se encuentran en diferentes nodos del ecosistema.

7. Configuración insegura del sistema:

Los riesgos de configuraciones inseguras y la ausencia del hardening de los sistemas partícipes del CD/CI posibilitan múltiples ataques.

Ejemplo de impacto: acceso a todos los sistemas involucrados en el ecosistema CD/CI con privilegios.

Ejemplo de solución: disponer de un inventario con sistemas y versiones para mantenerlos actualizados.

8. Uso no regulado de servicios de terceros:

Es necesario que los servicios de terceros accedan a los sistemas y activos CD/CI.

Ejemplo de impacto: en este caso el impacto es múltiple. Somos tan seguros como las implementaciones de terceros consideren.

Ejemplo de solución: disponer de un inventario con sistemas y versiones para mantenerlos actualizados.

9. Validación incorrecta de la integridad del artefacto:

Los recursos finales dependen de múltiples fuentes repartidas en diferentes pasos, creando múltiples puntos de entrada que permiten manipular el recurso final.

Ejemplo de impacto: envío de artefactos maliciosos a través de la canalización, posibilitando la ejecución de código malicioso.

Ejemplo de solución: implementar procesos y tecnologías que validen la integridad de los recursos mediante firma.

10. Registro y visibilidad insuficientes:

Una monitorización insuficiente permite a un atacante permanecer largos periodos de tiempo para realizar sus ataques.

Ejemplo de impacto: imposibilidad de detectar, mitigar y remediar cualquier tipo de ataque.

Ejemplo de solución: crear un inventario de sistemas, especialmente los autogestionados, y centralizar los eventos en un SIEM.