Skip to main content

Cómo reforzar la seguridad de tu pipeline de CI/CD

Escrito por
blog feature supply chain sbom

12 de julio de 2023

0 minutos de lectura

DevSecOps se refiere a la integración de prácticas de seguridad en el proceso de DevOps. Con los ciclos de desarrollo modernos, no puedes dejar la seguridad para el final. Debe integrarse en cada etapa.

La seguridad de la integración continua y la entrega continua (CI/CD) es una parte importante de DevSecOps. Es fundamental proteger tus pipelines y asegurarte de que los sistemas automatizados que se usan para implementar CI/CD no sean vulnerables a ataques.

En este artículo, aprenderás sobre los riesgos de seguridad que pueden amenazar tu pipeline de CI/CD. También aprenderás a crear pipelines reforzados contra ataques y a probarlos para verificar su seguridad.

Por qué debes proteger tu pipeline de CI/CD

Al pensar en seguridad, suelen enfocarse en las aplicaciones web y los servicios públicos. Es fácil pasar por alto aspectos que parecen secundarios, como tu pipeline, pero eso es un error: las consecuencias de no proteger adecuadamente la CI/CD pueden ser graves.

Un pipeline comprometido puede darles acceso a tus sistemas a los hackers. Esto puede incluir el acceso a tu código, datos valiosos y secretos de clientes. Si una parte de tu pipeline se ve comprometida, todo lo que contiene queda vulnerable.

También existe el riesgo de que se inyecte código malicioso, un tipo de ataque sutil pero muy grave. Un atacante con acceso a tu pipeline puede insertar su propio código, que luego se integra en tu compilación final sin que lo sepas. Así, la aplicación que implementas queda comprometida y los atacantes pueden robar tus datos y los de tus usuarios.

Además, una cadena de compilación comprometida puede filtrar secretos. Pueden robar las contraseñas o credenciales que autorizan el uso de tus herramientas y usarlas para acceder a otras partes de tu sistema. Un hacker puede causar mucho daño con credenciales robadas, por eso es fundamental protegerlas.

Además, ten cuidado con los componentes obsoletos, ya que pueden ser los más vulnerables a los ataques. Todo el tiempo se descubren nuevos vectores de ataque, y el software se actualiza y se corrige para eliminarlos, pero el software antiguo sigue desprotegido.

Actualizar tu software a las versiones más recientes tiene muchos beneficios, además de mejorar la seguridad. Mantener tu cadena de herramientas actualizada debe ser una parte fundamental de tu estrategia de seguridad.

Cómo crear un pipeline de CI/CD seguro

Por suerte, puedes hacer mucho para protegerte de los ataques. Veamos algunas medidas que puedes tomar.

Implementa el control de acceso basado en roles

El control de acceso basado en roles (RBAC) te permite limitar el acceso a distintas partes de tu sistema. Puedes otorgar acceso a las personas según sus roles. Así, es más fácil definir reglas seguras con distintos niveles de acceso e implementarlas rápidamente.

Administrar el acceso por usuario puede parecer seguro, pero en la práctica genera problemas, como pasar por alto cuentas antiguas y mantener privilegios otorgados durante demasiado tiempo. Con RBAC, tienes un conjunto fijo de reglas que puedes otorgar o revocar en bloque.

Busca vulnerabilidades

Las herramientas automatizadas son esenciales para buscar vulnerabilidades. Por suerte, hay muchos sistemas de análisis de seguridad que te ayudan a encontrar problemas de forma rápida y eficiente. Pueden detectar errores de código o problemas de configuración que dejan tu sistema expuesto a ataques.

También puedes pedir ayuda externa y contratar a un tercero para que realice una auditoría de seguridad y detecte lo que quizás se te haya pasado por alto. Alguien que no esté tan involucrado en el proyecto como tú puede encontrar puntos ciegos que quizá no habías considerado.

Usa un administrador de secretos

