Cómo crear un pipeline de CI/CD con la seguridad en mente

La integración continua (CI) y la entrega continua (CD) se han convertido en prácticas generalizadas entre los equipos de DevOps. El proceso de CI/CD se centra en crear e implementar aplicaciones nuevas o publicar actualizaciones para cargas de trabajo que ya están implementadas. Por eso, la mayoría de las iniciativas de CI/CD buscan acelerar el desarrollo. 

Sin embargo, las prácticas de CI/CD pueden lograr mucho más que facilitar la implementación de cargas de trabajo. Por ejemplo, también podemos usar CI/CD como un pipeline que prioriza la seguridad, somete el código a pruebas de seguridad, analiza el código fuente en busca de vulnerabilidades y ejecuta otras comprobaciones esenciales antes de implementar los componentes de la aplicación.

Cómo es un pipeline de CI/CD que prioriza la seguridad

Empecemos por visualizar el pipeline de CI/CD como una ruta lineal que va del desarrollo a las operaciones.

Los desarrolladores comienzan con el proceso de compilación y luego registran su código en un sistema de control de versiones como Git. El código se valida y se empaqueta; después, el archivo del paquete —como un Webdeploy.zip para .NET o una imagen de contenedor Docker— se publica en el entorno de ejecución de destino (por ejemplo, un host de Docker o un entorno de Kubernetes). A continuación, los equipos de operaciones asumen el control y administran el entorno.

Con esto en mente, veamos cómo podría cambiar este proceso el concepto de optimización de la seguridad en CI/CD conocido como «desplazar la seguridad a la izquierda», al incorporar prácticas de seguridad a lo largo de todo el ciclo. En el contexto de la seguridad, desplazarla a la izquierda significa integrar la conciencia y el enfoque en la seguridad lo antes posible en el ciclo de DevOps y mantenerlos en cada etapa del proceso. 

Sin embargo, es importante tener en cuenta que la mayoría de las recomendaciones sobre desplazar la seguridad a la izquierda se basan en un concepto general que consiste en incorporar cualquier aspecto de DevOps (pruebas, automatización operativa y seguridad) más cerca de quien lo implementa. El objetivo es cerrar el ciclo de retroalimentación y conocer más rápido los resultados de los cambios en esas áreas. 

La mayoría de las organizaciones ya desplaza de esta manera otros ciclos de procesos de DevOps, pero no logra hacerlo con la seguridad o se queda a medio camino. Por eso surgió el término DevSecOps, para destacar la importancia de incluir la seguridad en las prácticas de DevOps.

Veamos algunas capacidades de seguridad comunes que podemos integrar en cada estructura de pipeline de CI/CD.

Como muestra este diagrama, es posible establecer un flujo de CI/CD que priorice la seguridad sin cambiar el proceso de CI/CD en sí. Adoptar este tipo de flujo centrado en la seguridad permite que los equipos de DevOps integren capacidades de seguridad en cada ciclo de CI/CD. 

Veamos con más detalle algunos de los aspectos clave de seguridad que se mencionan en el diagrama, qué componentes podemos incorporar en un pipeline de CI/CD y qué beneficios de seguridad ofrecen. 

Modelado automatizado de amenazas

Las herramientas de modelado de amenazas analizan las aplicaciones para detectar fallas de seguridad conocidas, vulnerabilidades y otros riesgos. Ayudan a las organizaciones a identificar, reconocer y anticipar amenazas, y facilitan la toma de decisiones proactiva para evitarlas o mitigarlas. 

En nuestro diagrama del pipeline de CI/CD, el modelado de amenazas aparece como primer paso, pero suele llevarse a cabo antes de que comience el desarrollo. Lo ideal es repetirlo en distintas etapas de CI/CD; aquí es donde resulta útil un enfoque automatizado para el modelado de amenazas. 

Lista de materiales de software

Cada vez más desarrolladores de código fuente usan código que proviene de otros lugares. Por eso, puede ser difícil hacer un seguimiento de recursos —como fragmentos de código open source, paquetes de software o contenedores Docker— durante el ciclo de vida de desarrollo de una aplicación. En situaciones como esta, resulta útil una lista de materiales de software (SBOM).

La SBOM permite que los equipos de desarrollo cataloguen aspectos de los componentes de software, como la ubicación de los paquetes y sus dependencias, y ofrece visibilidad de los componentes de una aplicación. Esta información también permite comparar los paquetes de la aplicación con vulnerabilidades de seguridad conocidas, lo que ayuda a identificar dónde y cómo podrían explotar el código los usuarios maliciosos. Por estos motivos, las SBOM se han convertido en una parte fundamental de los pipelines de CI/CD que priorizan la seguridad. 

Firma de artefactos

A menudo, los desarrolladores reutilizan artefactos en distintas aplicaciones para agilizar el proceso. En el desarrollo de software, un artefacto es cualquier software o información sobre el software —como las SBOM mencionadas anteriormente— que aporta funciones y capacidades a un ciclo de vida de desarrollo de software más amplio. 

Podemos considerar como artefacto el resultado de crear o compilar código de desarrollo (el resultado de CI). Otros artefactos comunes incluyen los paquetes NuGet para .NET, npm para el desarrollo con Node.js y Maven para Java. Incluso podemos considerar artefactos los scripts de PowerShell o Bash. 

Para proteger los recursos y garantizar su autenticidad, los ingenieros de DevOps pueden considerar la posibilidad de firmar digitalmente el código fuente que producen. Esta firma digital es un requisito para los desarrolladores de aplicaciones que usan plataformas de distribución como App Store de Apple y Google Play Store. Una firma digital vinculada a un certificado permite que quien recibe el código fuente determine qué organización originó el artefacto. También garantiza que ninguna persona no autorizada haya manipulado el código. 

