Fim da vida útil do Apache Struts: mantenha suas aplicações web em Java seguras | TuxCare ELS

Principais conclusões

• Quando uma versão do Struts chega ao fim de sua vida útil, toda a pilha de dependências — OGNL, FreeMarker, Commons FileUpload, Commons BeanUtils, Log4j2 e outras — deixa de receber correções de segurança coordenadas juntamente com a própria estrutura.
• A migração do Struts 2.5.x para o 6.x exige atualizações do ambiente de execução do Java, alterações na API do Servlet, reescrita de expressões OGNL, substituição de interfaces de interceptadores e remoção de padrões de acesso a métodos estáticos; tudo isso requer um planejamento cuidadoso e testes extensivos, e não prazos apertados.
• O TuxCare ELS amplia a cobertura de segurança para as versões do Struts em fim de vida útil (EOL) e suas árvores de dependências, permitindo que as organizações mantenham a segurança e a conformidade enquanto planejam uma migração deliberada, com recursos adequados e de acordo com seu próprio cronograma.

O Struts tem sido a espinha dorsal do desenvolvimento web corporativo em Java há mais de duas décadas. Sua arquitetura Modelo-Visão-Controlador, seu ecossistema maduro de plug-ins e sua profunda integração com a pilha corporativa Java mais ampla o tornaram a estrutura preferida para aplicativos web de grande escala nos setores de serviços financeiros, governo, saúde e telecomunicações. Mas o Struts tem um histórico que torna a questão do fim de vida útil (EOL) excepcionalmente delicada. Ele possui o histórico de vulnerabilidades CVE mais significativo entre todas as estruturas web Java em produção, e as organizações que utilizam versões do Apache Struts em fim de vida útil (EOL) estão expostas a um perfil de risco que, com a violação de dados da Equifax em 2017, deixou de ser teórico para se tornar notícia de primeira página.

Este artigo explica o que o fim da vida útil (EOL) do Apache Struts realmente significa para as equipes de desenvolvimento de aplicativos Java, onde se esconde a verdadeira vulnerabilidade de segurança na árvore de dependências, por que o caminho de migração para as versões atuais é mais desafiador do que parece e como o Endless Lifecycle Support (ELS) da TuxCare permite que você mantenha cobertura total de segurança e conformidade sem forçar uma migração para a qual suas equipes ainda não estão preparadas.

O que é o ciclo de vida do produto Apache Struts?

O Struts não segue uma cadência de lançamento formalmente documentada e baseada em prazos, como acontece com alguns outros projetos de código aberto. O PMC (Comitê de Gestão do Projeto) da Apache Software Foundation publica avisos de fim de vida útil (EOL) diretamente no site do projeto quando um ramo principal está prestes a ser descontinuado, geralmente com um aviso prévio de seis meses antes do término formal do suporte. Os avisos de EOL não estão vinculados a um cronograma fixo; eles refletem a capacidade da comunidade de manter um determinado ramo e a disponibilidade de um sucessor com suporte.

Por exemplo, você pode consultar nosso guia sobre o fim da vida útil (EOL) do Apache Kafka para ver como a infraestrutura de streaming lida com mudanças bruscas de suporte semelhantes, ou analisar como as estruturas de big data gerenciam um marco do ciclo de vida relacionado ao fim da vida útil do Apache Spark. Você também pode saber mais sobre o fim da vida útil (EOL) do Apache Hive em nosso guia detalhado, caso esteja gerenciando componentes de data warehouse.

O projeto segue o sistema de versionamento semântico e mantém o suporte aos seus ramos ativos atuais. Os avisos de fim de vida útil (EOL) têm historicamente incluído seis meses de cobertura exclusiva de segurança após o anúncio inicial; após esse período, o ramo não recebe mais nenhum tipo de correção. Isso significa que não há período de carência para vulnerabilidades de segurança divulgadas após a data final de EOL; qualquer CVE que afete um ramo em EOL não receberá uma correção oficial da comunidade.

Status atual do suporte à versão do Struts:

