Como manter a segurança após o Django chegar ao fim de sua vida útil

Principais conclusões

• O fim do suporte (EOL) do Django deixa você vulnerável a vulnerabilidades (CVEs) sem correção, não apenas no Django, mas também em dependências como o sqlparse, o que pode comprometer a conformidade com as normas PCI DSS, HIPAA e SOC 2.
• A migração direta do Django 3.2 ou 4.2 para a versão 5.2 exige uma atualização do ambiente de execução do Python e traz à tona mudanças que causam incompatibilidade, por isso requer um planejamento cuidadoso, em vez de uma corrida contra o prazo para adequação.
• O TuxCare ELS para Django mantém sua versão em fim de vida atualizada com patches e em conformidade enquanto você realiza a migração de acordo com seu próprio cronograma.

Se a sua pilha de aplicativos em Python inclui o Django para desenvolvimento web — e é bem provável que seja o caso —, vale a pena entender o fim do ciclo de vida (EOL) do Django antes que um verificador de segurança ou uma auditoria de conformidade force essa discussão.

Há quase duas décadas, o Django tem sido uma das estruturas padrão para a criação de aplicativos web em Python. Seu modelo “baterias incluídas” reúne o ORM, a autenticação, a interface administrativa, o gerenciamento de formulários, o middleware de segurança e outros recursos essenciais de aplicativos web em uma única estrutura, e é exatamente por isso que tantas equipes corporativas ainda confiam nele em ambiente de produção. Mas essa estabilidade de longo prazo também gera riscos relacionados ao ciclo de vida. O Django 3.2 LTS chegou ao fim de vida útil em abril de 2024, o Django 4.2 LTS chegou ao fim de vida útil em abril de 2026, e versões não LTS, como 4.0, 4.1, 5.0 e 5.1, já não têm suporte. Para todas elas, os patches de segurança do desenvolvedor original foram interrompidos.

Este artigo explica o que significa, na prática, o fim do suporte (EOL) do Django, por que os registros de vulnerabilidades tornam essa exposição uma realidade e como o TuxCare ELS para Django ajuda as organizações a manterem seus sistemas atualizados e em conformidade, sem forçá-las a realizar uma migração apressada antes que suas equipes estejam preparadas.

O que é o Django e por que ele ainda é tão amplamente utilizado?

O Django é um framework web de alto nível em Python, mantido pela Django Software Foundation. Sua arquitetura modelo-visão-modelo (MVT) separa a lógica de negócios, o acesso aos dados e a apresentação, permitindo que as equipes criem aplicativos web fáceis de manter sem precisar reimplementar a infraestrutura necessária a qualquer aplicativo web. O framework vem com um ORM integrado, um sistema de migração, um backend de autenticação, uma interface administrativa, validação de formulários, proteção contra falsificação de solicitações entre sites (CSRF) e middleware de segurança — uma pilha abrangente que tornou o Django o framework web padrão em Python para organizações que priorizam confiabilidade e completude.

A adoção do Django está profundamente enraizada nas pilhas de Python corporativas. Ele sustenta plataformas de gerenciamento de conteúdo, portais de serviços financeiros, sistemas governamentais e back-ends de comércio eletrônico em diversos setores que vêm utilizando Python há uma década ou mais. A mesma estabilidade e abrangência que tornaram o Django atraente também contribuem para sua persistência em produção: aplicativos desenvolvidos com uma versão bem conhecida do Django raramente são considerados candidatos a atualização, a menos que um verificador de CVE ou uma auditoria de conformidade crie essa necessidade. Essa é exatamente a armadilha do fim de vida útil (EOL) do Django.

O que é o ciclo de vida do produto Django?

O Django utiliza um ciclo de lançamento previsível e baseado em prazos. Os lançamentos com novas funcionalidades ocorrem aproximadamente a cada oito meses. Cada versão recebe correções de segurança por um total de dezesseis meses: oito meses de suporte completo, seguidos por oito meses de manutenção voltada exclusivamente à segurança. A exceção é a designação de Suporte de Longo Prazo (LTS): a versão final de cada ramificação de versão principal recebe três anos completos de suporte de segurança. Entender quais versões possuem o status LTS é essencial para avaliar com precisão o risco de fim de vida útil (EOL) do Django em toda a sua pilha de tecnologia, já que as versões não LTS chegam ao fim de vida útil muito mais rapidamente do que as equipes normalmente esperam.