Sin embargo, el proceso de firma digital es complejo y requiere gestionar certificados de infraestructura de clave privada. Por suerte, podemos integrar una herramienta de automatización en nuestro pipeline de CI/CD para implementar firmas digitales. 

Pruebas unitarias para validar la seguridad

Las pruebas unitarias permiten que los desarrolladores validen la calidad y el resultado de una pequeña unidad de software funcional. Estas pruebas garantizan que cada parte del código funcione según lo esperado. Aunque se usan principalmente para probar la integridad y la funcionalidad del código, también podemos emplearlas específicamente para validar la seguridad. 

Las pruebas unitarias pueden comprobar si cada fragmento de código presenta vulnerabilidades conocidas detectadas por el análisis de modelado de amenazas, por lo que son útiles para este proceso. 

Analizar la infraestructura como código (IaC)

La infraestructura como código (IaC) permite que los equipos de DevOps definan el estado final de la infraestructura necesaria y la implementen mediante un enfoque basado en plantillas. Cada plataforma de nube pública ofrece sus propias herramientas de IaC, como Azure (ARM Templates y Bicep), AWS (CloudFormation) y GCP (Deployment Manager). 

Para los entornos multinube, las organizaciones pueden considerar una solución multiplataforma como Terraform de HashiCorp, que evita la complejidad de aprender la sintaxis de varios lenguajes de plantillas. Si la mayoría de tu equipo de DevOps tiene experiencia en desarrollo, una solución como Pulumi puede ser una alternativa excepcional. En lugar de ofrecer plantillas, Pulumi usa bibliotecas de código y código real, y es compatible con varios lenguajes populares, como JavaScript, Python y DotNet. También es compatible con varias plataformas de nube.  

Los archivos de plantillas de IaC se parecen al código fuente de una aplicación: contienen componentes de definición, variables y enlaces a otros artefactos. Por eso, también debemos aplicar a IaC todas las optimizaciones orientadas a la seguridad. La automatización de estos procesos también es eficaz en este caso. Por ejemplo, Snyk automatiza el análisis de vulnerabilidades de seguridad en IaC para ayudar a los equipos de DevOps a analizarlas de forma rápida y eficiente. 

Análisis automatizado de vulnerabilidades

El análisis de vulnerabilidades permite que los ingenieros de DevOps integren este tipo de análisis en el proceso del pipeline de CI/CD. En este contexto, suele realizarse mediante pruebas de seguridad de análisis estático (SAST) o pruebas dinámicas de seguridad de aplicaciones (DAST). 

Primero, SAST analiza el código fuente en reposo y realiza una validación detallada directamente como parte del control de versiones. Luego, puede ejecutarse otro proceso de análisis de vulnerabilidades cuando el código se compila y se integra con los paquetes de software. Este proceso analiza el código fuente del desarrollador para detectar amenazas de seguridad y examina a fondo cualquier paquete adicional, como contenedores Docker o bibliotecas de software. Por último, DAST se integra una vez publicada la aplicación y prueba la seguridad de la aplicación en ejecución. Sin analizar el código fuente, imita las acciones de un hacker o usuario malicioso para probar las defensas del código. 

Hay diversas herramientas que pueden ayudar a analizar el código o automatizar el análisis. Por ejemplo, Snyk ofrece potentes capacidades de seguridad y análisis de código para las herramientas y plataformas de DevOps más comunes disponibles actualmente. 

Seguridad continua 

Estos son algunos aspectos clave para integrar controles de seguridad en cada ciclo de DevOps. Coinciden con el concepto de la industria de «desplazar la seguridad a la izquierda», que promueve integrar controles de seguridad lo antes posible en el proceso de DevOps. 

El resultado es una práctica de seguridad continua que protege cada parte del ciclo de desarrollo. Estas estrategias ayudan a los equipos de DevOps a avanzar en sus prácticas de seguridad y transformar el desarrollo y las operaciones (DevOps) en desarrollo, seguridad y operaciones (DevSecOps). 

DevSecOps destaca que debemos integrar mecanismos de validación de seguridad desde las primeras etapas del desarrollo y en cada etapa de DevOps. Por ejemplo, podemos comenzar con el modelado de amenazas en la fase de arquitectura, incluir análisis de seguridad en el control de versiones y durante la compilación del código, y validar la seguridad durante la publicación y en el entorno de ejecución de la carga de trabajo una vez que esté operativa.

La seguridad continua puede —y debe— ser una parte integral de la gestión del ciclo de vida del desarrollo de software. 

Optimizar las prácticas de CI/CD y la seguridad

Históricamente, los procesos de CI/CD se han usado para optimizar la velocidad de publicación del software. Sin embargo, también pueden ser muy útiles cuando se integran en las prácticas de seguridad y se convierten en un pipeline de CI/CD que prioriza la seguridad en todas sus etapas. Dado que las ciberamenazas y los ataques de ciberseguridad evolucionan constantemente, proteger el ciclo de vida del software requiere una metodología de seguridad más activa que nunca. 

Algunas pautas de seguridad útiles para los equipos de ingeniería de DevSecOps incluyen el modelado automatizado de amenazas, las SBOM, la firma de artefactos y el análisis automatizado de vulnerabilidades. Adoptar estrategias como estas permite avanzar hacia la supervisión continua de la seguridad. De esta manera, tu organización se beneficia de publicaciones de software más rápidas que, además, incorporan las mejores prácticas de seguridad.