Lecciones de las vulnerabilidades de OpenSSL, parte 2: cómo encontrar y corregir vulnerabilidades en la cadena de suministro

Esta serie sobre la cadena de suministro se centra en las lecciones aprendidas de OpenSSL y en lo que debes tener en cuenta para reforzar la seguridad de tu cadena de suministro. Aunque esta serie se enfocará en OpenSSL y las bibliotecas relacionadas, también consideraremos vulnerabilidades en general. En la primera entrega, cubrimos todo lo que necesitas saber sobre dónde buscar bibliotecas vulnerables. Veamos la segunda parte y cómo encontrar —y, más importante aún, corregir— las vulnerabilidades en tu cadena de suministro.

Cómo encontrar vulnerabilidades en tu cadena de suministro

Los métodos que usas para buscar bibliotecas o paquetes problemáticos dependen de las áreas que estés inspeccionando. Los hosts y las máquinas virtuales usan mecanismos distintos de los contenedores y el código. Hoy nos enfocaremos en el software: los contenedores y el código.

Tener una vista centralizada de todo tu ecosistema puede ayudar a responder la pregunta «¿dónde nos afecta?». Esta vista centralizada te daría visibilidad de todo tu portafolio de aplicaciones. Debería incluir todas tus aplicaciones y los componentes que las conforman: el código, los contenedores donde las implementas y todas sus dependencias de código abierto. Esta «vista centralizada» almacenaría de manera efectiva una lista de materiales de software (SBOM) para cada uno de tus componentes de software, y proporcionaría un índice de todas las aplicaciones y los contenedores que ejecutas o almacenas. 

Código fuente y bibliotecas de código abierto

Una vista centralizada es excelente, pero, como dicen, después de la tormenta todos son capitanes. Es muy posible que el anuncio de OpenSSL haya llegado antes de que pudieras configurar un inventario (o incluso antes de que supieras que centralizarlo era una opción). Veamos qué debes tener en cuenta y dónde buscar si aún no lo tienes centralizado. Las aplicaciones modernas aprovechan componentes y bibliotecas de código abierto: el 80 % o más del código de tus aplicaciones podría estar fuera de tu control directo. Por eso, determinar dónde se usan estas bibliotecas y paquetes es una parte importante del problema.

Encontrar las bibliotecas que importan tus aplicaciones y proyectos personalizados es más complicado que buscarlas en hosts físicos. Puedes hacer un análisis de fuerza bruta para buscar «openssl» en todas las apariciones de requirements.txt en los directorios raíz de tus proyectos, pero probablemente no encontrarás mucho. No solo es poco probable que un mismo host tenga todo el código fuente de todos tus proyectos, sino que también es muy posible (o incluso probable) que, si tus aplicaciones dependen de OpenSSL, lo hagan a través de las propiedades transitivas que mencionamos antes. 

Lo ideal es que tengas una lista de materiales de software (SBOM) para cada una de tus aplicaciones, lo que te permitiría determinar rápidamente el riesgo, pero todavía no están muy extendidas. Hay varias herramientas que permiten generar una SBOM para tus aplicaciones. Por ejemplo, Snyk ofrece una API y un comando de CLI, snyk sbom, que genera una lista de materiales de software en formato SPDX o CycloneDX. Sin embargo, revisar manualmente cada uno de tus repositorios de código fuente no es práctico. En lugar de analizar el código fuente en tu computadora local, muchas soluciones permiten analizarlo donde se encuentra: en los repositorios. Por ejemplo, Snyk te permite agregar los repositorios que quieres monitorear con solo vincular tus cuentas y seleccionar los repositorios que quieres agregar.

Cuando los repositorios se vinculan de esta manera, se pueden analizar con regularidad. Esto ayuda a encontrar vulnerabilidades recién descubiertas que ya estaban presentes en las dependencias de tus proyectos (por ejemplo, las vulnerabilidades de OpenSSL, que ayer desconocíamos), además de las que puedan haber agregado los desarrolladores. 

Imágenes de contenedor

Las imágenes de contenedor también forman parte de tu cadena de suministro de software. No solo funcionan como motores para tus cargas de trabajo, sino que también incluyen elementos que van más allá de tu código y sus dependencias. Hay varias herramientas para analizar la composición, los paquetes y las vulnerabilidades de las imágenes de contenedor, entre ellas Snyk Container, que ofrece planes gratuitos y de pago, integraciones con IDE y una interfaz de línea de comandos, además de admitir la automatización en tus pipelines de CI/CD. También hay varios proyectos de código abierto —como Syft, Grype, trivy y la herramienta no oficial «docker index»— que pueden buscar vulnerabilidades. La herramienta docker-index se puede usar desde la línea de comandos para encontrar CVE. Aunque actualmente la herramienta no está firmada, puedes ejecutarla en un contenedor (muy meta). Este es un ejemplo de una imagen pública, apache/tika:2.6.0.1, que, al momento de escribir esto, todavía tiene una versión vulnerable de OpenSSL. Expandí los argumentos para que sean más fáciles de leer; siéntete libre de abreviar -it.