Versão	Data de lançamento	Data de fim de vida útil	Status
Struts 1.x	2000–2008	Abril de 2013	EOL
Struts 2.3.x	2012	Maio de 2019	EOL
Struts 2.5.x	Maio de 2016	30 de abril de 2024	EOL
Struts 6.x	Junho de 2022	Não anunciado	Ativo (mais recente)
Struts 7.x	Dezembro de 2024	Não anunciado	Ativo

O Struts 2.5.x, a versão mais amplamente implantada em ambientes corporativos, recebeu sua versão final (2.5.33) em dezembro de 2023 e chegou formalmente ao fim de vida útil em 30 de abril de 2024. As organizações que ainda não concluíram sua migração para o Struts 6.x ou 7.x estão, atualmente, utilizando uma estrutura Apache Struts em fim de vida útil, sem cobertura de patches de segurança do desenvolvedor original.

A consequência prática desse modelo de ciclo de vida é significativa. Como o projeto não divulga datas fixas de fim de vida útil (EOL) com anos de antecedência, as organizações frequentemente percebem que um anúncio de EOL chega antes que a migração tenha sido orçada, dotada de recursos e planejada. O prazo de aviso prévio de seis meses do Apache Struts para o fim de vida útil não é tempo suficiente para que grandes aplicativos corporativos, com ampla integração ao Struts, concluam uma migração testada e validada.

O que o fim da vida útil (EOL) do Apache Struts significa para as aplicações web em Java?

Para organizações que utilizam o Struts como camada web de aplicativos Java de missão crítica — responsáveis por lidar com solicitações HTTP voltadas ao público, gerenciar uploads de arquivos, processar envios de formulários e atuar na frente de camadas de lógica de negócios que envolvem registros financeiros, dados de pacientes ou sistemas governamentais —, a designação de fim de vida útil (EOL) do Apache Struts não é uma mera questão administrativa. Trata-se de um evento de segurança com consequências diretas para a conformidade.

Não haverá mais patches de segurança após a data de fim de vida útil (EOL)

Quando uma versão do Struts chega ao fim de vida útil (EOL), a comunidade Apache deixa de publicar correções de segurança para ela. Qualquer vulnerabilidade divulgada após a data de EOL — seja no despachador central do framework, em seu mecanismo de avaliação de expressões OGNL, no tratamento de upload de arquivos ou em sua pilha de interceptadores — não receberá um patch oficial. A única solução oferecida pela comunidade é a migração para uma versão com suporte.

Para equipes que administram grandes aplicativos web essenciais à produção, nos quais a migração exige a reescrita de classes de ação, a substituição de interfaces de interceptadores, a atualização de expressões OGNL em todos os modelos e a validação do comportamento em dezenas ou centenas de pontos de extremidade do aplicativo, isso nem sempre é uma opção em curto prazo. O intervalo entre o momento em que o status de EOL entra em vigor e o momento em que uma migração pode, de forma realista, ser concluída e validada é exatamente quando se acumulam vulnerabilidades não corrigidas.

Riscos de segurança e conformidade após o fim da vida útil

As consequências em termos de conformidade decorrentes da utilização de uma versão do Struts em fim de vida (EOL) são diretas. A norma PCI DSS (Requisito 6.3.3) exige que patches críticos e de alta gravidade sejam instalados no prazo de um mês a partir do lançamento do patch; no entanto, em uma versão do Struts em fim de vida, não há patches para instalar, tornando impossível a conformidade por meios normais. Os auditores SOC 2 sinalizam a presença de software em fim de vida útil em ambientes de produção. As organizações que utilizam implantações do Apache Struts em fim de vida útil enfrentam lacunas na documentação que vêm à tona em questionários de segurança, atrasam certificações de fornecedores e, em setores regulamentados, impedem a renovação de contratos com clientes.

Para organizações nas quais as aplicações Struts estão dentro do escopo da PCI, processam informações de identificação pessoal ou sustentam serviços com obrigações contratuais de SLA, o risco de não conformidade decorrente desse evento de fim de vida útil (EOL) não é teórico. Trata-se de uma constatação de auditoria prestes a se concretizar.

