Fim da vida útil do Apache Spark: mantenha seus pipelines de dados seguros | TuxCare ELS

Principais conclusões

• A árvore de dependências multiplica sua exposição: Uma implantação do Spark em produção traz uma quantidade significativa de dependências diretas e transitivas, como bibliotecas clientes do Hadoop, Netty, Jackson Databind, Apache Parquet, Apache Avro, Guava e muitas outras, cada uma com seu próprio fluxo de CVEs que deixa de receber cobertura coordenada quando ocorre a transição de fim de vida útil (EOL) do Apache Spark, seu pai.
• Atualizações apressadas são caras e arriscadas: Migrações motivadas pelo pânico levam a incidentes em produção, instabilidade do sistema, acúmulo de dívida técnica e custos não planejados que excedem em muito o custo do suporte estendido.
• O fim do ciclo de vida (EOL) do Apache Spark não significa o fim da segurança: Opções de suporte estendido, como o TuxCare ELS, oferecem cobertura de segurança contínua para versões em fim de vida útil enquanto você planeja atualizações estrategicamente.

O Apache Spark tem sido o motor que impulsiona a engenharia de dados corporativos, a análise em grande escala e o aprendizado de máquina há mais de uma década. Sua capacidade de processar conjuntos de dados massivos na memória, simultaneamente em tarefas em lote, pipelines de streaming e cargas de trabalho de aprendizado de máquina, tornou-o a escolha padrão para organizações com uso intensivo de dados nos setores de serviços financeiros, saúde, comércio eletrônico, telecomunicações e órgãos governamentais.

A onipresença do Spark na infraestrutura crítica de produção, no entanto, significa que a questão de segurança relacionada ao fim da vida útil (EOL) do Apache Spark tem um peso operacional real. As organizações que utilizam versões do Apache Spark em fim de vida útil assumem um risco de segurança e conformidade em uma das camadas mais intensivas em dados de sua pilha de tecnologia — a camada que processa rotineiramente registros confidenciais de clientes, transações financeiras e dados regulamentados em grande escala.