O Django 4.2 LTS, a versão anterior com suporte de longo prazo, chegou ao fim de vida útil em 7 de abril de 2026. O Django 3.2 LTS chegou ao fim de vida útil em abril de 2024. As versões não LTS entre elas (4.0, 4.1, 5.0, 5.1) chegaram ao fim do ciclo de vida antes, e várias delas estão sem patches do desenvolvedor original há anos. Qualquer organização que ainda esteja executando qualquer uma dessas versões está operando um software para o qual a Django Software Foundation não emitirá correções, independentemente do que venha a ser descoberto.

O fim da vida útil (EOL) do Django é incondicional. O projeto Django não oferece suporte comercial estendido, modos de manutenção voltados exclusivamente para segurança nem retroportagem de patches para versões anteriores. Quando uma versão do Django chega ao fim de vida, o suporte do desenvolvedor original cessa totalmente, e é exatamente essa lacuna que o ELS da TuxCare para Django foi criado para preencher. Isso significa que cada CVE divulgado após a data de fim de vida representa uma vulnerabilidade permanente sem correção, a menos que um fornecedor como a TuxCare esteja realizando a retroportagem de correções.

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

O fim do ciclo de vida (EOL) do Django não significa que as vulnerabilidades deixem de ser descobertas nas versões em fim de vida; significa que elas deixam de ser corrigidas. O ORM do Django é expressivo e poderoso, o que também significa que falhas na forma como ele lida com entradas fornecidas pelo usuário podem se traduzir diretamente em injeção de SQL. Os dois CVEs abaixo estão confirmados no NVD e definem a principal exposição direta à segurança que o EOL do Django cria para organizações que executam versões sem suporte em produção. Você pode acompanhar o status dos CVEs que afetam as versões do Django em EOL e as correções disponíveis por meio do Rastreador de CVEs da TuxCare.

CVE-2022-28346: Injeção de SQL em aliases de colunas do QuerySet

CVE-2022-28346 (NVD CVSS 3.1: 9,8 – Crítica) é uma vulnerabilidade de injeção de SQL no ORM do Django que afeta os métodos QuerySet.annotate(), aggregate() e extra(). Quando os aliases de colunas são definidos por meio da expansão de dicionário, passando-se um dicionário malicioso como **kwargs, o Django não valida nem escapa adequadamente os valores dos aliases de coluna antes de interpolá-los na consulta SQL gerada. Um invasor capaz de influenciar o conteúdo do dicionário pode injetar SQL arbitrário na parte da consulta referente aos aliases de coluna, contornando as proteções normais do Django contra consultas parametrizadas.

A vulnerabilidade CVE-2022-28346 foi divulgada em 11 de abril de 2022, com correções lançadas para as versões 2.2.28, 3.2.13 e 4.0.4 do Django. As organizações que utilizavam versões cujo ciclo de vida já havia terminado na data da divulgação não receberam nenhuma correção do desenvolvedor original. A vulnerabilidade possui uma prova de conceito disponível publicamente e continua sendo uma falha concreta e explorável em qualquer instalação do Django sem patch.

CVE-2024-42005: Injeção de SQL por meio do JSONField no método QuerySet.values()

CVE-2024-42005 (CVSS 3.1: 9,8 – Crítico, conforme o comunicado de segurança do Django) é uma vulnerabilidade de injeção de SQL no ORM do Django que afeta os métodos QuerySet.values() e values_list() em modelos que incluem um JSONField. Ao criar chaves específicas de objetos JSON e passá-las como parâmetros *arg para esses métodos, um invasor pode fazer com que o Django utilize a chave maliciosa como um alias de coluna sem a devida sanitização, injetando SQL arbitrário na consulta gerada. O ataque é baseado em rede, não requer autenticação e apresenta baixa complexidade.