Histórico do CVE: o que o registro de vulnerabilidades revela

O Struts possui o histórico de CVEs mais significativo entre todas as estruturas web Java em produção, e esse histórico demonstra claramente por que a aplicação de correções para softwares em fim de vida (EOL) não é opcional.

CVE-2017-5638 (CVSS 10.0 Crítico) é a vulnerabilidade que expôs dados pessoais e financeiros de 147 milhões de pessoas no vazamento da Equifax, um dos vazamentos de dados mais prejudiciais da história. A falha residia no analisador Jakarta Multipart: um invasor poderia criar um cabeçalho HTTP Content-Type malicioso que acionasse um tratamento inadequado de exceções no analisador, resultando na execução arbitrária de comandos no servidor com os privilégios do processo do servidor web. Não era necessária autenticação. Códigos de exploração ficaram disponíveis publicamente poucos dias após a divulgação, e a exploração ativa na rede começou imediatamente. Um patch foi lançado em 7 de março de 2017. A falha da Equifax em aplicá-lo deixou seus sistemas expostos por 144 dias, tempo suficiente para que os invasores extraíssem números de Seguro Social, datas de nascimento e números de carteira de motorista ao longo de uma campanha prolongada. A violação resultou em um acordo de US$ 700 milhões, depoimentos no Congresso e se tornou o estudo de caso definitivo sobre quanto realmente custa a exposição do Struts sem patch. A correção estava disponível. O intervalo entre a disponibilidade do patch e sua aplicação foi o que determinou o resultado.

CVE-2023-50164 (NVD CVSS 3.1: 9,8 – Crítico) demonstrou que a exposição crítica do Struts à execução remota de código (RCE) não terminou com a geração de vulnerabilidades de 2017. Essa falha residia na lógica de envio de arquivos da estrutura: um invasor poderia manipular os parâmetros de envio de arquivos para permitir o traversal de caminho e, em seguida, enviar um arquivo malicioso para um local acessível ao servidor web – possibilitando a execução remota de código. O vetor CVSS AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H indica que não é necessária autenticação, não há interação do usuário, é acessível pela rede e há comprometimento total da confidencialidade, integridade e disponibilidade. Explorações de prova de conceito foram publicadas poucos dias após a divulgação em dezembro de 2023. As versões afetadas abrangiam todo o histórico do Struts 2, desde a 2.0.0 até a 2.5.32 e da 6.0.0 até a 6.3.0. O Struts 2.5.33 recebeu um patch – mas o Struts 2.5.33 é a versão final da série Struts 2.5.x, o que significa que o ramo está agora no fim da vida útil (EOL). Qualquer CVE divulgado contra o Struts 2.5.33 daqui em diante não receberá uma correção da comunidade.

CVE-2024-53677 (NVD CVSS 3.1: 9,8 – Crítico) é a ilustração mais direta do que o status de fim de vida útil (EOL) do Apache Struts significa na prática atualmente. Divulgada em dezembro de 2024, essa vulnerabilidade crítica de traversal de caminho no mecanismo de upload de arquivos do Struts afeta todas as versões do Struts, da 2.0.0 à 6.3.0.2 – incluindo o Struts 2.5.33, a versão final com fim de vida útil. O vetor de ataque é idêntico ao da CVE-2023-50164: um invasor manipula os parâmetros de upload de arquivos para acessar um caminho não pretendido no servidor e enviar um arquivo malicioso, conseguindo a execução remota de código. A correção requer a atualização para o Struts 6.4.0 e a migração para o novo interceptador Action File Upload. O Struts 2.5.33, por ser um ramo em fim de vida (EOL), não recebeu nenhum patch. Qualquer organização que ainda execute o Struts 2.5.x fica permanentemente exposta a essa vulnerabilidade crítica de RCE, sem nenhum caminho oficial de correção disponível – exatamente o cenário de risco de fim de vida do Apache Struts abordado neste artigo.

