Palabras clave: Docker,Kubernetes,CI/CD,Terraform,Azure DevOps,Trivy,DevOps,DevSecOps
Introducción
La digitalización ha transformado la ciberseguridad en un pilar esencial para empresas de todos los sectores, especialmente con el auge de tecnologías como Docker y Kubernetes. Sin embargo, al igual que otros elementos de la infraestructura informática, están expuestos a riesgos de seguridad. Por lo tanto, la evaluación de imágenes de contenedores juega un papel vital en este escenario [1].
Para fortalecer la calidad del software y las prácticas de desarrollo seguro, las organizaciones han recurrido cada vez más a herramientas automatizadas, como el análisis estático de código, para identificar y mitigar vulnerabilidades en etapas tempranas del ciclo de vida del desarrollo. Estas herramientas actúan como revisores en busca de vulnerabilidades desde las primeras etapas del desarrollo [2].
En el ciclo de vida del desarrollo de software, factores como la colaboración, la automatización, la velocidad y la eficiencia son fundamentales para impulsar la mejora continua. Estos principios se reflejan en prácticas como la Integración Continua (CI) y el Despliegue Continuo (CD), que son parte esencial de la filosofía DevOps [3].
En este entorno colaborativo, la seguridad se convierte en un aspecto crítico y compartido entre los equipos de desarrollo, seguridad y operaciones. Surge así el concepto de «DevSecOps», que integra la seguridad en todas las etapas del ciclo de vida del desarrollo de software. DevSecOps promueve una cultura centrada en la seguridad, la automatización de procesos de seguridad y el diseño de plataformas seguras desde el inicio hasta la operación del software [3].
Ahondando más en el desarrollo de tecnologías IT, otro aspecto crucial es la Infraestructura como Código (IaC). IaC es una metodología para gestionar y aprovisionar infraestructura de TI mediante archivos de definición legibles por máquina, en lugar de configuración manual o herramientas interactivas. Esto permite tratar la infraestructura de manera similar al código de aplicación, facilitando la automatización, el versionado y la consistencia en los entornos [5].
Al integrar IaC en el desarrollo de software, las organizaciones pueden lograr una mayor agilidad y eficiencia en la gestión de su infraestructura. Con IaC, las configuraciones de infraestructura se pueden codificar y gestionar como cualquier otro componente de software, lo que permite desplegar y escalar infraestructura de manera rápida, reproducible y fácilmente adaptable a ciclos CI/CD [5].
Ahora, al conectar estas prácticas con los principios de DevOps y DevSecOps, se puede ver cómo la automatización y la gestión de la infraestructura como código se alinean con la filosofía de colaboración, integración continua y seguridad en todas las etapas del ciclo de vida del desarrollo de software. Esto subraya aún más la importancia de herramientas que permitan analizar y gestionar de forma efectiva la infraestructura, las dependencias y las aplicaciones contenerizadas, asegurando tanto la eficiencia como la seguridad en las operaciones de TI.
Metodología.
En este ejercicio, se implementa una esquema de desarrollo seguro y eficiente mediante el uso de infraestructura como código (IaC) y principios de DevOps.
Para ello, se establece un pipeline con Azure Pipelines que permite automatizar varias etapas del desarrollo y despliegue de software. Este pipeline incluye el checkout de repositorios de backend y frontend, adicionalmente, el pipeline realiza una creación de contenedores con Docker y finalmente, procede a dar uso a la herramienta Trivy para análisis de contenedores, vulnerabilidades de código de scripts de Terraform, Dockerfiles y manifiestos YAML para el despliegue en AKS. Además, se asegura la publicación de los resultados obtenidos como artefactos y en formato HTML en el summary del pipeline, proporcionando así una visión clara y accesible del estado de seguridad del proyecto en cada etapa del ciclo de desarrollo. Esta estrategia integral garantiza tanto la eficiencia en el desarrollo como la seguridad de las aplicaciones y la infraestructura subyacente.
Trivy
Trivy es un escáner de vulnerabilidades simple y completo para contenedores y otros artefactos. Una vulnerabilidad de software es un fallo, defecto o debilidad presente en el software o en un sistema operativo. Trivy detecta vulnerabilidades en paquetes del sistema operativo (Alpine, RHEL, CentOS, etc.) y dependencias de aplicaciones (Bundler, Composer, npm, yarn, etc.). Trivy es fácil de usar, simplemente se instala el binario y ya estaría listo para escanear. Todo lo que se necesita para hacer para el escaneo es especificar un objetivo, como el nombre de la imagen del contenedor [6].Con la herramienta Trivy se puede realizar varios análisis, por ejemplo, analizar dockerfile, archivos de terraform (files.tf), archivos YAML de despliegues con kubernetes (AKS)
Resultados
Para la imagen docker del backend, en total, Trivy logró identificar cincuenta y cinco (55) vulnerabilidades conformadas por cuarenta y seis (46) vulnerabilidades bajas (LOW), siete (7) medias (MEDIUM), una (1) alta (HIGH) y una (1) crítica (CRITICAL).
Con respecto a la imagen docker del frontend, en conjunto, Trivy logró detectar noventa (90) vulnerabilidades distribuidas en setenta y seis (76) vulnerabilidades bajas (LOW), siete (7) medias (MEDIUM), cinco (5) altas (HIGH), dos (2) críticas (CRITICAL).
En relación al los scripts de terraform, como resultado, Trivy logró encontrar cuatro (4) vulnerabilidades en donde se evidencian cero (0) vulnerabilidades bajas (LOW), una (1) medias (MEDIUM), dos (2) altas (HIGH) y una (1) críticas (CRITICAL).
Trivy identificó un total veintisiete (27) vulnerabilidades y/o configuraciones erróneas de los archivos YAML para el deployment del backend y frontend. Entre estas, se detectaron dieciocho (18) vulnerabilidades de baja gravedad (LOW), seis (6) de nivel medio (MEDIUM), tres (3) de gravedad alta (HIGH), y cero (0) de gravedad crítica (CRITICAL).
En el análisis de Dockerfiles, Trivy identificó un total de cinco (5) vulnerabilidades y/o configuraciones erróneas. Entre estas, se detectaron dos (2) vulnerabilidades de baja gravedad (LOW), una (1) de nivel medio (MEDIUM), dos (2) de gravedad alta (HIGH), y cero (0) de gravedad crítica (CRITICAL).
En cada uno de los casos de análisis, Trivy proporciona información en cada vulnerabilidad detectada, la cual tiene un link que redirige a la respectiva documentación que informa tanto como corregir la vulnerabilidad y el porqué fue catalogada (LOW, MEDIUM, HIGH).
Análisis de resultados
En total, para todos los archivos involucrados en el ciclo de CI/CD se identificó un balance de ciento ochenta y un (181) vulnerabilidades y/o configuraciones erróneas. Entre estas, se detectaron ciento cuarenta y dos (142) vulnerabilidades de baja gravedad (LOW), veintidós (22) de nivel medio (MEDIUM), trece (13) de gravedad alta (HIGH), y cuatro (4) de gravedad crítica (CRITICAL).
Estos resultados indican que existen numerosas vulnerabilidades presentes en los distintos archivos analizados, que abarcan un amplio espectro de gravedad, desde críticas hasta bajas. Con base en dichos resultados, es importante que se implementen medidas para abordar estas vulnerabilidades.
Acorde a la definición de la administración de vulnerabilidades de Microsoft, los pasos correctos para administrar vulnerabilidades serían identificar, evaluar, tratar e informar sobre las vulnerabilidades [15]. Si bien, Trivy se encarga de identificar y evaluar el nivel de la vulnerabilidad, la herramienta no las resuelve pero sí sugiere como hacerlo, por tanto, se debe tener claro el proceder con esta información que nos disponibiliza la herramienta de análisis.
Según el artículo de IBM sobre gestión de vulnerabilidades, es crucial priorizar las vulnerabilidades de manera efectiva [14]. A continuación, se muestra la clasificación basada lo indicado por IBM y en los resultados obtenidos del análisis con Trivy:
Priorización de vulnerabilidades (HIGH and CRITICAL): las vulnerabilidades críticas y altas deben tratarse como prioridad máxima y abordarse de inmediato en el pipeline de desarrollo. Estas vulnerabilidades pueden ser explotadas para comprometer la seguridad del sistema y causar un daño significativo [14]. Por lo tanto, se debe considerar seriamente romper el pipeline ante la aparición de vulnerabilidades o configuraciones erróneas de este nivel. El enfoque inmediato en vulnerabilidades críticas y altas asegura que los sistemas permanezcan protegidos contra amenazas potencialmente devastadoras.
Mitigación de vulnerabilidades de nivel medio: aunque las vulnerabilidades de nivel medio no son tan críticas como las de nivel alto o crítico, aún representan un riesgo significativo para la seguridad. La mitigación a menudo se realiza cuando aún no está disponible un parche u otro medio de remediación para la vulnerabilidad [14]. Una organización debe tener claro el procedimiento para administrar las vulnerabilidades y establecer políticas claras para abordar estas de manera oportuna y efectiva.
Consideración de vulnerabilidades de bajo nivel: aunque las vulnerabilidades de bajo nivel pueden parecer menos preocupantes, y en muchos casos pueden tener un proceso de aceptación [14], no deben ignorarse por completo. Estas vulnerabilidades pueden acumularse y potencialmente ser utilizadas en ataques más complejos o como parte de una cadena de ataques. Por lo tanto, se debe considerar la mitigación de estas vulnerabilidades como parte integral de los esfuerzos de seguridad de una empresa.
Confiabilidad de resultados
Con el fin de evaluar la confiabilidad de la información que arroja Trivy en sus reportes, se procede con dar solución a una de las vulnerabilidades reportadas por la herramienta. Para efectos de este artículo, se resolverá una única vulnerabilidad crítica de la imagen del backend.
Links de consulta de las vulnerabilidades: https://access.redhat.com/errata/RHSA-2022:9058, https://access.redhat.com/security/cve/CVE-2022-1471,
https://bitbucket.org/snakeyaml/snakeyaml/commits/5014df1a36f50aca54405bb8433bc99a8847f758,
Inicialmente se puede observar que las bases de datos de las vulnerabilidades están actualizadas, y documentadas en sus respectivos links de consulta. Adicionalmente, se puede notar la fecha de publicación de la vulnerabilidad y la última fecha de modificación.
Posterior al entendimiento de la vulnerabilidad encontrada y la evaluación del riesgo de seguridad, se procede en busca de la actualización sugerida por Trivy, paso seguido, se añade al archivo de configuración que en este caso es es el build.gradle Y finalmente, se vuelve a analizar.
Después de abordar una vulnerabilidad, de tal forma que se lee sobre los riesgos, y se actualiza según lo sugerido, se observa que el riesgo crítico asociado a la vulnerabilidad, desaparece. A continuación se pueden destacar los siguientes puntos clave:
Trivy aprovecha bases de datos de vulnerabilidades de código abierto, que se actualizan regularmente para proporcionar información precisa y actualizada sobre las vulnerabilidades más recientes. Además, el proceso de actualización automática de estas bases de datos durante la ejecución del análisis garantiza que se estén utilizando datos fiables y relevantes para evaluar la seguridad de las imágenes de contenedor.
La confianza en Trivy se sustenta en su capacidad para analizar y detectar vulnerabilidades de forma efectiva, respaldada por el uso de bases de datos actualizadas. Al integrar Trivy en nuestros procesos de seguridad, se tiene la certeza de contar con una herramienta confiable y eficaz para evaluar y mejorar la seguridad de nuestras aplicaciones y entornos de contenedores.
Conclusiones
En resumen, Trivy se presenta como una solución integral y poderosa para fortalecer la seguridad en los procesos de desarrollo e implementación continua (CI/CD). Su capacidad para detectar un amplio rango de vulnerabilidades y configuraciones erróneas, desde las críticas hasta las de menor gravedad, resalta su valor como una herramienta esencial en la construcción de pipelines robustos y seguros.
Como se esperaba, Trivy demostró su versatilidad al analizar múltiples tipos de archivos, como Dockerfile, YAML, Terraform e imágenes Docker. Generando reportes ordenados, fáciles de entender y cómodos de leer, lo que demuestra su destreza en análisis con un toque amigable con el usuario el cual puede fácilmente ser implementado en un ciclo CI/CD.
En cuanto a la implementación de Trivy en fulujos CI/CD, no solo garantiza la identificación proactiva de riesgos, sino también promueve una cultura de seguridad y calidad en el desarrollo de software. Esto habilita el camino hacia una entrega más confiable y protegida de aplicaciones en entornos empresariales cada vez más desafiantes.
En conclusión, en relación con la seguridad, se puede afirmar que no es un destino al que se llega una vez y se deja atrás, sino más bien un viaje interminable a lo largo del cual continuamente se adapta y evoluciona. Se podría comparar con navegar en un océano siempre cambiante, donde cada ola representa una nueva amenaza o vulnerabilidad. La clave no es solo llegar a un destino seguro, sino navegar con sabiduría y perseverancia en el vasto y siempre cambiante mar de la ciberseguridad. Para garantizar una gestión continua de vulnerabilidades, se recomienda combinar el uso de Trivy con monitoreo regular, actualizaciones automáticas de bases de datos de vulnerabilidades y la implementación de políticas claras para abordar riesgos críticos y altos de manera inmediata.
Bibliografía
- Iberasync. (s. f.). Análisis de contenedores utilizando Trivy. Recuperado de https://iberasync.es/analisis-de-contenedores-utilizando-Trivy/
- OWASP. (s. f.). Static Code Analysis. Recuperado de https://owasp.org/www-community/controls/Static_Code_Analysis#
- Red Hat. (s. f.). What Is CI/CD?. Recuperado de https://www.redhat.com/es/topics/devops/what-is-ci-cd
- Trivy. (s. f.). Recuperado de https://Trivy.dev/
- Red Hat. (s. f.). What Is Infrastructure as Code (IaC)?. Recupado de https://www.redhat.com/en/topics/automation/what-is-infrastructure-as-code-iac
- Aqua Security. (s. f.). Trivy. Recuperado de https://aquasecurity.github.io/Trivy/v0.17.2/#:~:text=Trivy%20(%20tri%20pronounced%20like%20trigger,or%20in%20an%20Operating%20System.
- Microsoft. (s. f.). What Is Azure DevOps?. Recuperado de https://learn.microsoft.com/es-es/azure/devops/user-guide/what-is-azure-devops?view=azure-devops
- HashiCorp. (s. f.). Introduction to Terraform. Recuperado de https://developer.hashicorp.com/terraform/intro
- Semaphore. (s. f.). Continuous Container Vulnerability Testing with Trivy. Recuperado de https://semaphoreci.com/blog/continuous-container-vulnerability-testing-with-Trivy
- Universidad de los Andes. (s. f.). Proyecto: Análisis de vulnerabilidades en imágenes Docker utilizando Trivy. Recuperado de https://sistemas.uniandes.edu.co/maestrias/mesi/proyectos/proyecto.php?id=25
- Semaphore. (s. f.). Continuous Container Vulnerability Testing with Trivy. Recuperado de https://semaphoreci.com/blog/continuous-container-vulnerability-testing-with-Trivy
- IBM. (s. f.). Docker. Recuperado de https://www.ibm.com/topics/docker
- Aqua Security. (s. f.). Trivy Vulnerability Examples Report. Recuperado de https://aquasecurity.github.io/Trivy/v0.24.4/vulnerability/examples/report/
- IBM. (s. f.). Vulnerability Management. Recuperado de https://www.microsoft.com/es-co/security/business/security-101/what-is-vulnerability-management
- Microsoft. (s. f.). ¿Qué es la gestión de vulnerabilidades? | Microsoft Security. Recuperado de https://www.ibm.com/es-es/topics/vulnerability-management
- Google Cloud. (s. f.). What is Kubernetes?. Recuperado de https://cloud.google.com/learn/what-is-kubernetes
- Red Hat. (s. f.). What is Kubernetes? 2. Recuperado de https://www.redhat.com/en/topics/containers/what-is-kubernetes
- Amazon Web Services. (s. f.). What is DevSecOps?. Recuperado de https://aws.amazon.com/what-is/devsecops/#:~:text=DevSecOps%20stands%20for%20development%2C%20security,they%20are%20building%20software%20applications
- IIberasync. (s. f.). Análisis de contenedores utilizando Trivy. Recuperado de https://iberasync.es/analisis-de-contenedores-utilizando-Trivy/
- Red Hat Security Advisory CVE-2022-1471: Para citar la página de Red Hat sobre la vulnerabilidad CVE-2022-1471, puedes usar: Red Hat. (2024). Security Advisory CVE-2022-1471. Recuperado de https://access.redhat.com/security/cve/CVE-2022-1471
- SnakeYAML 2.0 en MVNRepository: Para citar la página de MVNRepository sobre la versión 2.0 de SnakeYAML, puedes seguir este formato: MVNRepository. (2023). SnakeYAML 2.0. Recuperado de https://mvnrepository.com/artifact/org.yaml/snakeyaml/2.0
- Bluetab. (2021). Análisis de vulnerabilidades en contenedores con Trivy. Recuperado de https://www.bluetab.net/es/analisis-de-vulnerabilidades-en-contenedores-con-trivy/
- Aqua Security. (2024). Trivy vulnerability database. Recuperado de https://aquasecurity.github.io/trivy/v0.40/docs/vulnerability/db/