Los administradores de secretos son herramientas que almacenan datos confidenciales, como credenciales o claves, y administran el acceso a ellos. Al limitar quién puede acceder a esos datos, desde dónde y cómo, se reducen considerablemente las posibilidades de que se filtren. Además, una buena herramienta de administración de secretos cifra los datos tanto en reposo como en tránsito, lo que minimiza el impacto de una filtración.

Muchas plataformas de CI tienen su propio sistema integrado para administrar secretos y credenciales; algunas incluso se integran con sistemas externos populares de administración de secretos.

Administra la exposición de la red

El acceso irrestricto a la red puede dejar tus sistemas de CI/CD vulnerables a ataques externos (tráfico entrante) y facilitar la exfiltración de datos (tráfico saliente). Administrar la exposición de la red cerrando los accesos que tu pipeline no necesita te ayuda a estar más protegido.

Por ejemplo, abre la menor cantidad posible de puertos y ciérralos cuando no los necesites. Además, desactiva las funciones remotas que no uses. Debes proteger rigurosamente los sockets de Docker, las API y cualquier otro medio que usen tus sistemas para comunicarse con el mundo exterior.

Limita los límites de confianza

Otra forma de mitigar el riesgo es limitar los límites de confianza tanto como sea posible. Debes proteger todas las comunicaciones entre sistemas o usuarios externos. Limita lo que se permite a lo estrictamente necesario y, de ser posible, otorga acceso solo por un período determinado.

Si te aseguras de que cada parte de tu cadena revele la menor cantidad de información posible, también será más difícil que te hackeen. Los textos que se muestran, como los mensajes de error, podrían aparecer en una parte pública de tu sistema. Luego podrían usarse para crear una imagen detallada de tu infraestructura y ayudar a los hackers a dirigir sus ataques.

Para evitarlo, en algunos casos puedes ejecutar comandos con una salida mínima. Así, los registros o mensajes de salida que puedan filtrarse revelan la menor cantidad posible de información sobre tu sistema.

Por ejemplo, el comando wget en Bash muestra todo tipo de información. Puedes suprimirla con la opción q, así:

wget -q https://google.com

Los hackers suelen avanzar por tu cadena de herramientas y aprender sobre tu sistema a medida que lo hacen, por lo que reducir la salida limita las oportunidades que tienen para hacerlo. Puedes aplicar opciones similares a otros comandos.

Cómo automatizar la seguridad de un pipeline de CI/CD

Por suerte, puedes abordar varios de estos problemas con un producto de seguridad como Snyk, que se ejecuta como parte de tu pipeline de compilación y te ayuda a detectar y responder rápidamente a los problemas.

Por ejemplo, ejecutar un analizador de vulnerabilidades en tu pipeline puede detectar problemas relacionados con componentes obsoletos. Snyk puede encontrar y detectar este tipo de problemas. Para encontrar problemas desde la terminal, solo escribe lo siguiente:

snyk test

También puedes integrar tu sistema de administración de código fuente, como GitHub, con Snyk para agregar automáticamente comprobaciones de PR que detecten nuevas vulnerabilidades en dependencias, contenedores o políticas de infraestructura como código:

Interfaz de pipeline de CI/CD que muestra una marca de verificación verde, «Todas las verificaciones se aprobaron» y una verificación de seguridad/Snyk marcada como omitida

Obtén más información sobre cómo integrar Snyk con las comprobaciones de PR en la documentación de soporte de Snyk.

Cómo integrar pruebas de seguridad en un pipeline de CI/CD

Puedes incluir pruebas de seguridad en tu pipeline. Como las pruebas pueden buscar distintos problemas, asegúrate de cubrirlos todos.

RBAC

Como mencionamos, el RBAC es una excelente manera de proteger distintas partes de tu sistema. Las pruebas periódicas pueden asegurar que siga siendo seguro. Las comprobaciones automatizadas pueden verificar que los usuarios solo accedan a los recursos que corresponden a su rol. Por ejemplo, una prueba con un usuario anónimo no debería permitirle acceder a los recursos que quieres reservar para usuarios autorizados. Esta prueba podría fallar, por ejemplo, si actualizas el software y cambian sus ajustes, lo que hace que dejen de aplicarse los cambios de configuración realizados anteriormente.