Essa é exatamente a categoria de vulnerabilidade — execução de código remoto (RCE) sem autenticação e acessível pela rede na infraestrutura de aplicativos web em produção — que se torna uma exposição permanentemente não resolvida em versões em fim de vida (EOL). O caso da Equifax demonstrou que esse não é um risco que as organizações possam gerenciar apenas por meio de monitoramento ou detecção. A única solução duradoura é uma versão corrigida.

O risco oculto: a árvore de dependências do Struts

A superfície de vulnerabilidade de uma implantação do Struts não se limita ao próprio binário do framework. O Struts vem com um conjunto substancial de dependências que trazem seus próprios riscos de segurança — e, quando o Struts chega ao fim de vida útil, a aplicação coordenada de correções nessas dependências no contexto daquela versão do Struts também chega ao fim.

O módulo struts2-core incorpora o OGNL (a biblioteca Object-Graph Navigation Language) como uma dependência direta de tempo de execução – e o OGNL possui seu próprio histórico de CVEs decorrente de seu papel como principal mecanismo de avaliação de expressões, que foi explorado em inúmeras vulnerabilidades do Struts. O FreeMarker está incluído para a renderização de modelos. O Apache Commons FileUpload lida com dados de formulários multiparte e esteve diretamente envolvido no CVE-2017-5638. O Apache Commons BeanUtils, o Commons Collections, o Commons IO e o Commons Lang são todos dependências de tempo de execução. O Log4j2 está incluído para registro em log – uma biblioteca cujo próprio histórico de vulnerabilidades críticas (Log4Shell, CVE-2021-44228) gerou uma onda de patches de emergência em todo o ecossistema Java. O Jackson Databind lida com o processamento de JSON nos plug-ins. A integração com o framework Spring traz o spring-core, spring-beans, spring-context, spring-web e Spring AOP quando o plug-in Spring é utilizado. O Hibernate Validator é incorporado para a validação de beans.

Cada uma dessas dependências possui seu próprio fluxo de CVEs de origem. Quando um ramo do Struts chega ao fim da vida útil (EOL), a comunidade deixa de emitir atualizações coordenadas para todas essas dependências no contexto daquela versão do Struts. Os scanners de vulnerabilidades executados em implantações do Struts em fim de vida útil (EOL) gerarão resultados em toda a árvore de dependências para os quais não há correção oficial disponível para essa versão, deixando as equipes de segurança com uma lista crescente de resultados de varredura que não podem ser resolvidos.

A árvore de dependências do struts2-core abrange mais de 20 dependências diretas e transitivas quando se incluem os plug-ins comuns. Cada uma delas possui sua própria árvore transitiva. A área prática de correção de uma implantação do Struts 2.5.x em produção, com um conjunto típico de plug-ins, é substancialmente maior do que apenas o binário do framework, e todos os componentes dessa árvore deixam de receber cobertura coordenada quando o ramo pai do Struts chega ao fim da vida útil (EOL).

Opções para manter a segurança e a conformidade

As organizações que utilizam versões do Apache Struts em fim de vida útil (EOL) têm três opções à disposição. Duas delas envolvem um esforço significativo de engenharia, risco operacional e prazos prolongados. A terceira — o Suporte de Ciclo de Vida Ilimitado da TuxCare — elimina imediatamente a lacuna de segurança enquanto suas equipes planejam a migração de forma adequada.

Opção 1: Migrar para uma versão atual do Struts

A solução a longo prazo é migrar o aplicativo para uma versão do Struts que receba suporte atualmente. As versões com suporte ativo são o Struts 6.x e o Struts 7.x, sendo que a 7.1.1 é a versão mais recente em outubro de 2025.