1docker run \
2    --interactive \
3    --tty \
4    --rm \
5    ghcr.io/docker/docker-index:main \
6    cve -i \
7    apache/tika:2.6.0.1 CVE-0000

El comando docker-index identifica las vulnerabilidades 3602 y 3768 de OpenSSL, pero no detecta nada más:

1INFO Requesting image apache/tika:2.6.0.1
2INFO Copied image
3INFO Indexed 333 packages
4INFO Detected 2 vulnerabilities
5
6Detected CVE-2022-3602  HIGH
7https://dso.docker.com/cve/CVE-2022-3602
8
9pkg:deb/ubuntu/openssl@3.0.2-0ubuntu1.6?os_distro=jammy&os_name=ubuntu&os_version=22.04
10ADD file:ba96f963bbfd429a0839c40603fdd7829eaca58f20adfa0d15e6beae8244bc08 in /
110: sha256:301a8b74f71f85f3a31e9c7e7fedd5b001ead5bcf895bc2911c1d260e06bd987
12
13Detected CVE-2022-3786  HIGH
14https://dso.docker.com/cve/CVE-2022-3786
15
16pkg:deb/ubuntu/openssl@3.0.2-0ubuntu1.6?os_distro=jammy&os_name=ubuntu&os_version=22.04
17ADD file:ba96f963bbfd429a0839c40603fdd7829eaca58f20adfa0d15e6beae8244bc08 in /
180: sha256:301a8b74f71f85f3a31e9c7e7fedd5b001ead5bcf895bc2911c1d260e06bd987

La mayoría de los analizadores de contenedores y componentes de código abierto muestran una lista de vulnerabilidades; algunos también indican una versión con la que se corrigen. Un ejemplo es el resultado de Trivy, que identifica una larga lista de vulnerabilidades que docker-index no detecta (a continuación, un subconjunto):

Identificó las dos nuevas vulnerabilidades de OpenSSL de gravedad HIGH, junto con una descripción general y una versión con la que se corrigen, pero no ayuda realmente a crear un contenedor más seguro:

┌────────────────┬────────────────┬──────────┬───────────────────┬────────────────────┐
│ libssl3        │ CVE-2022-3602  │ HIGH     │ 3.0.2-0ubuntu1.6  │ 3.0.2-0ubuntu1.7   │
│                │                │          │                   │                    │
│                ├────────────────┤          │                   │                    │
│                │ CVE-2022-3786  │          │                   │                    │
│                │                │          │                   │                    │
└────────────────┴────────────────┴──────────┴───────────────────┴────────────────────┘

Al igual que con el código abierto en nuestra primera publicación, es posible analizar una o dos imágenes de contenedor, pero analizar cientos o miles es poco realista en un flujo de trabajo de desarrollo típico.

Al igual que ocurre con las dependencias transitivas y el código abierto, probablemente no estés ejecutando imágenes como Ubuntu o tika directamente, sino que usas imágenes derivadas de ellas. Esto significa que heredas cualquiera de sus vulnerabilidades, además de las que hayas agregado mediante instrucciones de usuario, lo que añade una capa de complejidad a la búsqueda.

Dónde nos afecta

Como hemos visto, hay varias herramientas que pueden ayudar a encontrar bibliotecas vulnerables en nuestras imágenes de contenedor y dependencias de código abierto. Las herramientas que realizan análisis puntuales en tu entorno de desarrollo local pueden funcionar en proyectos con pocos desarrolladores, pero se vuelven difíciles de manejar a medida que crecen el equipo y la cantidad de proyectos. Por otro lado, las herramientas que se integran con la fuente de referencia de tu portafolio de aplicaciones —los repositorios de código fuente y los registros de imágenes de contenedor— pueden llevar un registro de tu inventario y ofrecer información actualizada sobre posibles impactos. Por ejemplo, al filtrar por otra vulnerabilidad de alto perfil, Snyk Reporting muestra una vista centralizada de nuestros proyectos afectados por Log4Shell. Tanto si usamos el método de fuerza bruta como si contamos con una vista centralizada y ordenada, al menos podemos responder la pregunta «¿dónde nos afecta?».

No se trata solo de «encontrar» las apariciones

Hemos visto que más del 80 % del código de tu cadena de suministro de software podría provenir de fuentes externas, pero encontrar las apariciones es solo una parte de la pregunta que hará tu jefe. Ahora que sabemos dónde somos vulnerables y tenemos una lista de cosas que corregir, todavía queda responder la segunda parte de la pregunta: «¿cómo vamos a corregirlo?». En el caso de los sistemas operativos o las aplicaciones, «corregir» suele significar esperar los parches o las actualizaciones de un proveedor y aplicarlos. 

