Cómo LiveRamp usó Snyk para corregir Log4Shell

Como cualquier empresa que usa aplicaciones web o software empresarial desarrollado con Java, LiveRamp, con sede en San Francisco, temía que la vulnerabilidad de día cero Log4Shell, presente en Log4j —la popular biblioteca de registro de código abierto—, hubiera afectado sus sistemas.

Cuando Log4Shell apareció a mediados de diciembre de 2021, LiveRamp —una empresa de conectividad de datos que integra datos de clientes de distintas fuentes en las plataformas de marketing de las empresas— acababa de completar su prueba de concepto (POC) con Snyk y estaba en las primeras etapas de implementación de Snyk Open Source y Snyk Container.

La principal motivación de LiveRamp para implementar Snyk era proteger su pipeline de CI/CD con análisis automatizados de vulnerabilidades. Los equipos de desarrollo y seguridad de LiveRamp no esperaban que Snyk detectara y ayudara a corregir una importante vulnerabilidad de día cero.

“Nos preguntamos: ‘¿Queremos usar Snyk para esto?’”, explicó John Jelinek, ingeniero sénior de DevOps en LiveRamp. “Google había publicado sus propias herramientas para buscar vulnerabilidades como Log4Shell, pero estábamos integrando Snyk y la herramienta estaba diseñada para estas situaciones, así que decidimos usarla para localizar instancias de la biblioteca Log4j”.

Cómo localizar instancias de Log4j con Snyk

Cuando LiveRamp empezó a buscar Log4j con Snyk, Jelinek y su equipo no tenían claro cuántos repositorios debían analizar ni quién era responsable de cada uno. Usaban 1,600 repositorios de GitHub. Jelinek utilizó la herramienta de importación de la API de Snyk para reducir la lista a 400 proyectos de Java, los más vulnerables a Log4Shell, que debían importarse a Snyk y analizarse. Pudo importar todos los proyectos de Java a Snyk en dos horas.

Jelinek organizó un grupo interno para coordinar las tareas de mitigación de Log4Shell y empezó a recibir informes de Snyk que señalaban las instancias de Log4j en los proyectos de Java de LiveRamp. Luego recopiló los informes de Snyk y se los entregó al equipo de seguridad, que trabajó para corregir la vulnerabilidad en todas las instancias afectadas de Log4j.

Jelinek y su equipo descubrieron que el 23 % de los 400 proyectos de Java contenía la vulnerabilidad Log4Shell y debía corregirse.

Análisis de contenedores para detectar Log4j

El siguiente paso fue usar Snyk para analizar en busca de Log4j los contenedores de LiveRamp en GCR. El proceso resultó complicado porque cada contenedor tenía entre 500 y 2,000 proyectos, además de binarios de Java y varias versiones. “La cantidad de imágenes de contenedor con Log4j parecía mayor de lo que era”, dijo Jelinek. “Muchas de esas imágenes debían archivarse porque ya no forman parte de nuestro ecosistema”.

Aunque este proceso requirió mucho trabajo, también fue valioso porque ayudó a LiveRamp a entender qué contenedores debían tener prioridad y cuáles debían eliminarse o archivarse.

El esfuerzo para corregir Log4Shell

LiveRamp estableció un orden de prioridad para las correcciones. Primero corrigió las aplicaciones expuestas a los clientes y, después, las aplicaciones que usaban los empleados y a las que solo se podía acceder internamente.

Con Snyk, LiveRamp pudo corregir todas las instancias de Log4Shell en sus aplicaciones externas e internas antes de que terminara el año (Log4Shell se hizo pública el 10 de diciembre). “Corregir las aplicaciones de cara al cliente tomó una semana”, dijo Jelinek, “y las aplicaciones internas, quizá dos semanas. La corrección de todas las versiones vulnerables de Log4j (hasta la 2.17) se extendió hasta finales de enero”.

Lecciones para la próxima vulnerabilidad

El uso de Snyk para analizar y corregir Log4Shell puso de relieve la necesidad de LiveRamp de contar con una lista de materiales de software (SBOM). Según Jelinek, uno de los desafíos que enfrentó LiveRamp cuando apareció Log4Shell fue identificar las bibliotecas y dependencias que usaba cada microservicio. La falta de visibilidad sobre cómo se conectaban las URL, los microservicios y los repositorios de LiveRamp dificultó localizar la biblioteca Log4j en su infraestructura e identificar qué servicios eran vulnerables.

“La vulnerabilidad Log4Shell convirtió en una tarea pendiente entender la huella de nuestro software”, dijo Jelinek. “Ahora estamos trabajando para tener un mejor control de ella”. Tras superar los desafíos de Log4Shell, LiveRamp sigue usando Snyk para obtener mayor visibilidad del estado de seguridad de sus dependencias de código abierto y contenedores.