A realidade prática, especialmente para grandes aplicativos desenvolvidos com o Struts 2.5.x, é que não se trata de uma simples atualização de versão. Trata-se de uma migração que envolve alterações coordenadas em toda a base de código do aplicativo, na configuração e no ambiente de execução. O Struts 6.0 requer, no mínimo, o Java 8 e a API Servlet 3.1 — as organizações que utilizam ambientes Java mais antigos devem atualizar o ambiente de execução antes que a migração do framework possa prosseguir. Todas as constantes de configuração do Struts 2.3 foram removidas na versão 6.0; qualquer aplicativo que utilize constantes obsoletas deve atualizá-las para suas substituições. O namespace do pacote XWork foi reorganizado, exigindo atualizações nas importações nas classes Action. O acesso a métodos estáticos por meio de expressões OGNL, um padrão utilizado em muitas aplicações Struts 2.x, foi totalmente removido na versão 6.0 e deve ser substituído por wrappers de métodos de instância de Action. O comprimento das expressões OGNL é limitado a 256 caracteres por padrão, o que interrompe expressões mais longas que possam estar espalhadas pelos modelos FreeMarker e JSPs.

 

A migração para o Struts 7.x traz um número substancialmente maior de requisitos, e dois deles já representam esforços enormes por si só, antes mesmo de se tocar em uma única linha de código do Struts. Primeiro, o Struts 7.x exige o Java 17 como ambiente de execução mínimo. Para organizações que ainda utilizam o Java 8 ou o Java 11 — o que é comum em grandes implantações corporativas do Struts —, isso significa planejar e executar uma atualização completa da JVM em todos os ambientes: desenvolvimento, CI, staging e produção. Em segundo lugar, o Struts 7.x requer o Jakarta EE, o que significa que cada importação `javax.*` em toda a base de código deve ser atualizada para seu equivalente `jakarta.*`. Essa migração do namespace `javax` para `jakarta` afeta `javax.servlet.*`, `javax.annotation.*`, `javax.persistence.*` e todos os outros pacotes `javax.*`, onde quer que apareçam nas classes `Action`, arquivos de configuração, interceptadores personalizados, JSPs e quaisquer bibliotecas de terceiros na árvore de dependências que ainda não tenham publicado versões compatíveis com o Jakarta EE. Em grandes bases de código corporativas, essa migração de namespace por si só pode abranger milhares de instruções de importação em centenas de arquivos e requer validação de ponta a ponta em todas as camadas da pilha de aplicativos. Somente após esses dois pré-requisitos serem atendidos é que o trabalho de migração específico do Struts começa: cada setter de classe Action que aceita parâmetros de solicitação deve ser explicitamente anotado com `@StrutsParameter`, uma alteração que pode afetar centenas de setters em um aplicativo maduro. Os padrões de mapeamento de namespace foram alterados para exigir correspondências exatas, o que pode quebrar links em modelos existentes. O antigo Interceptor de Upload de Arquivos foi totalmente removido e substituído pelo Interceptor de Upload de Arquivos da Action, exigindo alterações de configuração e código em aplicativos que lidam com uploads de arquivos. Para aplicativos com investimento significativo no Struts — o que inclui a maioria dos aplicativos para os quais a questão da migração é relevante —, uma migração para o Struts 7.x devidamente planejada e testada leva meses, não semanas.

Opção 2: Migrar para uma estrutura web diferente

Algumas organizações encaram o fim do ciclo de vida (EOL) do Apache Struts como um gatilho para avaliar frameworks web Java alternativos: Spring MVC, Jakarta EE com Faces, Micronaut, Quarkus ou outros. O argumento arquitetônico tem seu mérito em alguns contextos, especialmente quando arquiteturas modernas do tipo “REST-first” atenderiam melhor aos requisitos atuais da aplicação, ou quando modelos de implantação nativos da nuvem se beneficiariam de um framework mais leve.

A migração completa de um framework é muito mais cara do que uma atualização da versão do Struts. Classes de ação, modelos JSP, visualizações FreeMarker, layouts Tiles, configurações de validação, pilhas de interceptadores e mapeamentos struts.xml exigem substituição ou reformulação significativa. O modelo de programação é diferente, o modelo de implantação é diferente, e as versões do Struts em fim de vida útil (EOL) continuam em execução em produção durante todo o processo de avaliação, planejamento e migração. Trata-se de uma decisão estratégica de infraestrutura que merece um cronograma próprio e cuidadosamente planejado, e não uma decisão forçada por uma data de fim de vida útil (EOL) que se aproxima antes do previsto.

