Seguridad de CI/CD: cómo proteger su pipeline de CI/CD
La pipeline de CI/CD (integración y distribución continuas) es la base sobre la que se construyen todos los procesos de DevOps. Por lo tanto, proteger las pipelines de CI/CD en cada etapa y en cada herramienta y entorno que componen la pipeline, debería ser una prioridad para cualquier organización que adopte DevOps.
Siga leyendo para saber por qué la seguridad de CI/CD es importante y conocer las mejores prácticas para reforzar la seguridad en toda la pipeline.
¿Qué es la seguridad de CI/CD?
La seguridad de CI/CD es un proceso de varias etapas cuyo objetivo es identificar y mitigar los riesgos de seguridad en cada etapa de la pipeline de CI/CD.
Los requisitos específicos de seguridad de CI/CD varían de un equipo a otro en función de las características únicas de las operaciones de CI/CD de cada equipo. Aunque todas las pipelines de CI/CD incluyen un mínimo de etapas básicas como la gestión del código fuente, la construcción, las pruebas y el despliegue, algunos también tienen ramas de características que añaden complejidad (y riesgos de seguridad) a la pipeline. Del mismo modo, las pipelines de CI/CD que tienen como destino varios entornos de producción (como los servidores Windows y Linux) son más complejos e implican más riesgos de seguridad que los que envían aplicaciones a un solo tipo de entorno.
La manera de enfocar la seguridad de CI/CD depende, por tanto, de cómo sean exactamente sus procesos de CI/CD y de las herramientas que utilice para gestionarlas. En cualquier caso, el objetivo principal a la hora de proteger una pipeline de CI/CD debería ser garantizar que, independientemente de los pasos que siga el código a medida que transcurre por la pipeline, se mitiguen todos los riesgos potenciales en todas las etapas.
Amenazas de seguridad de CI/CD
Además de conocer cómo funciona su pipeline, también debe reconocer los distintos tipos de amenazas a la seguridad que podrían afectar a las operaciones de CI/CD y tomar medidas para combatirlas.
Aunque es imposible identificar todos los tipos de riesgos de seguridad de CI/CD antes de que se produzca, los ejemplos más comunes son:
- Un código inseguro que se importa a una pipeline de CI/CD desde una fuente de terceros, como un proyecto de código abierto.
- El acceso no autorizado a los repositorios de código fuente o a las herramientas de compilación, lo que podría permitir a los atacantes inyectar código malicioso en una aplicación.
- Una vulnerabilidad del entorno de desarrollo y prueba que permita al atacante inhabilitar una prueba de seguridad importante, impidiendo así que el equipo detecte una brecha de seguridad en la fase de prueba de la pipeline.
- Una gestión de secretos poco segura dentro de la pipeline debido a prácticas como la incrustación de contraseñas en las plantillas de IaC. Los atacantes que consigan acceder a esta información podrían utilizarla para crear una brecha de seguridad.
Cómo proteger una pipeline CI/CD
Puesto que las amenazas de CI/CD afectan a distintas etapas del proceso y a diferentes capas de la pila de software, la seguridad del proceso de CI/CD requiere un enfoque múltiple. Es necesario desplegar herramientas y procesos que sean capaces de detectar una gran variedad de amenazas.
A continuación se enumeran categorías clave de herramientas y procedimientos recomendados para ayudar a detectar y gestionar los riesgos de seguridad de CI/CD.
Análisis de composición de software
El análisis de composición de software (SCA) es el escaneo del código fuente para detectar las vulnerabilidades que se originan en módulos o bibliotecas de terceros, como los que se importan desde un proyecto de código abierto. Las herramientas de SCA pueden escanear sus repositorios de código fuente al principio de la pipeline de CI/CD y alertarle de las dependencias que pueden conducir a vulnerabilidades de seguridad en su aplicación de producción.
Pruebas de seguridad de aplicaciones estáticas
Las pruebas de seguridad de aplicaciones estáticas (SAST) complementan el SCA examinando el código fuente que usted ha escrito en busca de posibles vulnerabilidades. En otras palabras, mientras que SCA identifica vulnerabilidades en el código de terceros basándose en bases de datos de vulnerabilidades conocidas, SAST realiza un análisis inicial del código personalizado para encontrar posibles problemas de seguridad, como la validación incorrecta de entradas.
De este modo, al realizar SAST al principio de su pipeline de CI/CD junto con el SCA, dispondrá de una segunda capa de defensa contra los riesgos de seguridad en el código fuente.
Controles de Acceso de CI/CD
El uso de controles de acceso para gestionar quién puede acceder a qué herramientas y recursos dentro de la pipeline de CI/CD es esencial para prevenir ataques en los que se inyectan código malicioso en el entorno de desarrollo, que es el vector de ataque utilizado en la desafortunada vulnerabilidad de SolarWinds que se dio a conocer en 2020.
Para gestionar este tipo de riesgos, todas las herramientas de la pipeline de CI/CD deben estar protegidas con contraseñas, claves de acceso u otros controles de acceso, y el acceso se debe otorgar de forma granular únicamente a los miembros del equipo que lo necesiten expresamente. Aunque puede resultar tentador otorgar a todos los desarrolladores e ingenieros acceso a todos los recursos de CI/CD, no es una práctica recomendable. Esto no solo se aleja del principio de mínimo privilegio, sino que además aumenta en gran manera las probabilidades de que una cuenta vulnerada regale a los atacantes las claves de todo el reino de CI/CD de su equipo.
Gestión de secretos y CI/CD
Los secretos como las contraseñas y las claves de acceso son a menudo necesarios en varias de las etapas del proceso de CI/CD para integrar o crear código, desplegar aplicaciones en la fase de prueba o producción, etc.
La forma más sencilla de compartir estos secretos es, por lo general, incrustarlos en los archivos de configuración de CI/CD o en las plantillas de IaC que su equipo utiliza para aprovisionar los entornos de las aplicaciones. Pero también en este caso, el camino fácil no es el camino seguro. Todo aquel que pueda ver los archivos de configuración o las plantillas de IaC puede acceder fácilmente a los secretos incrustados en el código fuente, lo que supone un riesgo de seguridad importante.
Lo más recomendable es utilizar un gestor de secretos seguro para almacenar los datos sensibles y compartirlos cuando sea necesario durante las operaciones de CI/CD.
Escaneo de registros
Si su pipeline de CI/CD despliega aplicaciones utilizando containers, puede añadir otra capa de protección realizando un escaneo automático de imágenes de los containers cuando llegan a los registros. El escaneo de registros comprueba las vulnerabilidades de los containers, permitiendo así que su equipo detecte códigos maliciosos que puedan haber pasado desapercibidos en las pruebas de seguridad realizadas durante las primeras etapas de la pipeline de CI/CD.
El escaneo de registros es muy importante, ya que algunas vulnerabilidades pueden introducirse no en la etapa de código fuente de la pipeline, sino como parte de las dependencias que se incorporan posteriormente a un container. Por consiguiente, las herramientas SCA y SAST no detectarán estas vulnerabilidades, dado que solo escanean el código fuente. Pero el escaneo de registros sí lo hará en la mayoría de los casos.
Seguridad en tiempo de ejecución
La seguridad en tiempo de ejecución, que es la detección de amenazas activas en entornos en los que se están ejecutando las aplicaciones, le ayuda a gestionar las amenazas durante la última etapa importante del piepeline de CI/CD: el despliegue en producción. La seguridad en tiempo de ejecución también se puede aplicar a los entornos de desarrollo y prueba como parte de una estrategia de seguridad “shift-left”.
La seguridad en tiempo de ejecución se basa en una serie de herramientas y fuentes de datos, como los registros de aplicaciones, las métricas de red y los registros de auditoría. Su enfoque de la seguridad en tiempo de ejecución dependerá de cómo sea su entorno de ejecución (si utiliza containers, qué orquestador utiliza, etc.), pero el objetivo principal debe ser detectar las amenazas activas antes de que escalen.
Una pipeline de CI/CD poco segura dará como resultado inevitablemente una aplicación insegura. Gestionando los riesgos de seguridad en todas las etapas de la pipeline mediante procedimientos como el control de acceso, la gestión de secretos y el análisis de registros, puede minimizar el riesgo de que el código inseguro se transmita a su pipeline.