Como a LiveRamp usou a Snyk para corrigir a Log4Shell

Como qualquer empresa que usa aplicativos web ou software corporativo criado com Java, a LiveRamp, com sede em San Francisco, estava preocupada com a possibilidade de ter sido afetada pela vulnerabilidade de dia zero Log4Shell no Log4j, a popular biblioteca de logging de código aberto.

Quando a Log4Shell surgiu em meados de dezembro de 2021, a LiveRamp — uma empresa de conectividade de dados que integra dados de clientes de diferentes fontes às próprias plataformas de marketing das empresas — tinha acabado de concluir seu teste de PoC (prova de conceito) com a Snyk e estava nos estágios iniciais da implementação de Snyk Open Source e Snyk Container.

A principal motivação da LiveRamp para implementar a Snyk era proteger seu pipeline de CI/CD com a análise automatizada de vulnerabilidades. As equipes de desenvolvimento e segurança da LiveRamp não esperavam que a Snyk detectasse e ajudasse a corrigir uma grande vulnerabilidade de dia zero.

“Nós nos perguntamos: ‘Queremos usar a Snyk para isso?’”, explicou John Jelinek, engenheiro de DevOps sênior da LiveRamp. “O Google tinha lançado ferramentas próprias para analisar ameaças como a Log4Shell, mas estávamos fazendo a integração da Snyk e a ferramenta foi desenvolvida para situações como essa. Por isso, decidimos usar a ferramenta da Snyk para localizar ocorrências da biblioteca Log4j.”

Como localizar ocorrências do Log4j com a Snyk

Quando a LiveRamp começou a analisar o Log4j com a Snyk, Jelinek e sua equipe não sabiam quantos repositórios precisavam analisar nem quem era responsável por cada um. Eles usavam 1.600 repositórios do GitHub. Jelinek usou a ferramenta de importação da API da Snyk para filtrar esses repositórios e selecionar 400 projetos Java mais vulneráveis à Log4Shell, que precisavam ser importados para a Snyk e analisados. Ele conseguiu importar todos os projetos Java para a Snyk em duas horas.

Jelinek criou uma força-tarefa interna para mitigar a Log4Shell e começou a receber relatórios da Snyk que sinalizavam ocorrências do Log4j nos projetos Java da LiveRamp. Em seguida, reuniu os relatórios da Snyk e os encaminhou à equipe de segurança, que trabalhou para corrigir a vulnerabilidade em todas as ocorrências afetadas do Log4j.

Jelinek e sua equipe descobriram que 23% dos 400 projetos Java continham a vulnerabilidade Log4Shell e precisavam de correção.

Como analisar contêineres em busca do Log4j

A próxima etapa foi usar a Snyk para analisar os contêineres da LiveRamp no GCR em busca do Log4j. O processo acabou sendo trabalhoso, pois cada contêiner tinha entre 500 e 2.000 projetos, além de binários Java e várias versões. “O número de imagens de contêiner com Log4j estava inflado”, disse Jelinek. “Muitas dessas imagens precisavam ser arquivadas porque já não faziam parte do nosso ecossistema.”

Embora esse trabalho exigisse bastante esforço, também foi valioso, pois ajudou a LiveRamp a entender quais contêineres deveriam ser priorizados e quais deveriam ser excluídos ou arquivados.

O esforço para corrigir a Log4Shell

A LiveRamp definiu uma ordem de prioridade para as correções. Primeiro, foram corrigidos os aplicativos voltados aos clientes; depois, os usados pelos funcionários e acessíveis apenas internamente.

Com a Snyk, a LiveRamp conseguiu corrigir todas as ocorrências da Log4Shell em seus aplicativos externos e internos antes do fim do ano (a Log4Shell foi divulgada em 10 de dezembro). “Levamos uma semana para corrigir os aplicativos voltados aos clientes”, disse Jelinek, “e talvez duas semanas para os aplicativos internos. A correção de todas as versões vulneráveis do Log4j (até a 2.17) só foi concluída no fim de janeiro.”

Lições para a próxima vulnerabilidade

O uso da Snyk para analisar e corrigir a Log4Shell destacou a necessidade de a LiveRamp ter uma lista de materiais de software (SBOM). Segundo Jelinek, um dos desafios enfrentados pela LiveRamp quando a Log4Shell surgiu foi identificar as bibliotecas e dependências usadas por cada microsserviço. A falta de visibilidade sobre as conexões entre URLs, microsserviços e repositórios da LiveRamp dificultava localizar a biblioteca Log4j na infraestrutura e identificar quais serviços estavam vulneráveis.

“A vulnerabilidade Log4Shell colocou a compreensão do nosso inventário de software na lista de tarefas”, disse Jelinek. “Agora, estamos trabalhando continuamente para entendê-lo melhor.” Depois de superar os desafios da Log4Shell, a LiveRamp continua contando com a Snyk para ampliar a visibilidade da postura de segurança de suas dependências de código aberto e de seus contêineres.