Opção 3: Suporte de ciclo de vida estendido da TuxCare: o caminho recomendado

Essa é a opção que resolve o problema imediato sem criar novos problemas. O Suporte de Ciclo de Vida Ilimitado da TuxCare para o Struts significa que você continua executando sua versão atual do Struts em produção, ao mesmo tempo em que recebe cobertura contínua de patches de segurança para o framework e sua árvore de dependências, fornecida por meio de sua cadeia de ferramentas Maven ou Gradle existente, sem a necessidade de migração forçada.

A lacuna de segurança é sanada imediatamente. Sua conformidade é mantida. Suas equipes ficam livres para planejar a migração adequada em um cronograma que faça sentido do ponto de vista operacional — incluindo o prazo adicional necessário para anotar classes de ação relacionadas à injeção de parâmetros no Struts 7.x, atualizar padrões de expressão OGNL em todos os modelos e validar o comportamento em todo o conjunto de endpoints do aplicativo. Sem migração forçada sob pressão de prazos, sem emergências de conformidade, sem regressões de comportamento em aplicativos web em produção que atendem usuários ativos.

Os riscos de apressar uma migração para o Struts

Quando um status de fim de vida útil (EOL) é registrado em um painel de segurança e a equipe de conformidade começa a fazer perguntas, a pressão para agir imediatamente é real. Compreender o que uma migração apressada do Struts realmente implica é tão importante quanto compreender a própria vulnerabilidade.

O que uma migração do Struts realmente envolve

Uma migração adequada do Struts — especialmente da versão 2.5.x para a 6.x ou 7.x — é um projeto de aplicação em várias fases, e não apenas uma atualização da versão de uma dependência. Isso requer a auditoria de toda a base de código em busca de APIs obsoletas e recursos removidos, a atualização do ambiente de execução Java caso a versão atual esteja abaixo do mínimo exigido pelo Struts 6.x, a atualização das referências à API Servlet e das configurações dos descritores de implantação, a substituição de constantes de configuração obsoletas em todo o arquivo struts.xml, a atualização de todas as importações de classes Action afetadas pela reorganização do pacote XWork e a reescrita de expressões OGNL que dependem do acesso a métodos estáticos ou excedem o novo limite de 256 caracteres.

Adaptação de código: Todo setter da classe Action que aceite parâmetros de formulário ou de solicitação deve ser anotado com @StrutsParameter no Struts 7.x. Em uma aplicação de grande porte, com dezenas ou centenas de classes Action, trata-se de uma alteração sistemática na base de código que exige uma revisão minuciosa para evitar a omissão inadvertida de pontos de injeção — o que causaria falhas silenciosas no processamento do envio de formulários.

Verificação de compatibilidade: Todos os JSPs, modelos FreeMarker e modelos Velocity do aplicativo precisam ser revisados quanto a expressões OGNL que utilizem acesso a métodos estáticos, excedam os limites de comprimento ou façam referência a bibliotecas de tags obsoletas. Mudanças no comportamento de renderização dos modelos — incluindo as configurações padrão de escape automático do FreeMarker — podem introduzir diferenças sutis na saída que se manifestam nos testes de ponta a ponta.

Adaptação da cadeia de ferramentas: As configurações de compilação, os pipelines de CI/CD e os descritores de implantação que fazem referência a plug-ins específicos do Struts, declarações DTD e constantes de configuração precisam ser revisados e atualizados. O plug-in Tiles sofreu alterações ao longo das versões; o suporte ao Velocity foi transferido para um plug-in dedicado. Qualquer dependência de plug-in que tenha sido removida na versão de destino deve ser substituída ou removida da compilação.

Carga de testes: Testes abrangentes de ponta a ponta em toda a aplicação — abrangendo envios de formulários, uploads de arquivos, fluxos de validação, comportamento dos interceptadores e renderização de resultados — não podem ser ignorados. Mudanças comportamentais no modelo de injeção de parâmetros, padrões de mapeamento de namespace e semântica de avaliação do OGNL precisam ser validadas sob padrões de solicitação realistas antes da implantação em produção.

