Comment LiveRamp a utilisé Snyk pour corriger la vulnérabilité Log4Shell

Comme toute entreprise qui utilise des applications web ou des logiciels d’entreprise développés en Java, LiveRamp, basée à San Francisco, craignait d’avoir été touchée par la vulnérabilité zero-day Log4Shell dans Log4j, la célèbre bibliothèque de journalisation open source.

Lorsque Log4Shell a été découverte à la mi-décembre 2021, LiveRamp — une entreprise spécialisée dans la connectivité des données qui intègre des données clients disparates aux plateformes marketing d’une entreprise — venait de terminer son essai de validation de concept (POC) avec Snyk et commençait tout juste à déployer Snyk Open Source et Snyk Container.

LiveRamp souhaitait avant tout déployer Snyk pour sécuriser son pipeline CI/CD grâce à l’analyse automatisée des vulnérabilités. Les équipes de développement et de sécurité de LiveRamp ne s’attendaient pas à ce que Snyk détecte une importante vulnérabilité zero-day et les aide à la corriger.

« Nous nous sommes demandé : “Voulons-nous utiliser Snyk pour cela ?” », explique John Jelinek, ingénieur DevOps senior chez LiveRamp. « Google avait publié ses propres outils pour rechercher des vulnérabilités comme Log4Shell, mais nous étions en train d’intégrer Snyk et l’outil avait été conçu pour ce type de situation. Nous avons donc décidé de l’utiliser pour localiser les instances de la bibliothèque Log4j. »

Localiser les instances de Log4j avec Snyk

Lorsque LiveRamp a commencé à rechercher Log4j avec Snyk, Jelinek et son équipe ne savaient pas combien de dépôts analyser ni qui était responsable de chacun d’eux. L’entreprise utilisait 1 600 dépôts GitHub. Jelinek s’est servi de l’outil d’importation de l’API Snyk pour filtrer les dépôts GitHub et ne retenir que 400 projets Java particulièrement exposés à Log4Shell, à importer dans Snyk pour les analyser. Il a pu importer tous les projets Java dans Snyk en deux heures.

Jelinek a mis en place une équipe interne chargée de limiter les risques liés à Log4Shell, puis a commencé à recevoir des rapports Snyk signalant la présence d’instances de Log4j dans les projets Java de LiveRamp. Il a ensuite transmis ces rapports à l’équipe de sécurité, qui s’est chargée de corriger la vulnérabilité dans chaque instance concernée de Log4j.

Jelinek et son équipe ont découvert que 23 % des 400 projets Java étaient touchés par la vulnérabilité Log4Shell et devaient être corrigés.

Analyser les conteneurs à la recherche de Log4j

L’étape suivante consistait à utiliser Snyk pour analyser les conteneurs de LiveRamp dans GCR à la recherche de Log4j. La tâche s’est révélée fastidieuse, car chaque conteneur comptait entre 500 et 2 000 projets et contenait des binaires Java ainsi que plusieurs versions. « Le nombre d’images de conteneur contenant Log4j était gonflé, explique Jelinek. Beaucoup de ces images devaient être archivées, car elles ne faisaient plus partie de notre écosystème. »

Cet exercice a demandé beaucoup de travail, mais il a aussi été utile : il a permis à LiveRamp de déterminer quels conteneurs prioriser et lesquels supprimer ou archiver.

La correction de Log4Shell

LiveRamp a défini un ordre de priorité pour les corrections. Les applications accessibles aux clients depuis l’extérieur ont été corrigées en premier, suivies des applications utilisées par les employés et accessibles uniquement en interne.

Avec Snyk, LiveRamp a pu éliminer toutes les instances de Log4Shell de ses applications externes et internes avant la fin de l’année (Log4Shell a été révélée le 10 décembre). « Il a fallu une semaine pour corriger les applications destinées aux clients, explique Jelinek, et peut-être deux semaines pour les applications internes. La correction de toutes les versions vulnérables de Log4j (jusqu’à la version 2.17) a pris jusqu’à la fin du mois de janvier. »

Les enseignements à tirer pour la prochaine vulnérabilité

L’utilisation de Snyk pour détecter et corriger Log4Shell a mis en évidence la nécessité, pour LiveRamp, de disposer d’une nomenclature logicielle (SBOM). Selon Jelinek, l’un des défis rencontrés par LiveRamp lors de l’apparition de Log4Shell consistait à savoir quelles bibliothèques et dépendances étaient utilisées par chaque microservice. Le manque de visibilité sur les liens entre les URL, les microservices et les dépôts de LiveRamp compliquait la localisation de la bibliothèque Log4j dans son infrastructure et l’identification des services vulnérables.

« La vulnérabilité Log4Shell a fait de la compréhension de notre empreinte logicielle une priorité », explique Jelinek. « Nous travaillons actuellement à mieux la maîtriser. » Depuis que LiveRamp a surmonté les difficultés liées à Log4Shell, Snyk continue d’améliorer la visibilité sur la posture de sécurité de ses dépendances open source et de ses conteneurs.