Este artigo explica o que o fim do ciclo de vida (End of Life) do Apache Spark realmente significa para as equipes de engenharia de dados, onde se concentra o verdadeiro risco à segurança na árvore de dependências, por que a migração para as versões atuais é mais complexa do que parece e como o Suporte de Ciclo de Vida Ilimitado (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 estejam preparadas.

O que é o ciclo de vida do Apache Spark?

O Apache Spark segue um sistema de versionamento semântico estruturado da seguinte forma: [MAJOR].[FEATURE].[MAINTENANCE]. As versões secundárias (de recursos) são normalmente publicadas a cada seis meses e recebem correções de bugs e de segurança por um período de 18 meses após o lançamento. A última versão secundária dentro de cada versão principal é designada como uma versão LTS (Suporte de Longo Prazo) e é mantida por um período mais longo, normalmente em torno de 31 meses.

O status de suporte das versões do Spark:

O Spark 3.5, a última versão LTS da série 3.x e a versão mais amplamente implantada em empresas que ainda não migraram para a geração 4.x, está programado para atingir o fim da vida útil (EOL) do Apache Spark em 12 de abril de 2026. O Spark 3.4 atingiu o EOL do Apache Spark em outubro de 2024. O Spark 3.3 atingiu o EOL do Apache Spark em dezembro de 2023. As organizações que ainda utilizam qualquer uma dessas versões já estão operando com estruturas sem patches, e aquelas que utilizam o Spark 3.5 têm pouco tempo restante antes que a mesma situação se aplique a elas.

Leia nossa análise detalhada do cronograma de fim de vida útil do Apache Spark para entender o que essas datas significam para sua pilha de produção.

O modelo de janela de manutenção de 18 meses significa que as transições de fim de vida útil (EOL) do Apache Spark ocorrem de acordo com um cronograma, mas o tempo que decorre entre o momento em que uma versão é implantada pela primeira vez em produção e o momento em que uma equipe de engenharia de dados está pronta para concluir uma atualização validada costuma ser muito mais longo. Quando chega a data de fim de vida útil do Apache Spark, a cobertura de segurança da qual seus pipelines dependiam simplesmente desaparece e, ao contrário dos eventos de fim de vida útil dos sistemas operacionais, não há período de carência nem nível de suporte estendido por parte do próprio projeto upstream.

O que o fim do ciclo de vida (EOL) do Apache Spark significa para as plataformas de engenharia de dados?

Para organizações nas quais o Spark é o mecanismo de processamento de pipelines de dados de produção que executam fluxos de trabalho ETL para alimentar sistemas financeiros a jusante, processam informações de identificação pessoal em grande escala, promovem a detecção de fraudes em tempo real ou servem de base para bancos de características de aprendizado de máquina, a designação de “Fim da Vida Útil” do Apache Spark constitui um evento direto de segurança e conformidade, e não um item de manutenção secundário.

Não haverá mais correções de segurança após a data de fim de vida útil (EOL) do Apache Spark

Quando uma versão do Spark atinge o fim do ciclo de vida (End of Life) do Apache Spark, a comunidade Apache deixa de lançar correções de segurança para ela. Qualquer vulnerabilidade divulgada após essa data — seja na camada de comunicação do cluster do Spark, em sua interface de usuário web, em sua implementação de criptografia RPC, em sua integração com bibliotecas cliente do Hadoop ou em qualquer outra parte do mecanismo — não receberá um patch oficial para esse ramo. A única solução oferecida pela comunidade é a atualização para uma versão com suporte.

Para organizações que executam o Spark em ambientes de produção complexos, nos quais os pipelines foram criados com base em APIs específicas do Spark, onde os trabalhos do PySpark dependem de versões do ecossistema Python vinculadas a versões específicas do Spark e onde uma atualização do Spark exige alterações coordenadas em dezenas de trabalhos dependentes e configurações de infraestrutura, “simplesmente atualizar” não é uma opção em curto prazo. O intervalo entre o momento em que o status de fim de vida útil (End of Life) do Apache Spark entra em vigor e o momento em que uma migração pode ser realisticamente concluída e validada é exatamente o período durante o qual novas vulnerabilidades se acumulam sem que haja nenhuma correção disponível.

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 Apache Spark em fim de vida (EOL) são concretas. O Requisito 6.3.3 do PCI DSS exige que patches críticos e de alta gravidade sejam instalados no prazo de um mês após o lançamento; no entanto, em uma versão do Apache Spark em fim de vida, não há patches para instalar, tornando impossível a conformidade por meios normais. Os auditores do SOC 2 sinalizam o software em fim de vida (EOL) em ambientes de produção como uma deficiência de controle. Para organizações nas quais os clusters do Spark processam dados que se enquadram no escopo da HIPAA, do GDPR ou da regulamentação financeira, a ausência de patches de segurança na camada de processamento não é um risco teórico; é uma falha de conformidade ativa prestes a vir à tona.

As organizações nas quais o Spark é implantado dentro de um perímetro regulamentado de processamento de dados enfrentam as mesmas lacunas de documentação que aparecem em questionários de segurança, impedem a certificação de fornecedores e, em setores regulamentados, geram requisitos de correção que podem ter prazos curtos próprios.

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

O histórico de CVEs do Spark reforça por que o status de fim de vida útil (EOL) do Apache Spark, em uma estrutura executada dentro da infraestrutura de dados corporativa, não é algo que deva ser aceito passivamente.

CVE-2022-33891 (CVSS 8,8 – Alto) é a vulnerabilidade que ilustrou de forma mais concreta como funciona, na prática, a exposição do Spark sem patch. Quando as ACLs do Spark estão habilitadas, um caminho de código no HttpSecurityFilter permitia que um invasor passasse um nome de usuário arbitrário por meio de suplantação de identidade. O filtro, então, passava esse nome de usuário diretamente para um comando de shell do Unix usado para consultar a associação a grupos, criando uma vulnerabilidade de injeção cega de comando no sistema operacional. Um invasor com acesso à interface do usuário do Spark poderia executar comandos de shell arbitrários na qualidade do usuário que executava o processo do Spark. A CISA classificou essa vulnerabilidade como uma “Vulnerabilidade Explorada Conhecida”, colocando-a entre as vulnerabilidades mais ativamente exploradas rastreadas em todo o ecossistema de código aberto. A exploração ativa em ambiente real foi confirmada nos meses seguintes à divulgação. A vulnerabilidade afetou várias ramificações do Spark 3.0.x, 3.1.x e 3.2.x, todas as quais estão agora no fim da vida útil (EOL). Qualquer futuro CVE de gravidade comparável contra uma ramificação atualmente no fim da vida útil não terá correção oficial.

CVE-2023-22946 (CVSS 8,8 – Alto) demonstrou que a exposição grave não se limita às versões mais antigas do Spark. Essa vulnerabilidade de escalonamento de privilégios afetou todas as versões do Spark anteriores à 3.4.0, o que significa que afetou toda a base instalada do Spark 3.3.x e versões anteriores no momento da divulgação. Um usuário mal-intencionado poderia passar uma classe de configuração personalizada como argumento de linha de comando para o `spark-submit`, contornando as verificações de permissão do usuário proxy do Spark e obtendo a capacidade de escalar privilégios até o nível do usuário do Spark que está enviando o trabalho. Para organizações nas quais o Spark é implantado em ambientes de cluster multilocatário — uma configuração comum em plataformas de dados corporativas —, essa classe de vulnerabilidade tem impacto direto na integridade do modelo de controle de acesso aos dados.

Essas vulnerabilidades abrangem a camada web do mecanismo Spark e seu modelo de privilégios — exatamente a superfície de ataque que as organizações que operam infraestrutura de dados precisam manter protegida.

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

A superfície de vulnerabilidade de uma implantação do Spark em produção vai muito além dos próprios binários do mecanismo do Spark. O Spark é fornecido com um conjunto considerável de dependências, e cada componente dessa árvore possui seu próprio fluxo independente de CVEs.

O módulo Spark Core utiliza o Netty como dependência direta de tempo de execução para todas as comunicações RPC e de rede, e o Netty possui um histórico significativo de CVEs, incluindo vulnerabilidades que afetam a análise de solicitações HTTP, o tratamento de cabeçalhos e a implementação de SSL/TLS. O Jackson Databind está incluído para serialização JSON e gerou alguns dos fluxos de CVEs mais prolíficos entre todas as bibliotecas Java nos últimos anos, com dezenas de vulnerabilidades de desserialização divulgadas ao longo das principais versões. As bibliotecas cliente do Apache Hadoop — hadoop-common, hadoop-hdfs e hadoop-auth — são incluídas para integração com o HDFS e o YARN e trazem sua própria superfície de exposição à segurança. O Apache Parquet está incluído como o formato padrão de armazenamento colunar. O Apache Avro lida com a serialização baseada em esquema. As bibliotecas cliente do Apache ZooKeeper são incorporadas por meio do Hadoop para serviços de coordenação. Google Guava, Apache Commons IO, Apache Commons Lang, Apache Commons Crypto, Curator (a estrutura cliente do ZooKeeper), Protobuf e LZ4 são todas dependências de tempo de execução. Quando o Spark é implantado com a biblioteca de ML (MLlib), o Arrow é utilizado para a troca de dados em colunas entre a JVM e os processos Python.

Quando o Spark é integrado ao Kafka para Structured Streaming — um padrão comum em produção —, a biblioteca cliente do Kafka e suas dependências passam a fazer parte da pegada de software. O gráfico de dependências transitivas de uma implantação do Spark em produção com um conjunto típico de integração abrange bem mais de 100 artefatos.

Quando uma versão do Spark atinge o fim da vida útil (EOL) do Apache Spark, a comunidade deixa de emitir atualizações de segurança coordenadas para qualquer uma dessas dependências no contexto dessa versão do Spark. Os scanners de vulnerabilidades executados em implantações do Apache Spark em fim de vida útil geram uma lista crescente de resultados em toda a árvore de dependências para os quais não há correção disponível, deixando as equipes de segurança com resultados de varredura sem solução que se acumulam a cada novo ciclo de divulgação de CVEs.

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

As organizações que utilizam versões do Apache Spark cujo ciclo de vida chegou ao fim têm várias opções à disposição. Algumas exigem um esforço significativo de engenharia e prazos mais longos. O Suporte de Ciclo de Vida Ilimitado da TuxCare, por outro lado, elimina a lacuna de segurança imediatamente.

Opção 1: Atualizar para uma versão recente do Spark

A solução a longo prazo é atualizar para uma versão do Spark que receba suporte atualmente. As versões com manutenção ativa são o Spark 3.5 (LTS, com suporte até abril de 2026), o Spark 4.0 e o Spark 4.1, as versões principais mais recentes da linha 4.x.

Para organizações que utilizam o Spark 3.3.x ou 3.4.x, a atualização para a versão Spark 3.5 LTS é o caminho de menor complexidade dentro da geração 3.x, pois evita as mudanças compatibilidade-quebrantes introduzidas na versão principal do Spark 4.0. O Spark 3.5 mantém a compatibilidade da API com aplicativos da versão 3.x, ao mesmo tempo em que estende a cobertura de segurança até abril de 2026; após essa data, ele também atingirá o fim da vida útil (EOL) do Apache Spark, tornando o Spark 4.x o único destino com suporte de longo prazo.

A atualização para o Spark 4.0 ou 4.1 traz uma série de mudanças que quebram a compatibilidade retroativa e exigem um planejamento cuidadoso em todas as bases de código de engenharia de dados. O Spark 4.0 deixou de oferecer suporte ao Scala 2.12, o que afetou muitas organizações. Os aplicativos Spark escritos em Scala devem atualizar toda a sua base de código para o Scala 2.13 e recompilar todos os artefatos compilados em Scala. O suporte ao JDK 8 e ao JDK 11 foi removido; o Java 17 é agora a versão mínima de runtime, exigindo atualizações da JVM em todos os nós do cluster e em quaisquer sistemas que executem tarefas do Spark. O modo ANSI SQL está habilitado por padrão no Spark 4.0. Pipelines que dependiam do comportamento de tratamento de nulos compatível com o Hive, da coerção silenciosa de tipos ou da semântica permissiva de estouro lançarão exceções em tempo de execução, em vez de retornar silenciosamente valores nulos ou valores encapsulados, o que pode corromper conjuntos de resultados a jusante ou a lógica do pipeline sem mensagens de erro evidentes. Versões do Hive Metastore anteriores à 2.0 não são mais suportadas, pois exigem o JDK 8.

Para organizações com um investimento significativo no Spark — o que se aplica à maioria das organizações para as quais a questão da atualização é relevante —, uma migração para o Spark 4.x, devidamente planejada e testada, leva meses, e não semanas.

Opção 2: Migrar para uma estrutura de processamento diferente

Algumas organizações encaram o fim do ciclo de vida do Apache Spark como um gatilho para avaliar tecnologias alternativas de processamento de dados: o Apache Flink para processamento de fluxos com estado, o Trino ou o Apache Hive para análises SQL, o Dask ou o Ray para computação distribuída nativa do Python, ou serviços gerenciados nativos da nuvem que abstraem totalmente o mecanismo.

Você também pode saber mais sobre o fim da vida útil (EOL) do Apache Hive em nosso guia detalhado, caso esteja avaliando o Hive como uma estrutura-alvo.

O argumento arquitetônico tem mérito em contextos específicos, especialmente quando modelos de execução sem servidor (serverless) nativos da nuvem eliminariam a sobrecarga operacional do gerenciamento de clusters do Spark, ou quando o padrão de carga de trabalho é melhor atendido por uma arquitetura que prioriza o processamento de fluxos (stream-first). No entanto, uma migração completa da estrutura é substancialmente mais cara do que uma atualização da versão do Spark. As consultas do Spark SQL, as transformações do PySpark, os pipelines do MLlib, as topologias do Structured Streaming e toda a infraestrutura de ferramentas, orquestração e monitoramento construída em torno do Spark exigem substituição ou reformulação fundamental. Trata-se de uma decisão estratégica de infraestrutura que merece um cronograma próprio e cuidadosamente planejado, e não uma imposta pela data de fim de vida útil (EOL) do Apache Spark.

Opção 3: Proteja seus sistemas agora com o Suporte de Ciclo de Vida Estendido da TuxCare

O Suporte de Ciclo de Vida Ilimitado da TuxCare é a opção que resolve o problema imediato sem criar novos problemas. Você continua executando sua versão atual do Spark enquanto recebe cobertura contínua de patches de segurança para a estrutura e sua árvore de dependências, fornecida por meio de seus fluxos de trabalho existentes do Maven, Gradle ou pip, sem a necessidade de atualizações forçadas e sem alterações na forma como sua infraestrutura opera.

A lacuna de segurança é sanada imediatamente. Sua postura de conformidade é mantida. Suas equipes ficam livres para planejar a atualização adequada em um cronograma que faça sentido do ponto de vista operacional, incluindo o prazo adicional necessário para reescrever o código do Scala 2.12 para o Scala 2.13, validar o comportamento do pipeline sob a configuração padrão do ANSI SQL, atualizar os ambientes de execução do Java em todo o cluster e realizar testes de regressão em todo o conjunto de tarefas de produção. Sem migração forçada sob pressão de prazos, sem emergências de conformidade, sem regressões silenciosas na qualidade dos dados nos pipelines de produção que alimentam sistemas financeiros ou operacionais a jusante.

Os riscos de apressar uma atualização do Spark

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

O que uma atualização do Spark realmente envolve

Uma atualização adequada do Spark, especialmente da versão 3.3.x ou 3.4.x para a 4.x, é um projeto de plataforma de dados em várias fases, e não apenas uma atualização de versão em um arquivo de dependências. Isso requer a auditoria de toda a base de código em busca de APIs obsoletas e recursos removidos, a atualização do runtime Java em todos os nós do cluster caso a versão atual esteja abaixo do mínimo exigido pelo Spark 4.x, a atualização das versões do Scala e a recompilação de todos os artefatos compilados em Scala, além da validação de todas as configurações do cluster, integrações do gerenciador de recursos e descritores de implantação em relação à nova versão.

Adaptação de código: Para aplicativos Spark baseados em Scala, todos os artefatos compilados para Scala 2.12 devem ser recompilados para Scala 2.13. As alterações no modo ANSI SQL exigem uma revisão sistemática de todas as consultas Spark SQL, transformações de DataFrame e UDFs para identificar a lógica que dependia do comportamento de estouro com retorno nulo, coerção de tipos permissiva ou casos extremos compatíveis com o Hive no tratamento de datas e carimbos de data/hora. Em grandes pipelines com centenas de expressões SQL, essa auditoria representa uma tarefa de engenharia substancial.

Verificação de compatibilidade: Os trabalhos do PySpark devem ser validados em relação à nova API de fonte de dados do Python e verificados quanto à compatibilidade com quaisquer alterações de comportamento específicas do PySpark na versão 4.x. Qualquer aplicação do Spark que se integre a um Hive Metastore deve verificar se a versão do metastore atende ao requisito mínimo do Spark 4.0, que é o Hive 2.0 ou posterior. Os trabalhos que utilizam o Delta Lake, o Apache Iceberg ou outras integrações de formato de tabela devem confirmar se essas integrações publicam versões compatíveis com o Spark 4.x.

Adaptação da cadeia de ferramentas: Sistemas de compilação, pipelines de CI/CD, imagens de contêiner, scripts de inicialização de cluster e configurações de orquestração que fazem referência a strings de versão específicas do Spark, entradas no classpath ou sinalizadores de inicialização precisam ser revisados e atualizados. A estrutura de registro de logs do Spark sofreu alterações na versão 4.0, o que afeta a infraestrutura de análise de logs e as ferramentas de observabilidade.

Carga de testes: Os testes de ponta a ponta em todo o inventário de tarefas de produção, abrangendo pipelines ETL em lote, tarefas de Structured Streaming, fluxos de trabalho de treinamento de ML e cargas de trabalho SQL interativas, não podem ser abreviados. Mudanças comportamentais no ANSI SQL, em particular, produzem diferenças sutis na saída que podem não gerar erros, mas alterarão silenciosamente os resultados de maneiras que só se manifestam sob distribuições específicas de dados ou entradas em casos extremos. A validação da fidelidade da saída dos pipelines em todo o conjunto de tarefas, com volumes de dados realistas, antes da implantação em produção, não é opcional para organizações nas quais os consumidores a jusante dependem da exatidão dos dados processados.

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

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

Aumento da carga de suporte: Alterações não validadas no ANSI SQL geram exceções inesperadas em tempo de execução em tarefas de produção. As incompatibilidades entre o Scala 2.12 e 2.13 se manifestam como conflitos no classpath ou erros do tipo “método não encontrado”, que são difíceis de diagnosticar sem um conhecimento aprofundado das bibliotecas afetadas. Isso gera uma onda de incidentes que as equipes de engenharia de dados e de operações de plataforma precisam absorver além das cargas de trabalho normais.

Instabilidade do sistema: Os pipelines do Spark geralmente alimentam painéis de controle, sistemas de risco, modelos de fraude e produtos de dados voltados para o cliente, nos quais regressões comportamentais afetam imediatamente as operações comerciais em tempo real. Mudanças sutis na semântica do SQL, no comportamento de coerção de tipos ou no tratamento de carimbos de data e hora que não foram detectadas nos testes geram problemas de qualidade de dados que costumam ser difíceis de detectar e ainda mais difíceis de atribuir à atualização do Spark.

Acúmulo de dívida técnica: Soluções provisórias implementadas sob pressão de tempo tornam-se permanentes. Consultas SQL corrigidas com conversões explícitas de tipo para evitar exceções ANSI, sem a compreensão da mudança semântica subjacente, introduzem riscos próprios à qualidade dos dados. O problema do fim da vida útil do Apache Spark é adiado, não resolvido.

Custos não planejados: Horas extras de engenharia de emergência, atrasos no lançamento de produtos de dados, despesas indiretas com resposta a incidentes e o custo de oportunidade de engenheiros de dados sênior dedicando-se à depuração de falhas no pipeline de produção, em vez de desenvolver novos recursos, somam-se rapidamente. Uma atualização apressada que gera semanas de incidentes de produção custa muito mais do que o suporte estendido que teria possibilitado um plano de migração bem planejado.

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

A TuxCare oferece suporte contínuo ao ciclo de vida para versões do Apache Spark que chegaram ao fim da vida útil. Em vez de forçar uma atualização para a qual suas equipes ainda não estão preparadas, você continua operando sua implantação atual do Spark com cobertura contínua de patches de segurança, fornecida por meio de seus fluxos de trabalho existentes do Maven, Gradle ou pip, sem alterações na forma como sua infraestrutura funciona.

A TuxCare vem fazendo isso há mais de uma década em sistemas operacionais, ambientes de execução, bibliotecas e estruturas de aplicativos. 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 a segurança de softwares em fim de vida útil (EOL) em escala empresarial, isso não é apenas discurso de marketing; é um histórico operacional comprovado.

Para obter mais detalhes sobre como gerenciar outras estruturas legadas de serviços web em Java que estão chegando ao fim da vida útil, você também pode conferir nossa análise sobre o fim da vida útil do Apache CXF para ver como o suporte estendido se aplica à sua pilha de tecnologias.

Cobertura completa da árvore de dependências: O ELS para Spark da TuxCare abrange a estrutura e suas dependências diretas e transitivas, incluindo Netty, Jackson Databind, bibliotecas de clientes Hadoop, Apache Parquet, Apache Avro, Guava, bibliotecas de clientes ZooKeeper, Commons IO e outras, 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 de nível superior do Spark.

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 Spark 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: Independentemente de você atualmente utilizar o Spark via Maven, Gradle ou pip, é possível mudar sua fonte de atualização 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 de engenharia de dados operam. 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 Spark que chegaram ao fim da vida útil, seja no próprio mecanismo ou em qualquer ponto da árvore de dependências, a TuxCare fornece patches dentro de um prazo garantido, respaldado por acordos de nível de serviço. Vulnerabilidades críticas e de alta gravidade (CVSS 7+) são corrigidas em até 14 dias após a divulgação pública. Você não fica esperando por um backport da comunidade que talvez nunca chegue para um ramo do Spark 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 uma atualização de emergência (realizada às pressas devido a um prazo de conformidade iminente) custa em termos de tempo de engenharia, risco operacional, resposta a incidentes e atrasos no plano de desenvolvimento. Cobertura de segurança previsível, um cronograma de atualizações 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 Apache Spark que chegaram ao fim da vida útil (EOL), a TuxCare mantém um rastreador CVE em tempo real para o Apache Spark.

Não deixe que o fim do ciclo de vida do Apache Spark coloque seus pipelines de dados em risco

O fim do ciclo de vida do Apache Spark não significa que seus pipelines fiquem imediatamente comprometidos, nem que você precise realizar uma atualização de emergência para a qual suas equipes não estejam preparadas. No entanto, o status de fim de vida útil do Apache Spark significa que a cobertura de segurança da qual sua infraestrutura de processamento de dados dependia não existe mais, e a inclusão do CVE-2022-33891 no catálogo de Vulnerabilidades Exploradas Conhecidas da CISA comprovou que as vulnerabilidades do Spark atraem explorações no mundo real, e não apenas interesse teórico.

As organizações que lidam bem com isso são aquelas que tratam o status de fim de vida útil do Apache Spark como um problema de segurança a ser gerenciado, e não como um prazo ao qual se deve reagir sob pressão. Você pode planejar uma atualização deliberada para o Spark 3.5, 4.0 ou 4.1 quando isso realmente se encaixar na capacidade da sua equipe, incluindo o tempo necessário para validar as mudanças de comportamento do ANSI SQL em todo o seu inventário de tarefas, atualizar as versões do Scala em toda a sua base de código e realizar testes de regressão nos pipelines de produção com volumes de dados realistas. Você pode avaliar se uma migração mais ampla da plataforma atende a um objetivo arquitetônico real. Ou pode usar o TuxCare ELS para manter segurança e conformidade total enquanto toma essas decisões no seu próprio cronograma, e não no de um auditor de conformidade.

O suporte estendido não é uma solução provisória. É a opção que mantém suas implantações do Spark seguras, sua conformidade intacta e suas equipes de engenharia de dados focadas no desenvolvimento, e não em resolver problemas urgentes. Se o fim da vida útil (EOL) do Apache Spark estiver em seu radar de segurança no 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 dados pelo tempo que você precisar.

Resumo

Nome do artigo

Fim da vida útil do Apache Spark: riscos, falhas de segurança e o que fazer a seguir

Descrição

Está executando o Apache Spark em produção? Mantenha a segurança e a conformidade sem precisar fazer uma migração forçada. O TuxCare ELS amplia a cobertura de segurança além do fim da vida útil (EOL)

Autor

Artem Karasev

Nome da editora

TuxCare

Logotipo da editora