A vulnerabilidade CVE-2024-42005 foi divulgada em 6 de agosto de 2024, com correções lançadas para o Django 4.2.15 e 5.0.8. O Django 3.2 LTS já havia ultrapassado sua data de fim de vida útil (EOL), em abril de 2024, no momento da divulgação, e o Django 4.0 e 4.1 estavam em EOL desde abril de 2023 e dezembro de 2023, respectivamente. O Django não testou nem corrigiu essas versões em EOL. As organizações que utilizam essas versões do Django fora do ciclo de vida estão expostas a essa vulnerabilidade crítica de injeção de SQL com pontuação CVSS 9,8, sem que haja um caminho oficial de correção por parte do projeto Django.

O risco de dependência: sqlparse

O Django requer duas dependências diretas de tempo de execução: asgiref e sqlparse. O sqlparse contém CVE-2024-4340 (CVSS 7,5 – Alta), uma vulnerabilidade de negação de serviço acionada quando o sqlparse.parse() processa uma lista profundamente aninhada, causando um RecursionError que trava o analisador. A correção foi lançada na versão 0.5.0 do sqlparse. Organizações que utilizam versões mais antigas do Django, já fora de suporte (EOL), também podem estar limitadas a versões do sqlparse anteriores a essa correção, ampliando a área de exposição coberta pelo TuxCare ELS para Django.

Conformidade e Risco Regulatório

O requisito 6.3.3 do PCI DSS determina que as vulnerabilidades com pontuação CVSS 7.0+ sejam corrigidas no prazo de um mês a partir da divulgação pública. A vulnerabilidade CVE-2022-28346, com pontuação CVSS 9.8, está pública desde abril de 2022, e a vulnerabilidade CVE-2024-42005, com pontuação CVSS 9.8, está pública desde agosto de 2024. Organizações que utilizam versões do Django em fim de vida útil (EOL) sem um plano de aplicação de patches estão, em alguns casos, em situação de não conformidade com esses prazos de correção há anos. A utilização de componentes de framework web com vulnerabilidades conhecidas e sem patches em aplicativos que lidam com Informações de Saúde Protegidas (PHI) não atende aos requisitos da Regra de Segurança da HIPAA para proteção contra ameaças razoavelmente previsíveis. Auditores SOC 2 Tipo II sinalizam versões de bibliotecas sem suporte como falhas de controle. O ELS para Django é a forma como as organizações cumprem essas obrigações de conformidade enquanto a migração é planejada e executada de acordo com seu próprio cronograma.

Os riscos de apressar uma migração no Django

A pressão para responder às constatações relacionadas ao fim da vida útil (EOL) do Django é real. As ferramentas de análise de composição de software geram constatações. Os auditores de segurança fazem perguntas diretas. Os prazos de conformidade não são adiados por causa de limitações de capacidade da equipe de engenharia. As equipes que lidam bem com o fim da vida útil do Django são aquelas que compreendem a diferença entre responder aos riscos e criar novos riscos por agir precipitadamente.

O que acontece quando você faz tudo com pressa

Quando as equipes comprimem a migração do Django em um cronograma irrealista por estarem sob pressão devido a questões de conformidade ou a problemas de segurança, as coisas tendem a dar errado de maneiras previsíveis:

Aumento da carga de suporte: Cada versão principal do Django remove recursos obsoletos que podem ter se acumulado silenciosamente nas bases de código ao longo dos anos. Quando os avisos de obsolescência foram ignorados, as remoções se tornaram alterações que causam quebra de compatibilidade, que só vêm à tona após a implantação. As equipes de suporte ficam imediatamente sobrecarregadas com tickets sobre visualizações com falhas, envios de formulários com erros e erros de consulta ORM que não foram detectados nos testes intensivos.

Instabilidade do sistema: O comportamento do ORM do Django sofre alterações sutis entre as versões principais, que nem sempre são detectadas nos testes unitários. Resultados de consultas que mudam devido a diferenças de ordenação, comportamento de agregação ou tratamento de campos JSON podem introduzir bugs na camada de dados que só se manifestam sob carga de produção ou com padrões específicos de dados — o tipo de bug que é difícil de reproduzir e caro de diagnosticar.

Acúmulo de dívida técnica: Na pressa para se adequarem às normas, as equipes tomam atalhos. Padrões obsoletos que deveriam ter sido refatorados são remendados com soluções provisórias de compatibilidade. Configurações cujo comportamento mudou entre versões são substituídas de maneiras que não estão documentadas. O problema do fim da vida útil (EOL) do Django é adiado por essas soluções provisórias, e não resolvido, e a dívida acumulada torna uma migração adequada mais onerosa posteriormente.

