O que para de receber correção: o calendário de EOL que importa

Software fora de suporte não avisa. Ele continua subindo, respondendo requisição e processando pedido exatamente como antes. A única coisa que muda é invisível: as falhas descobertas a partir daquela data não são mais corrigidas.

É o que torna o fim de suporte perigoso de um jeito peculiar. Disco cheio derruba o serviço e alguém age. EOL não derruba nada — ele apenas acumula exposição em silêncio, até virar o achado de uma auditoria ou a porta de entrada de um incidente.

O que "fim de suporte" significa de fato

Vale separar três estágios, porque tratá-los como um só leva a decisões erradas:

A fase "só segurança" é a mais confortável e a mais traiçoeira. Tudo funciona, as correções continuam chegando, e a sensação é de que está tudo bem — enquanto o prazo real corre. É nessa fase que a atualização deve ser planejada, com calma, e não na seguinte.

Existe também suporte estendido pago, oferecido por vários fornecedores. É uma saída válida para ganhar tempo quando a migração não cabe no trimestre, desde que seja decisão consciente com data de fim — e não uma assinatura que se renova para sempre.

O que já venceu

Se algum destes está na sua infraestrutura, ele não recebe mais correção de segurança pelo canal padrão:

• CentOS 7 e CentOS 8. O caso mais conhecido. Se você ainda opera essas máquinas, o guia de migração compara AlmaLinux, Rocky, Stream e a saída da família RHEL.
• Ubuntu 20.04 LTS. Saiu do suporte padrão; segue coberto apenas por assinatura de manutenção estendida.
• Node.js 18 e anteriores. Fora do ciclo de LTS.
• PHP 8.1 e anteriores. Sem correção de segurança.
• Python 3.8 e 3.9. Encerrados.
• PostgreSQL 13 e anteriores. Fora do ciclo de cinco anos.
• MySQL 5.7. Encerrado há bastante tempo, e ainda muito presente.

Essa lista não é exaustiva e as datas mudam com anúncios dos mantenedores. Trate-a como ponto de partida e confirme cada item na fonte oficial do projeto antes de montar cronograma.

O que exige planejamento agora

O grupo que ainda funciona e tem prazo curto o suficiente para entrar no planejamento do próximo trimestre:

• Debian 11. Já em janela de manutenção estendida pela equipe de LTS.
• Ubuntu 22.04 LTS. Suporte padrão até 2027 — parece longe, e não é para quem tem dezenas de máquinas.
• Node.js 20. Saindo do ciclo de manutenção.
• PHP 8.2. Entrando na fase de só segurança.
• PostgreSQL 14. Em contagem regressiva dentro do ciclo de cinco anos.
• MySQL 8.0. A migração para a linha seguinte não é trivial e merece tempo.

Bancos merecem atenção especial. Atualizar linguagem costuma ser questão de testar e reimplantar. Atualizar banco envolve dump, restauração, verificação de compatibilidade e uma janela de indisponibilidade que precisa ser negociada — é projeto, não tarefa.

Como saber o que você tem

Ninguém consegue planejar o que não enxerga, e o inventário quase sempre revela algo esquecido:

# Distribuição e tempo de vida
cat /etc/os-release
hostnamectl | grep -i 'operating system'

# Versões das linguagens e bancos presentes
php -v 2>/dev/null | head -1
node -v 2>/dev/null
python3 -V
psql --version 2>/dev/null
mysql --version 2>/dev/null

Em Debian e Ubuntu, dá para ver quantos pacotes já dependem de manutenção estendida:

sudo apt update
apt list --upgradable 2>/dev/null | grep -i security | wc -l

E para quem usa contêiner, a imagem base é o ponto cego mais comum — uma aplicação atualizada rodando sobre uma base de três anos atrás:

docker image ls --format '{{.Repository}}:{{.Tag}} {{.CreatedSince}}'

Uma imagem node:18-alpine continua disponível para download muito depois do fim do suporte. Estar no registro não significa estar mantida.

Montar o plano sem virar emergência

A atualização feita com pressa é a que quebra produção. O roteiro que funciona tem quatro passos e nenhum atalho:

Priorize por exposição. Um servidor web na internet com PHP fora de suporte é urgente. Um serviço interno, sem porta pública, com o mesmo PHP, é importante e não urgente. Comece pelo que a internet alcança.

Suba o novo ao lado do antigo. Atualizar no lugar é o caminho mais arriscado. Criar uma VM com a versão nova, implantar, testar e só então redirecionar o tráfego custa algumas horas de máquina e elimina a pior categoria de problema — porque a volta é imediata.

Tire snapshot antes de qualquer atualização no lugar, quando não houver alternativa. Um apt full-upgrade entre versões maiores tem chance real de deixar a máquina sem subir, e o snapshot transforma isso de incidente em cinco minutos de retorno.

Teste o que quebra, não o que funciona. Mudança de versão maior costuma derrubar coisa em três lugares previsíveis: extensão nativa que não compila, sintaxe removida, e comportamento de bibliotecas de data e de codificação. Vale listar essas áreas antes e testar direto nelas.

Quando não dá para atualizar

Existe o caso real em que a atualização não é viável no prazo: o sistema depende de uma biblioteca abandonada, o fornecedor do software não homologou a versão nova, ou o custo de recertificar não cabe agora.

Continuar como está sem fazer nada é a pior das opções. Aceitar o risco de forma explícita, com controles compensatórios e data para revisitar, é uma decisão defensável. A diferença entre as duas é trabalho, e vale a pena.

Os controles que mais reduzem exposição:

• Tirar da internet. Um serviço desatualizado acessível apenas pela rede interna ou por VPN muda a categoria do risco. Se ele precisa ser público, restrinja a origem na regra de firewall ao que realmente precisa alcançá-lo.
• Colocar um proxy atualizado na frente. Um nginx recente terminando o TLS protege contra falhas na camada de transporte do serviço antigo — que é onde mora boa parte das vulnerabilidades exploráveis remotamente.
• Isolar. Serviço legado em máquina própria, sem credencial compartilhada e sem acesso à rede dos outros sistemas, contém o estrago se ele for comprometido.
• Reduzir o que ele alcança. Regra de saída limitando para onde aquela máquina pode conectar dificulta bastante a vida de quem entrar.
• Aumentar a frequência de backup e testar a restauração. Se a hipótese de comprometimento é mais alta, a capacidade de voltar precisa ser melhor.

Registre a decisão por escrito, com o motivo, os controles aplicados e a data de reavaliação. Isso serve para auditoria, e serve principalmente para que a exceção não vire permanente por esquecimento — que é o destino natural de toda exceção não documentada.

Transformar em rotina

O objetivo final é que EOL deixe de ser evento e vire calendário. Três hábitos bastam:

• Revisão semestral do inventário, com a data de fim de suporte anotada ao lado de cada componente.
• Uma máquina de referência atualizada. Manter um ambiente na versão seguinte, mesmo sem uso produtivo, revela os problemas de compatibilidade meses antes.
• Padrão de saída. Definir que a empresa adota apenas versões LTS e migra ao menos um ciclo antes do fim elimina a discussão caso a caso.

O ganho maior não é de segurança, é de custo. Atualizar de uma versão para a seguinte é uma tarefa; atualizar de uma versão de cinco anos atrás para a atual é um projeto, porque acumula todas as mudanças incompatíveis do período de uma só vez. Empresa que pula duas gerações paga a soma das migrações, com a diferença de que paga tudo junto e sob pressão.

Há também o efeito sobre quem opera. Pilha atualizada significa documentação que corresponde à realidade, resposta em fórum que se aplica ao seu caso e ferramenta que instala sem contorno. Pilha antiga transforma cada tarefa banal em pesquisa arqueológica — e esse custo, diluído no dia a dia, raramente é atribuído à causa certa.

Vale acompanhar também o que muda por decisão comercial, e não por calendário técnico: mudança de licença em projeto open-source produz efeito parecido — a versão que você usa continua lá, mas o caminho adiante muda.

Se a conclusão for provisionar máquinas novas para migrar ao lado, a criação de VPS leva pouco mais de um minuto, e manter as duas no ar durante a transição costuma custar menos que um único fim de semana de correção às pressas.