O que acontece quando uma migração é feita às pressas

Quando as equipes concentram esse trabalho sob a pressão de prazos, as consequências são previsíveis e seguem um padrão consistente.

Aumento da carga de suporte: Lacunas nas anotações das classes Action, atualizações não realizadas nas expressões OGNL e alterações não verificadas na renderização de modelos se manifestam na produção como falhas no envio de formulários, fluxos de validação interrompidos e comportamento inesperado na renderização de páginas. Isso gera uma onda de incidentes que as equipes de engenharia e operações precisam absorver além das cargas de trabalho normais.

Instabilidade do sistema: As aplicações Struts costumam sustentar fluxos de trabalho voltados para o cliente, como solicitações de empréstimo, portais de pacientes e envios de solicitações de serviços públicos, nos quais regressões de comportamento afetam os usuários reais imediatamente. Mudanças sutis na vinculação de parâmetros, na ordem de execução dos interceptores ou na renderização de resultados podem causar falhas intermitentes que são difíceis de reproduzir e que se manifestam sob volumes de solicitações em produção que os testes de pré-produção raramente conseguem igualar.

Acúmulo de dívida técnica: Soluções provisórias implementadas sob pressão de tempo tornam-se permanentes. Classes de ação anotadas em massa, sem revisão, introduzem pontos de injeção de parâmetros indesejados. As expressões OGNL foram refatoradas rapidamente, sem compreensão das implicações de segurança do novo modelo de lista de permissões, criando vulnerabilidades que não existiam antes da migração. O problema do fim de vida útil (EOL) do Apache Struts foi adiado, não resolvido.

Custos não planejados: Horas extras de engenharia para emergências, atrasos no lançamento de funcionalidades, despesas indiretas com resposta a incidentes e o custo de oportunidade de engenheiros sênior dedicarem-se à depuração de falhas em aplicativos web em produção, em vez de desenvolverem novos recursos — tudo isso se acumula rapidamente e de maneiras difíceis de prever com antecedência.

A solução fácil: TuxCare ELS para o Apache Struts EOL

A TuxCare oferece suporte contínuo ao ciclo de vida para versões do Struts que chegaram ao fim de vida. Em vez de forçar uma migração para a qual suas equipes ainda não estão preparadas, você continua operando sua implantação atual do Struts com cobertura contínua de patches de segurança, fornecida por meio de sua cadeia de ferramentas de compilação Maven ou Gradle já existente.

A TuxCare vem fazendo isso há mais de uma década, fornecendo patches de segurança para sistemas operacionais, ambientes de execução, bibliotecas e estruturas de aplicativos que chegaram ao fim de vida útil. A empresa já distribuiu mais de 220.000 patches de segurança em todo o ecossistema de código aberto. Quando afirmam que sabem como manter o software em fim de vida útil seguro em escala empresarial, isso não é apenas retórica de marketing. Eles têm feito isso em grande escala, de forma consistente.

Cobertura completa da árvore de dependências: O ELS para Struts da TuxCare abrange a estrutura e suas dependências diretas e transitivas, incluindo OGNL, FreeMarker, Commons FileUpload, Commons BeanUtils, Commons Collections, Log4j2 e outras bibliotecas que apresentam suas próprias vulnerabilidades CVE, sem custo adicional. Os scanners de vulnerabilidades não respeitam os limites dos pacotes, e a cobertura da TuxCare também não. Toda a área de aplicação de patches é abordada, não apenas o artefato Struts de nível superior.

Processo refinado e automatizado de aplicação de patches: A TuxCare monitora o NVD, os alertas de segurança dos fornecedores, a lista de CVEs do próprio Apache e os feeds de segurança do GitHub — todos os canais onde vulnerabilidades do Struts e de suas dependências são divulgadas. Quando um CVE é identificado, ferramentas algorítmicas e automação assistida por IA se encarregam de aplicar as correções de segurança à versão suportada, e especialistas em segurança validam cada patch antes de sua distribuição. Cada atualização passa por testes de integridade, funcionalidade e regressão antes de chegar aos seus repositórios. Para obter detalhes técnicos completos, consulte o white paper técnico da TuxCare sobre seu processo de aplicação de patches para software de código aberto.