API

También puedes automatizar las pruebas de API. Para proteger la seguridad, necesitas una combinación de pruebas que tengan éxito con las credenciales correctas y fallen cuando no se proporcionen.

Acceder correctamente a un recurso sin las credenciales adecuadas es un fallo de seguridad. Las pruebas automatizadas de API te permiten verificarlo con rapidez y regularidad. También puedes comprobar que tus API devuelvan el resultado esperado y respondan adecuadamente a solicitudes malformadas diseñadas para vulnerar tu seguridad.

Secretos

Las pruebas de secretos te permiten comprobar si quedan expuestos en algún momento. Los pipelines deben administrar contraseñas y tokens, y las herramientas de tu cadena necesitan los privilegios adecuados para cumplir sus funciones.

Ten cuidado de no filtrar tus secretos en las pruebas, ya que alguien podría acceder a ellos. Snyk puede detectar secretos codificados de forma fija en tu código o tus scripts para que puedas solucionar el problema.

Cómo proteger un pipeline de CI/CD de Jenkins con Snyk

Para empezar a usar Snyk, debes registrarte e instalar el cliente localmente. Encontrarás las instrucciones de instalación aquí. Por ejemplo, si usas npm, puedes ejecutar el siguiente código:

npm install snyk -g

Snyk también se integra con los principales proveedores de nube y con muchas otras herramientas de CI/CD, y cuenta con numerosos plugins que facilitan estas integraciones. Por ejemplo, para usarlo con Jenkins, ve al panel de Jenkins y luego a Manage Plugins. Después, busca Snyk Security en la pestaña Available. No olvides registrar el plugin y conectarlo a tu cuenta.

Una vez que hayas integrado Snyk, puedes agregarlo como una etapa de tu pipeline con la entrada snykSecurity:

//build stage omitted 

stage('Test') {
      steps {
            echo 'Testing with Snyk'
            snykSecurity(
                  snykInstallation: '<Snyk Installation Name>',
                  snykTokenId: '<Snyk API Token ID>',
                  // other parameters here
            )
      }
}

//deploy stage omitted

Estos son otros comandos que puedes usar para controlar el comportamiento de Snyk:

  • failOnIssues y failOnError: Estos comandos te permiten detener el script si se cumple cualquiera de estas condiciones y evitar que los problemas detectados por Snyk lleguen a los despliegues. Es especialmente recomendable si tu CI/CD automatiza el despliegue de cualquier elemento que se publique.

  • severity: Te permite especificar la gravedad de los problemas que Snyk investigará. Podrías ignorar los problemas menos graves y permitir que las compilaciones continúen si solo se detectan problemas menores. También podrías ejecutar una etapa de compilación independiente con un comportamiento distinto según la gravedad del problema.

Al ejecutar tus compilaciones, puedes ver si hay problemas en la consola de Snyk y consultar los registros en detalle para averiguar qué debes corregir.

Así se configura Snyk con Jenkins, pero hay muchas otras posibilidades, como integrar Snyk con GitHub o con proveedores de nube como Amazon Web Services (AWS) y Azure.

Conclusión

Tu pipeline de CI/CD es una parte fundamental de tu estrategia de seguridad, pero es fácil pasarla por alto. Los hackers pueden aprovecharla de muchas maneras, por lo que es fundamental que tomes medidas para mitigar todos los vectores de ataque.

Debes protegerte e intentar adelantarte a quienes buscan comprometer tus sistemas. Las actualizaciones de seguridad, las pruebas automatizadas y la administración de roles son solo algunas de las formas de reforzar tu sistema y mantener alejados a los atacantes.

Snyk es una excelente herramienta para tu arsenal que te permite controlar tu pipeline. Visita su sitio web y comienza a proteger la seguridad de tu CI/CD. Con Snyk, es fácil mantenerte protegido.

Empieza con Capture the Flag

Aprende a resolver desafíos de Capture the Flag viendo nuestro taller virtual introductorio a pedido.