Custos não planejados: Horas extras de engenharia de emergência, atrasos no lançamento de recursos e o custo de oportunidade de seus melhores engenheiros dedicarem-se à depuração de problemas de compatibilidade de migração, em vez de desenvolver novos recursos, somam-se rapidamente, geralmente atingindo um valor que excede o que os serviços de suporte estendido teriam custado durante todo o período de planejamento da migração.

Pré-requisito de versão do Python

A migração para o Django 5.2 LTS requer o Python 3.10 ou superior. As organizações que utilizam o Django 3.2 podem estar usando o Python 3.6, 3.7 ou 3.8, versões que, por sua vez, já ultrapassaram suas datas de fim de vida útil definidas pelo desenvolvedor original. Organizações que utilizam o Django 4.2 podem estar usando o Python 3.8 ou 3.9. Isso significa que, para muitas organizações, a correção completa do fim de vida útil (EOL) do Django envolve uma migração sequencial tanto do ambiente de execução do Python quanto do framework Django, com toda a verificação de compatibilidade de dependências que isso implica. As equipes que definem a migração como uma simples “atualização do Django” e só descobrem o pré-requisito do Python no meio do projeto são as que enfrentam os maiores atrasos inesperados no cronograma.

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

As organizações que utilizam versões do Django em fim de vida (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 resolve o problema imediatamente, enquanto suas equipes planejam a migração de forma adequada.

Opção 1: Migrar para o Django 5.2 LTS

A solução de longo prazo é migrar para o Django 5.2 LTS, a versão atual com suporte de longo prazo (LTS), que conta com cobertura de segurança ativa do desenvolvedor original até abril de 2028. Isso elimina o risco de fim de vida útil (EOL) do Django, ao migrar para um software mantido ativamente pelo desenvolvedor original. A migração envolve um escopo de engenharia significativo. O Django 5.2 requer Python 3.10 ou superior; portanto, as organizações que utilizam versões mais antigas do Python devem atualizar seu ambiente de execução antes de iniciar a migração para o Django. Além do pré-requisito do runtime, cada versão principal entre a sua versão atual e a 5.2 remove recursos que foram descontinuados em versões anteriores. Para uma equipe que está migrando da versão 3.2 para a 5.2, isso significa três gerações de remoções a serem consideradas. Aplicativos com middleware personalizado, back-ends de modelos personalizados ou uso não trivial de ORM devem planejar essa migração em trimestres, e não em semanas.

Opção 2: Substituir o Django por um framework alternativo

Algumas organizações consideram o fim do suporte (EOL) do Django como o gatilho para avaliar alternativas. FastAPI, Flask e Starlette são frameworks web em Python mantidos ativamente, com diferentes modelos arquitetônicos. Se os requisitos de uma aplicação tiverem evoluído no sentido de microsserviços ou de um design “API-first”, uma mudança de framework pode se alinhar aos objetivos arquitetônicos. Uma migração completa de framework é mais disruptiva do que uma atualização dentro do mesmo framework; cada visualização, formulário, chamada ORM e middleware precisa ser reimplementado no modelo do novo framework. Nem a substituição do framework nem uma atualização padrão são soluções rápidas para uma constatação imediata de não conformidade com o fim da vida útil do Django. Ambas são caminhos viáveis a longo prazo para equipes com capacidade de executá-las com cuidado.

Opção 3: Suporte contínuo ao longo do ciclo de vida pela TuxCare (a opção recomendada)

O Suporte de Ciclo de Vida Ilimitado da TuxCare para Django é a opção que permite que você se mantenha seguro sem precisar realizar uma migração para a qual sua equipe ainda não está preparada. Em vez de forçar uma atualização disruptiva em toda a sua aplicação Django e suas dependências, você continua executando sua versão atual do Django com cobertura contínua de patches de segurança, fornecidos como atualizações de pacotes prontas para uso por meio do seu fluxo de trabalho pip existente. É para isso que o ELS para Django foi projetado: para preencher a lacuna entre o momento em que o suporte oficial termina e o momento em que sua organização tiver realmente concluído uma migração planejada e controlada, de acordo com seu próprio cronograma.

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

A TuxCare oferece suporte contínuo ao ciclo de vida para versões do Django que chegaram ao fim do suporte, garantindo que sua implantação atual do Django continue protegida com patches de segurança fornecidos por meio do seu fluxo de trabalho do pip já existente. A TuxCare já distribuiu mais de 220.000 patches de segurança em todo o ecossistema de código aberto.

Cobertura completa da árvore de dependências: O TuxCare ELS para Django abrange não apenas o próprio pacote Django, mas toda a sua pegada de dependências em tempo de execução, incluindo o sqlparse e sua exposição conhecida a CVEs (CVE-2024-4340, CVSS 7,5 – Alto). 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 sem custo adicional.

Processo refinado e automatizado de aplicação de patches: A TuxCare monitora o NVD, os alertas de segurança do Django, os feeds de segurança do GitHub e os canais de divulgação dos fornecedores — todas as fontes nas quais vulnerabilidades do Django 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 “Processo de aplicação de patches de código aberto da TuxCare” .

Integração perfeita: Quer você atualmente instale o Django diretamente via pip ou por meio de um espelho de pacotes privado, é 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 CI/CD, nem em seu processo de implantação, nem na forma como suas equipes trabalham. Os pacotes corrigidos do Django são substitutos diretos, com a mesma API, a mesma configuração e o mesmo comportamento em tempo de execução, com correções de segurança retrocompatíveis.

Resposta rápida respaldada por SLA: Quando novas vulnerabilidades que afetam versões do Django em fim de vida útil (EOL) são divulgadas — seja no próprio Django, no sqlparse ou no asgiref —, a TuxCare fornece patches respaldados por acordos de nível de serviço. Vulnerabilidades de gravidade alta e crítica (CVSS 7.0 e acima) são corrigidas no prazo de 14 dias após a divulgação pública.

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 emergência quando imposta por um prazo de conformidade. Você planeja uma migração deliberada para o Django 5.2 LTS quando isso se encaixa na capacidade da sua equipe, incluindo tempo para resolver os pré-requisitos de tempo de execução do Python, verificar a compatibilidade de pacotes de terceiros e validar o comportamento em todos os caminhos da aplicação. Ou você usa o ELS para manter segurança e conformidade totais enquanto toma essas decisões de acordo com o seu cronograma, e não com o de um auditor de conformidade.

Não deixe que o fim do suporte ao Django coloque suas aplicações em risco

O fato de o Django ter atingido o fim de vida útil (EOL) não significa que sua aplicação esteja automaticamente comprometida. Significa que, se uma vulnerabilidade crítica afetar a versão que você está executando, o projeto Django não fornecerá uma correção para você. Cada novo CVE divulgado após o fim de vida útil amplia o período de exposição — e, sem uma correção retroativa, esse período permanece aberto.

A resposta correta depende do cronograma, da tolerância ao risco e da capacidade de engenharia da sua organização. Se você puder migrar para o Django 5.2 LTS agora — incluindo qualquer atualização necessária do ambiente de execução do Python —, esse é o melhor caminho a longo prazo. Mas se o seu aplicativo Django for complexo demais para ser migrado com segurança sob pressão, o TuxCare ELS para Django oferece cobertura de segurança contínua enquanto sua equipe planeja e executa a atualização de maneira adequada.

Se o fim do suporte (EOL) do Django está em sua agenda de segurança no momento, acesse Suporte de Ciclo de Vida Ilimitado para o Django para ver como o suporte estendido pode proteger suas aplicações em Python, ou explore a oferta completa da TuxCare Suporte de Ciclo de Vida Ilimitado para Software de Código Aberto da TuxCare para cobrir toda a sua pilha de código aberto.

Resumo

Nome do artigo

ELS para Django: Mantenha a segurança após o fim do suporte (EOL) com a TuxCare

Descrição

Está usando uma versão do Django em fim de vida (EOL)? O TuxCare ELS para Django mantém suas aplicações em Python atualizadas e em conformidade, sem a necessidade de uma migração apressada.

Autor

Muzzammil Hasann

Nome da editora

TuxCare

Logotipo da editora