Integração perfeita: Quer você utilize atualmente o Struts via Maven ou Gradle, é possível mudar sua fonte de atualizações para o repositório seguro da TuxCare com alterações mínimas em seu fluxo de trabalho existente. Não há alterações em seu pipeline de compilação, nem em seus fluxos de trabalho de CI/CD, nem na forma como suas equipes trabalham. As atualizações de segurança são distribuídas automaticamente por meio de sua cadeia de ferramentas existente.

Resposta rápida garantida por SLA: Quando novas vulnerabilidades são divulgadas em versões do Apache Struts em fim de vida (EOL), seja no próprio framework ou em sua árvore de dependências, a TuxCare fornece patches dentro de um prazo garantido, respaldado por acordos de nível de serviço. Vulnerabilidades de gravidade alta e crítica (CVSS 7+) são corrigidas em até 14 dias após a divulgação pública. Você não precisa esperar por um backport da comunidade que talvez nunca chegue para uma versão do Struts em fim de vida útil. Você recebe patches prontos para produção em um cronograma que permite seu planejamento, com suporte especializado 24 horas por dia, 7 dias por semana, para triagem de vulnerabilidades e solução de problemas.

Continuidade de segurança com boa relação custo-benefício: O custo do TuxCare ELS é uma fração do que custa uma migração de infraestrutura de emergência quando imposta por um prazo de conformidade, considerando o tempo de engenharia, o risco operacional, a resposta a incidentes e o atraso no plano de trabalho. Cobertura de segurança previsível, um cronograma de migração controlado e a ausência de emergências de conformidade são o que tornam o suporte estendido a estratégia empresarial certa.

Para saber exatamente quais vulnerabilidades foram corrigidas nas versões do Struts que chegaram ao fim da vida útil (EOL), a TuxCare mantém um rastreador CVE em tempo real para o Struts.

Não deixe que o fim da vida útil do Apache Struts coloque suas aplicações web em risco

O fim do ciclo de vida (EOL) do Apache Struts não significa que sua aplicação esteja imediatamente comprometida, nem que você precise realizar uma migração de emergência para a qual suas equipes não estejam preparadas. No entanto, esse status de EOL do Apache Struts significa que a proteção de segurança da qual a infraestrutura da sua aplicação web dependia não existe mais, e a violação de dados da Equifax demonstrou exatamente quais são as consequências, em grande escala, da exposição do Struts sem patches.

As organizações que lidam bem com isso são aquelas que tratam esse status de EOL como um problema de segurança a ser gerenciado, e não como um prazo ao qual se deve reagir sob pressão. É possível planejar uma migração deliberada para o Struts 6.x ou 7.x quando isso realmente se encaixar na capacidade da sua equipe, incluindo o tempo adicional necessário para anotar corretamente as classes Action, atualizar os padrões de expressão OGNL em toda a camada de modelos e validar o comportamento em todo o conjunto de endpoints. Você pode avaliar se uma migração mais ampla da estrutura atende a um objetivo arquitetônico real. Ou pode usar o TuxCare ELS para manter total segurança e conformidade enquanto toma essas decisões de acordo com seu próprio cronograma, e não com o de um auditor de conformidade.

O suporte estendido não é uma solução provisória. É a opção que mantém suas aplicações Struts seguras, sua conformidade intacta e suas equipes de engenharia focadas no desenvolvimento — e não em resolver problemas urgentes. Se o fim da vida útil (EOL) do Apache Struts estiver em seu radar de segurança neste momento, acesse Suporte de Ciclo de Vida Ilimitado da TuxCare para Software de Código Aberto para ver como o suporte estendido pode proteger sua infraestrutura de aplicativos web pelo tempo que você precisar.