Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
A correção foi lançada. O ticket foi encerrado. O relatório pós-incidente foi arquivado. E, ainda assim, mais de quatro anos depois, os scanners continuam sinalizando o problema. Trata-se da diferença entre “corrigido” e comprovadamente seguro — e do que o Log4j realmente revelou sobre os sistemas subjacentes.
Existe um tipo específico de exaustão que se segue a um grande incidente de segurança. A corrida para aplicar os patches, as reuniões com toda a equipe, o inventário frenético dos sistemas afetados e, então, finalmente, o momento em que alguém fecha o ticket de rastreamento e escreve “resolvido” no campo de status. Essa sensação de conclusão é real. É também, em muitos casos, um pouco prematura.
O Log4Shell — a vulnerabilidade crítica de execução remota de código divulgada em dezembro de 2021 na biblioteca Apache Log4j — continua sendo o exemplo mais marcante da história recente do que acontece quando um componente profundamente integrado ao ecossistema Java se revela onipresente e universalmente perigoso. A reação foi enorme. Milhares de organizações aplicaram correções em poucos dias. Órgãos governamentais emitiram diretrizes de emergência. Equipes de segurança trabalharam durante os fins de semana.
No entanto, a falha de segurança do Java exposta pelo Log4j ainda não foi resolvida. Não se trata do CVE específico, mas das condições que a tornaram possível e da incerteza residual que persiste mesmo após a aplicação dos patches. Compreender essa incerteza é a verdadeira lição, e ela se aplica muito além de qualquer biblioteca específica.
O que “corrigido” realmente significa
Quando uma organização anuncia que aplicou o patch no Log4j, essa declaração traz uma suposição implícita: que todas as instâncias da biblioteca vulnerável foram identificadas e atualizadas. Na prática, essa suposição é extremamente difícil de verificar em ambientes Java complexos.
As aplicações Java são distribuídas como artefatos empacotados – arquivos JAR, arquivos WAR, fat JARs criados com ferramentas como o Maven Shade ou o empacotamento embutido do Spring Boot. Esses pacotes agrupam suas dependências no momento da compilação. Uma versão vulnerável do Log4j não aparece simplesmente no seu manifesto de dependências; ela pode estar fisicamente incorporada dentro de outro JAR, que por sua vez está dentro de um WAR, o qual é implantado em um servidor de aplicações que sua equipe de segurança nem sequer percebeu que estava executando Java.
Para saber como identificar e resolver sistematicamente essas dependências profundamente enraizadas, consulte nosso guia completo sobre como aplicar uma correção para a vulnerabilidade do Log4j.
Este não é um caso isolado. Durante a resposta ao Log4Shell, pesquisadores de segurança descobriram instâncias vulneráveis do Log4j aninhadas em quatro e cinco camadas de profundidade dentro de softwares corporativos de fornecedores que, por sua vez, nem sequer haviam percebido a presença da biblioteca. As orientações da CISA na época enfatizavam a identificação de todos os ativos afetados e alertavam que a varredura inicial, por si só, não era suficiente para confirmar um inventário completo. O problema era estrutural.
A discrepância entre o que um manifesto de dependências declara e o que realmente está sendo executado em tempo de execução não é uma discrepância insignificante. Trata-se de um problema fundamental de visibilidade no gerenciamento de dependências em Java, e o Log4Shell tornou impossível ignorá-lo.
As repercussões prolongadas de um incidente grave
Incidentes de segurança da magnitude do Log4j não são resolvidos de forma definitiva. Eles têm um efeito prolongado — longos períodos durante os quais a aplicação de patches está tecnicamente concluída nos sistemas que alguém se lembrou de verificar, enquanto instâncias vulneráveis persistem nos sistemas que ninguém se lembrou de verificar.
O impacto prolongado do Log4j tem se mostrado excepcionalmente persistente. Isso se deve, em parte, ao fato de o Java ser um ambiente de execução excepcionalmente resistente à mudança. As aplicações Java são implantadas em ambientes que não foram projetados para atualizações frequentes: sistemas industriais embarcados, plataformas financeiras legadas, software de dispositivos médicos e aplicações corporativas fornecidas por fornecedores, nas quais o cliente não controla a compilação. Esses não são contextos obscuros. Eles representam uma parcela significativa da base instalada do Java.
DEZEMBRO DE 2021
Divulgação da vulnerabilidade CVE-2021-44228. Início da aplicação de patches de emergência em todo o mundo. Lançamento do Log4j 2.15.0 – que mais tarde se revelou uma correção incompleta em determinadas configurações.
DEZEMBRO DE 2021 – JANEIRO DE 2022
Seguem-se três CVEs adicionais, todos divulgados em dezembro de 2021: CVE-2021-45046, CVE-2021-45105 e CVE-2021-44832. As equipes que aplicaram a correção para a versão 2.15.0 devem aplicá-la novamente. Análises de inventário revelam instâncias inesperadas em softwares de fornecedores e sistemas embarcados.
2022
A CISA incluiu o Log4Shell em seu catálogo de vulnerabilidades conhecidas que foram exploradas, e os agentes mal-intencionados continuaram a incorporá-lo aos kits de ferramentas padrão, juntamente com CVEs mais recentes. A exploração de sistemas legados sem patch continuou.
2023 – ATUAL
Atividades de varredura e exploração do Log4Shell ainda vêm à tona anos após a divulgação; um estudo longitudinal realizado em 2026 observou que o tráfego relacionado continuou até outubro de 2025. Aplicativos Java incorporados e fornecidos por fornecedores continuam sendo uma vulnerabilidade persistente. O incidente é considerado “resolvido” no acompanhamento formal da maioria das organizações — mas não na prática.
Essa linha do tempo ilustra algo importante: as principais vulnerabilidades não se limitam ao encerramento dos tickets de incidente. Elas persistem nas partes da infraestrutura que receberam menos atenção durante a resposta inicial: o sistema legado que a equipe de TI esqueceu, o equipamento de um fornecedor cujo fabricante levou seis meses para lançar uma correção e o serviço em contêiner que foi reconstruído a partir de uma imagem base antiga.
O que o Log4j mudou nas discussões sobre segurança interna
Se o Log4Shell teve algum efeito duradouro nas organizações além das correções, foi este: ele forçou uma reflexão sobre o quão pouco a maioria das equipes de engenharia realmente sabia sobre seu próprio software.
A pergunta “usamos o Log4j?” acabou sendo muito mais difícil de responder do que qualquer um esperava, e essa dificuldade foi constrangedora, mas de uma forma produtiva. Os arquitetos de segurança costumam descrever a mesma constatação após o fato. Eles achavam que tinham um bom inventário porque possuíam um manifesto — mas um manifesto é uma lista do que você acha que instalou, não uma lista do que está realmente em execução.
Antes do Log4Shell, as listas de materiais de software (SBOMs) eram uma preocupação de nicho — algo discutido pelas equipes de conformidade, mas não uma prioridade para as equipes de engenharia. Após o Log4Shell, o debate sobre as SBOMs passou a fazer parte das práticas de segurança convencionais. A ordem executiva do governo dos EUA sobre segurança de software, assinada em maio de 2021, meses antes da divulgação do Log4j, já havia estabelecido as SBOMs como uma expectativa básica. O Log4Shell demonstrou por que essa expectativa era razoável.
A conversa também se voltou para a questão da responsabilidade. Em grandes organizações, a pergunta “quem é responsável pelas dependências desse aplicativo?” muitas vezes não tem uma resposta clara. A equipe de engenharia que desenvolveu o aplicativo pode já ter saído da empresa. A equipe de plataforma administra a infraestrutura. A equipe de segurança pode sinalizar a vulnerabilidade, mas não pode implementar a correção. O Log4j criou situações em que três equipes diferentes ficavam, cada uma, esperando que as outras agissem, enquanto o tempo passava.
A confiança e o problema do fornecedor
O Log4Shell também prejudicou algo mais difícil de quantificar: a confiança no software fornecido pelos fornecedores. Muitas organizações descobriram que os aplicativos e dispositivos comerciais que haviam adquirido — e pelos quais pagavam contratos de suporte — continham instâncias vulneráveis do Log4j que o fornecedor não havia divulgado e não conseguia corrigir em um prazo razoável. As organizações não tinham visibilidade sobre o que esses produtos continham e não tinham poder de influência para acelerar a resposta do fornecedor.
Esse é o problema da dependência de fornecedores em sua forma mais evidente. Ao implantar um aplicativo de terceiros, você herda todo o seu gráfico de dependências, incluindo componentes que não é possível ver, atualizar nem substituir. Para as equipes de segurança, isso significa que a superfície de ataque se estende além do código escrito por seus engenheiros, abrangendo também o código escrito por seus fornecedores, e o código escrito pelos fornecedores desses, e assim por diante.
O PROBLEMA DA VISIBILIDADE, EXPLICADO DE FORMA SIMPLES
A maioria das organizações não tem conhecimento de tudo o que está em execução em seus ambientes. Elas sabem o que implantaram, mas nem sempre sabem o que estava contido no que implantaram. O Log4j tornou essa lacuna tão grave que é difícil reverter a situação.
A lição mais ampla: o caso do Log4j não foi um evento isolado
Seria conveniente tratar o Log4j como uma anomalia — uma catástrofe que ocorre uma vez a cada década, causada por um recurso excepcionalmente perigoso em uma biblioteca excepcionalmente onipresente. Essa interpretação é precisa em termos de grau, mas enganosa em sua essência. As condições que tornaram o Log4Shell tão prejudicial existem amplamente no ecossistema Java e gerarão incidentes futuros de caráter semelhante.
O ecossistema Java possui uma enorme base de código legado. Bibliotecas que foram escritas há quinze anos, quando as práticas de segurança eram diferentes e os modelos de ameaça eram mais restritos, ainda estão em execução em ambiente de produção hoje. Algumas são dependências diretas de aplicativos que não sofrem alterações há anos. Outras são dependências transitivas de frameworks que as incorporaram há muito tempo e não encontraram um motivo para removê-las.
Ao contrário dos ecossistemas de pacotes mais modernos, as ferramentas de compilação do Java facilitam o agrupamento de tudo em um único artefato pronto para implantação, o que significa que o código antigo e vulnerável acompanha o código novo, de forma imperceptível, até que um scanner ou um incidente o revele. O ponto forte do ecossistema (compatibilidade com versões anteriores, estabilidade, ampla disponibilidade de bibliotecas) é também seu ponto fraco em termos de segurança.
Não faltam candidatos para o próximo evento da magnitude do Log4j. O classe StringSubstitutor do Apache Commons Text (CVE-2022-42889, divulgada em outubro de 2022) causou alarme semelhante, pois poderia permitir a execução remota de código por meio da interpolação insegura de variáveis, embora sua explorabilidade na prática tenha se mostrado muito mais limitada do que a do Log4Shell. O ecossistema mais amplo do Apache Commons, várias bibliotecas de análise de XML, utilitários relacionados ao JNDI e ao RMI — esses são os tipos de componentes que estão presentes em aplicações Java há muito tempo, recebem menos atenção em termos de segurança do que bibliotecas mais recentes e poderiam, muito provavelmente, conter o próximo CVE crítico.
Como as equipes estão se adaptando
A resposta à incerteza revelada pelo Log4j gerou um conjunto de práticas que estão se tornando padrão em organizações que levam a sério o risco de dependências. Nenhuma delas resolve totalmente o problema. Juntas, elas representam uma redução significativa da incerteza.
01 Listas de materiais de software (SBOMs)
As equipes estão gerando SBOMs legíveis por máquina como parte do processo de compilação. O uso de ferramentas como Syft, CycloneDX ou o plug-in SBOM do Maven cria um registro auditável de todos os componentes de um artefato de implantação, incluindo dependências transitivas. Os SBOMs não impedem vulnerabilidades, mas possibilitam o inventário. Quando surgir o próximo Log4j, as organizações com SBOMs atualizados poderão responder à pergunta “fomos afetados?” em questão de horas, em vez de dias.
02 Verificação contínua de dependências em CI/CD
Eles também estão mudando a análise de vulnerabilidades de auditorias periódicas para verificações de integração contínua. Trabalhar com ferramentas como Grype, OWASP Dependency-Check ou Snyk muda a postura de reativa para preventiva. Novas vulnerabilidades em dependências existentes são identificadas imediatamente, em vez de só na próxima revisão trimestral. O desafio é lidar com a fadiga de alertas; nem todo CVE sinalizado é explorável no contexto, e os resultados indiferenciados do scanner acabam sendo rapidamente ignorados.
03 Monitoramento em tempo de execução e detecção de comportamento
A verificação estática identifica vulnerabilidades conhecidas em componentes conhecidos. Ela não detecta tentativas de exploração contra vulnerabilidades que ainda não eram conhecidas no momento da verificação. Em implantações legadas que ainda executam o JDK 17 a 23, o Java Security Manager pode oferecer controles limitados, mas foi marcado para remoção no Java 17 e desativado permanentemente no JDK 24; portanto, a proteção de tempo de execução moderna agora depende de agentes RASP e do monitoramento em nível de rede para padrões suspeitos de pesquisa JNDI — uma camada de detecção que opera em tempo de execução, em vez de em tempo de compilação.Isso é particularmente valioso para sistemas legados, nos quais é difícil adaptar a verificação estática.
04 Responsabilidade explícita e SLAs de correção
As lacunas de responsabilidade que retardaram a resposta ao Log4j em muitas organizações não eram problemas técnicos; eram problemas de processo. Estabelecer uma responsabilidade clara para cada aplicativo implantado, incluindo serviços legados, e definir SLAs explícitos para a correção de vulnerabilidades críticas (com caminhos de escalonamento quando a responsabilidade for ambígua) transforma a pergunta “quem resolve isso?” de um obstáculo recorrente em um processo regulamentado.
05 Cobertura de segurança ampliada para bibliotecas, além do suporte padrão
Para aplicativos Java que executam versões mais antigas de bibliotecas que não recebem mais manutenção ativa, a resposta convencional é “atualizar”. Quando as atualizações não são viáveis devido a restrições do fornecedor, congelamentos regulatórios ou sistemas legados frágeis, as equipes precisam de uma maneira de receber patches de segurança sem precisar migrar para uma nova versão principal. Serviços como o Endless Lifecycle Support (ELS) para Bibliotecas da TuxCare fornecem correções de segurança retrocompatíveis para as versões de bibliotecas cobertas, ajudando as equipes a manter uma configuração conhecida e estável protegida contra vulnerabilidades atuais enquanto planejam uma migração de longo prazo. Trata-se de uma ponte, não de um destino, mas é uma solução significativa quando a alternativa é operar sem patches porque a atualização só ocorrerá daqui a meses.
Aceitando a incerteza residual
Existe uma versão dessa conversa que termina com uma lista de verificação: implementar SBOMs, implantar varreduras, definir responsabilidades e gerenciar janelas de suporte. Basta seguir essas etapas e o problema estará resolvido. Essa versão é mais simples do que a realidade.
A verdade é que os sistemas de software complexos contêm incertezas residuais que não podem ser totalmente eliminadas, apenas gerenciadas. Você não conseguirá ter visibilidade completa de todas as dependências em seu ambiente. Você não conseguirá aplicar patches em todas as bibliotecas vulneráveis antes que o próximo CVE crítico seja divulgado. O software fornecido pelos fornecedores continuará contendo componentes que você não pode ver nem controlar.
O que você pode fazer é tomar decisões deliberadas sobre onde investir para reduzir essa incerteza, em vez de deixar que ela se acumule de forma imperceptível até que um incidente force a discussão. O Log4j foi, entre outras coisas, um fator determinante, um momento em que o custo do risco de dependências invisíveis se tornou inegável.
As equipes que saíram da resposta ao Log4Shell com uma postura de segurança aprimorada não foram aquelas que aplicaram os patches mais rapidamente. Foram aquelas que encararam o incidente como uma fonte de informação sobre seus próprios sistemas: o que elas não sabiam, onde seus processos apresentavam lacunas, quais partes de seu ambiente não tinham um responsável definido. Elas aproveitaram a interrupção para construir algo mais duradouro do que um arquivo JAR corrigido.
Essa pergunta deve servir de base para todas as análises de segurança pós-Log4j. A questão nunca se resume apenas a saber se você já aplicou o patch, mas sim ao grau de confiança que você tem nessa resposta – e o que você está fazendo para sanar essa lacuna.
Conheça o Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare para bibliotecas →
