Container Analysis: Administra las dependencias de una manera fácil y segura
La seguridad de las aplicaciones es solo un aspecto del desarrollo de software y, por lo tanto, una de las muchas demandas que compiten por el tiempo y la atención de los desarrolladores. Los enfoques de seguridad de alta fricción pueden ser frustrantes para los desarrolladores e ineficiente en general, ya que las personas intentan evitar los puntos de fricción, Por ejemplo, en The State of DevOps Report 2022 (DORA), un conjunto de entrevistas con profesionales en ingeniería de software descubrió que sus puntos de contacto con los equipos de seguridad se limitaban al inicio o al final de un proyecto, y que podía ser difícil interactuar con esos equipos.
Como podemos ver en la imagen, las vulnerabilidades pueden estar presentes en cualquier etapa de un pipeline de CI/CD, en este post quiero enfocarme en un punto en específico: el manejo de las dependencias.
En noviembre de 2020, relativamente pocos profesionales de la tecnología sospechaban que se estaba gestando una crisis de seguridad en la cadena de suministro de software. La Open Source Security Foundation, sucesora de esfuerzos anteriores, se fundó para centrarse en la seguridad del software de código abierto y, aunque hubo algunos puntos positivos para abordar este problema, el tema no estaba en la portada de los principales periódicos. Un gran ataque, SolarWinds, cambió todo eso. Cuando los atacantes pueden penetrar silenciosamente en miles de empresas importantes y redes gubernamentales gracias a las actualizaciones de software con troyanos, los tiempos cambian rápidamente.
Manejando las dependencias
Dentro de la documentación de Google Cloud tenemos varias recomendaciones de cómo Administrar las Dependencias, una de ellas es el versionamiento de las dependencias. Como una buena práctica para la reproducibilidad de nuestra aplicación, restringimos la versión de una dependencia a una versión específica. Sin embargo, esto también implica congelarse en el tiempo, es decir, no recibir nuevas actualizaciones de la dependencia, como correcciones de seguridad, errores y mejoras.
Responder con rapidez a las vulnerabilidades en tus dependencias te ayuda a proteger tu cadena de suministro de software, pero ¿Cómo podemos saber si se ha identificado una vulnerabilidad en una dependencia?. Lo más probable es que no estemos monitoreando activamente las bases de datos de vulnerabilidades de third-party software.
Container Analysis puede proporcionar una amplia gama de análisis de vulnerabilidades para imágenes de containers, esto permite identificar las vulnerabilidades de forma temprana.
Un repositorio para almacenar nuestras imágenes de containers
Artifact Registry permite a nuestros equipos administrar las imágenes de containers en un solo lugar, está integrado a las herramientas de Google Cloud. Esto facilita la integración a las herramientas de CI/CD a la hora de configurar un pipeline automatizado, como por ejemplo, el análisis de vulnerabilidades con Container Analysis.
¿Cómo analizar las dependencias en las imágenes de containers?
Como primer paso vamos a crear un nuevo repositorio para imágenes de containers en Artifact Registry. Buscamos la sección de Artifact Registry dentro de la consola de Google Cloud y damos clic en Crear Repositorio.
Completamos los campos como se muestra en la imagen:
Presionamos CREAR y listo, tenemos un repositorio para nuestras imágenes de containers. Es importante tener en cuenta que la dirección completa del repositorio es southamerica-east1-docker.pkg.dev/[YOUR-PROJECT-ID]/microservice-repository, ya que es posible crear varios repositorios en la misma región o multi región, además que el nombre del repositorio debe ser único en la región donde fue creado.
Para activar el análisis de vulnerabilidades vamos a utilizar Cloud Shell donde podremos ejecutar los comandos necesarios:
gcloud services enable containerscanning.googleapis.comPara esta demostración vamos a utilizar el microservicio AdService del repositorio de Online Boutique en Github.
Clonamos el repositorio de Online Boutique y vamos a la ubicación del servicio adservice:
git clone https://github.com/GoogleCloudPlatform/microservices-demo.git
cd microservices-demo/src/adservice/ Para hacer build de nuestra imagen de container en la nube usando Cloud Build y posteriormente almacenarlo en el repositorio que acabamos de crear en Artifact Registry, ejecutamos los siguientes comandos en Cloud Shell.
gcloud builds submit --tag southamerica-east1-docker.pkg.dev/[YOUR-PROJECT-ID]/microservice-repository/adservice:v0.1
# Respuesta esperada
DONE
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ID CREATE_TIME DURATION SOURCE IMAGES STATUS
fac8f861-ed51-435b-bd6c-468edf6be0f2 2022-12-20T20:42:36+00:00 2M2S gs://[YOUR-RPOJECT-ID]_cloudbuild/source/1671568954.292143-0b4e6e60d6062dc9412483d013f89a7.tgz southamerica-east1-docker.pkg.dev/[YOUR-RPJECT-ID]/microservice-repository/adservice:v0.1 SUCCESSVemos que el flag
--tages bastante largo y esto se debe a que el tag (o nombre) de la imagen de container debe tener la dirección del repositorio donde va a ser almacenado.
La imagen fue almacenada correctamente y ya podemos observar que hay una vulnerabilidad detectada.
Aquí podemos ver el resultado del análisis, lo que podemos resaltar es que la gravedad de la vulnerabilidad es baja y que existe una corrección para esta vulnerabilidad.
Al dar click en VER CORRECIÓN vemos mayor información sobre la vulnerabilidad y cómo fue corregido, en defensa del repositorio, esta vulnerabilidad fue publicada una semana antes de redactar este post.
Vamos a hacer la demostración un poco más interesante, hace no mucho tiempo surgió Log4 Shell, esta vulnerabilidad permitía que un atacante que controla los mensajes de log o los parámetros de los mensajes de log ejecutar código arbitrario, la idea es regresar a un commit antes que la vulnerabilidad sea publicada y ver cual es el resultado de Container Analysis.
Para ir al commit previo a Log4Shell, ejecutamos:
git checkout -b log4j 884439c7437cab8d66da4657d8043278e01c33dcCon git log podemos ver que la información del commit:
commit 884439c7437cab8d66da4657d8043278e01c33dc (HEAD -> log4j)
Author: Mathieu Benoit <mathieu-benoit@hotmail.fr>
Date: Wed Nov 3 12:23:56 2021 -0400
Update dotnet packages for `cartservice` (#613)
* dotnet/sdk:5.0.402 and dotnet/runtime-deps:5.0.11-alpine3.14-amd64
* Grpc.AspNetCore 2.40.0
* add the e-2-m tutorial as a demo featuring the onlineboutique repo
* GRPC_HEALTH_PROBE_VERSION=v0.4.5
* GRPC_HEALTH_PROBE_VERSION=v0.4.6Realizamos el buildnuevamente y esperamos o resultado do Container Analysis
gcloud builds submit --tag southamerica-east1-docker.pkg.dev/[YOUR-PROJECT-ID]/microservice-repository/adservice:v0.0
Y como era de esperar, el número de vulnerabilidades detectadas es mayor
En la lista de vulnerabilidades vamos a encontrar Log4J con una gravedad crítica.
En VER CORRECCIÓN, aparece más información sobre la vulnerabilidad.
Conclusión
Existen numerosas iniciativas, y gran parte de la industria del software se ha comprometido a reformar sus propias prácticas de seguridad de la cadena de suministro de software y mejorar la seguridad en las dependencias de código abierto. Con Artifact Registry y Container Analysis podemos monitorear activamente las dependencias de una forma automatizada.
¡Los invito a comenzar a analizar sus dependencias! Si encuentran vulnerabilidades críticas, por favor, no busquen culpables, por el contrario tomenlo como una oportunidad de anticiparse a un problema y así mejorar la experiencia de desarrollo.