Con las vulnerabilidades de bibliotecas de código abierto y contenedores, probablemente también tendrás que esperar las actualizaciones de los responsables del proyecto, pero con pasos adicionales. Es probable que los responsables también estén esperando una corrección de alguien más en la cadena de dependencias. Tomemos como ejemplo Ubuntu 22.04, la versión de soporte a largo plazo (LTS) de la popular distribución de Linux. Cuando se divulgaron las vulnerabilidades de OpenSSL, Ubuntu 22.04 incluía OpenSSL 3.0.2 (en particular, 3.0.2-0ubuntu1.6), una de las versiones vulnerables. En el caso de Ubuntu, en lugar de pasar a la versión 3.0.7, se aplicaron parches a la versión 3.0.2 para corregir las vulnerabilidades. Pero eso no fue todo. Una vez que se aplicaron los parches a la biblioteca, todavía tenían que publicar la actualización para Ubuntu 22.04 y crear imágenes de contenedor actualizadas. 

Si consumes directamente imágenes de Ubuntu (por ejemplo, si tu Dockerfile empieza con FROM ubuntu:22.04), podrías volver a crear tus imágenes para incorporar la corrección una vez que se publicaran las imágenes afectadas (y, con suerte, pruebas tus imágenes, ya que hasta los cambios más pequeños deben verificarse). Sin embargo, si eres un consumidor posterior que depende de imágenes derivadas de esa nueva versión de Jammy Jellyfish, quizá tengas que esperar un par de iteraciones más para que las correcciones se propaguen antes de que se actualice la imagen que esperas.

A diferencia de las opciones de análisis de contenedores de código abierto de la sección anterior, Snyk Container te ayuda a explorar los árboles de dependencias de las imágenes para encontrar mejores imágenes base y crear imágenes más seguras. Snyk mantiene y actualiza con regularidad un índice de versiones de imágenes oficiales populares en Docker Hub, lo que te permite determinar cuándo están desactualizadas las imágenes que usan etiquetas móviles (imágenes que se actualizan en el mismo lugar, en vez de aumentar una versión menor). En este caso, Snyk Container detecta que ubuntu:22.04 se actualizó desde que se creó la imagen analizada e indica que debes volver a crearla para incorporar el cambio:

1Your base image is out of date
21) Pull the latest version of your base image by running 'docker pull ubuntu:22.04'
32) Rebuild your local image

Snyk Container también puede ofrecerte una lista de mejores opciones de imágenes, tanto si usas imágenes oficiales de Docker como si especificas tus propias imágenes base personalizadas. Además, permite generar pull request con un solo clic para que puedas actualizar rápidamente y corregir varias vulnerabilidades a la vez.

Corregir vulnerabilidades en dependencias de código abierto también es sencillo con Snyk. Además de los detalles sobre las bibliotecas vulnerables, también ofrece información sobre las versiones corregidas, como se muestra a continuación:

Snyk también ofrece herramientas para corregirlas mediante «Fix PRs», que te permiten abordar varias vulnerabilidades con un solo clic.

Si el método de corregirlas una por una no funciona a tu escala, la mejor respuesta a la pregunta «¿cómo vamos a corregirlo?» es sencilla: «Lo corregiremos con Snyk».

Prepárate para la próxima vulnerabilidad en la cadena de suministro con Snyk

Aprovecha la reducción de gravedad de las vulnerabilidades de OpenSSL para probar tus procesos de gestión de vulnerabilidades. Crea guías y listas de verificación sobre cómo abordar la próxima vulnerabilidad, incluidos quiénes deben participar, cómo evaluar el impacto, qué inventario se debe analizar y cómo comunicarás los hallazgos y el impacto internamente (y externamente, si corresponde). Quizá lo más importante sea asegurarte de que todos sepan dónde encontrar las guías. Antes de que aparezca la próxima vulnerabilidad crítica, empieza a incorporar herramientas para hacer un seguimiento de tu código fuente y el inventario de contenedores, así estarás mejor preparado.

Al usar Snyk Container y Snyk Open Source para proteger tu cadena de suministro de software, puedes monitorear de forma proactiva tus contenedores y proyectos de código abierto. En lugar de tener que buscar a toda prisa imágenes de contenedor o paquetes de código abierto vulnerables, puedes saber si estás afectado antes de que se publiquen las vulnerabilidades. Así tendrás la tranquilidad de contar con las respuestas cuando hagas clic en «enviar» en Slack y le mandes ese mensaje a tu jefe.

Obtén más información sobre las herramientas de seguridad de la cadena de suministro de software y sobre cómo Snyk puede ayudarte a reforzar la seguridad de tu cadena de suministro de software, y comienza gratis hoy mismo.