Suas dependências do Composer não deixam de existir só porque o PHP foi descontinuado

Principais conclusões

• O PHP divulga as datas de fim de vida útil com anos de antecedência, enquanto os pacotes do Composer não anunciam nada quando um mantenedor deixa de aparecer.
• Uma dependência abandonada costuma ser a causa de uma atualização do PHP ficar parada, e não um efeito colateral dela.
• composer why-not indica rapidamente o que está impedindo sua próxima atualização de tempo de execução.
• O Composer consegue identificar pacotes abandonados, mas nenhuma ferramenta da cadeia de ferramentas aplicará correções neles para você.

Uma equipe leva quatro meses para migrar do PHP 8.1 para o 8.3. Testes, ambiente de teste, migração durante o fim de semana, todo o processo. Funciona.

Em seguida o composer audit marca um pacote que lida com webhooks de pagamento como abandonado. Alguém abre o repositório e não encontra nenhum commit desde 2021. Sem política de fim de vida útil, sem aviso de descontinuação, apenas um projeto que silenciosamente deixou de receber atenção, situado quatro níveis abaixo em uma árvore de dependências que ninguém leu do início ao fim.

O ambiente de execução foi atualizado. O risco de software EOL não sofreu alterações.

Essa diferença entre “estamos usando uma versão do PHP com suporte” e “nosso aplicativo tem suporte” é onde se esconde grande parte da dívida de segurança do PHP, e é muito mais difícil de identificar do que um número de versão no php -v.

O cronograma de fim de vida útil do PHP que todo mundo acompanha

A política de lançamento do PHP é realmente boa, e essa previsibilidade é exatamente o motivo pelo qual o fim da vida útil (EOL) em tempo de execução é a parte mais fácil desse problema. Cada ramificação recebe dois anos de suporte ativo, seguidos por mais dois anos que abrangem apenas questões críticas de segurança.

Um detalhe importante a se saber antes de ler a tabela. Esse período de quatro anos só se aplica a partir do PHP 8.1, pois o ciclo de lançamento foi estendido em 2024. As versões anteriores receberam apenas um ano de correções de segurança, em vez de dois; é por isso que as versões 7.4 e 8.0 parecem ter um período mais curto na tabela abaixo.

Esta é a situação atual, confirmada com base na página oficial de versões suportadas do PHP.

O PHP 8.1 e o 8.2 são as duas versões que merecem sua atenção hoje. O PHP 8.1 chegou ao fim de sua vida útil em dezembro de 2025; portanto, qualquer sistema que ainda esteja rodando nessa versão já está há meses sem correções de segurança do desenvolvedor original. O fim do suporte ao PHP 8.2 chega ao fim em dezembro de 2026 e, embora a versão 8.2 ainda receba suporte hoje, qualquer equipe que planeje mantê-la em operação após essa data precisa ter uma solução pronta antes disso.

As equipes que não conseguirem migrar a tempo podem aplicar patches fornecidos pelo fornecedor diretamente no próprio ambiente de execução e continuar recebendo correções de segurança até que a migração seja concluída. É isso que o Suporte de Ciclo de Vida Ilimitado da TuxCare para PHP da TuxCare, assim que uma versão do PHP chega ao fim de vida útil, enquanto essa versão permanecer em sua pilha de aplicativos.

Observação: Estar dentro do período exclusivo de segurança não é o mesmo que estar sob suporte ativo. As correções regulares de bugs foram interrompidas. O trabalho de otimização de desempenho foi interrompido. O trabalho de compatibilidade foi interrompido. O que resta são correções críticas de segurança em um ramo do qual os gerentes de lançamento já se afastaram.

Por que as dependências do Composer nunca têm uma data de fim de vida útil

Quase ninguém publica uma política de suporte para um pacote que criou em um fim de semana de 2018.

Essa é a verdadeira diferença. O PHP conta com um grupo de gerentes de lançamento, uma política documentada e um cronograma que permite o planejamento. Um pacote do Composer geralmente depende de uma única pessoa ou de uma pequena equipe, e as pessoas mudam de emprego, perdem o interesse ou acabam sendo chamadas para outras tarefas. Quando isso acontece, não há nenhum anúncio, porque nunca houve um compromisso de anunciar nada.

A falta de manutenção se manifesta de várias maneiras diferentes, e apenas uma delas é fácil de identificar. Um pacote marcado como “abandonado” no Packagist é o caso mais simples, pois o Composer realmente avisa sobre isso. Um repositório arquivado no GitHub representa a mesma situação, mas sem nenhum aviso, e o Composer não faz nenhuma menção a isso.

Depois, há o pacote cuja última versão foi lançada há dois ou três anos, com problemas se acumulando sem resposta; o mantenedor que ainda está por aí, mas deixou de oferecer suporte à versão principal mais antiga na qual você está preso; o pacote que foi incorporado a um projeto diferente sem um redirecionamento; e o fork que, discretamente, se tornou o projeto de fato, enquanto o original manteve o nome.

Um pacote que, tecnicamente, ainda está lá, ainda pode ser instalado, ainda é resolvido sem problemas — e não recebe nenhuma atenção em termos de segurança — parece exatamente um pacote em boas condições quando visto de dentro do seu composer.lock.

Como descobrir o que você está realmente executando

Reserve alguns minutos para cada aplicação. O resultado geralmente não é nada agradável de ler.

Comece com o que o Composer já sabe.

auditoria de compositores

O Composer 2.4 e versões posteriores verificam as dependências instaladas por meio da API de alertas do Packagist, que agrega o Banco de Dados de Alertas de Segurança do PHP e a Base de Dados de Alertas do GitHub. Adicione –locked se preferir auditar o arquivo composer.lock diretamente sem instalar primeiro, o que é a escolha comum em CI. Os pacotes abandonados entraram em cena no Composer 2.6.3 e, desde a versão 2.7, eles são reprovados na auditoria por padrão; portanto, uma execução limpa em um Composer moderno já fornece mais informações do que antes.

Se você quiser a lista abandonada sem interromper a compilação, a versão 2.8 adicionou um sinalizador exatamente para isso.

auditoria do composer –abandonado=relatório

Isso reclassifica os pacotes abandonados de “falha” para “relatório”, o que geralmente é o desejado na integração contínua (CI) enquanto o backlog é processado.

Agora veja o quanto suas dependências diretas estão realmente atrasadas.

composer show –outdated –direct

O –direct é importante. Se você ignorá-la, obterá a árvore inteira, onde as informações úteis se perdem no ruído. As dependências diretas são aquelas que você escolheu propositalmente; portanto, são o ponto de partida mais prático. Adicione –sort-by-age e as versões mais antigas aparecerão primeiro, o que é uma maneira mais rápida de identificar aquelas que estão realmente desatualizadas.

Se algo parecer desatualizado, verifique o status real do pacote, em vez de confiar apenas no número da versão.

composer show vendor/package

Isso extrai os próprios metadados do pacote, incluindo se o Packagist o marcou como abandonado e o que o mantenedor sugeriu como substituto, caso tenha se dado ao trabalho de sugerir algum. Para ter uma visão real da atividade de manutenção, dos commits recentes, das versões lançadas, das questões em aberto e se as solicitações de pull são levadas adiante, verifique o repositório diretamente.

Por que atualizar o PHP não resolve esse problema

Agora, inverta a suposição comum. A dependência abandonada costuma ser a razão pela qual você ainda usa uma versão antiga do PHP, e não um sintoma disso.

An unmaintained package requiring php: >=8.1 <8.3 will refuse to install on 8.4, and with nobody maintaining it, that upper bound never gets loosened. The upgrade stalls on a library that stopped receiving maintenance years ago.

O Composer mostrará exatamente quais pacotes estão impedindo sua execução.

composer why-not php 8.4

Execute isso antes de planejar qualquer atualização do ambiente de execução. Isso transforma a afirmação “a migração para o PHP 8.4 é uma grande incógnita” em uma lista específica e, geralmente, mais curta do que o esperado; e, muitas vezes, há um ou dois nomes nessa lista que fazem a sala ficar em silêncio.

Mais ou menos o que aparece:

Não foi possível localizar o pacote “php” com a restrição “8.4”; os resultados a seguir provavelmente estarão incompletos.

acme/webhook-handler 2.0.0 requires php (>=8.1 <8.3)

Não encontrou o que estava procurando? Tente executar o comando `composer require “php:8.4” –dry-run` para ter uma nova perspectiva sobre o problema.

composer why-not fornece a lista bruta, indicando quais pacotes e quais restrições. O que você fará com cada um deles depende de uma rápida verificação posterior, composer show vendor/package além de uma olhada no repositório. Quatro resultados cobrem quase tudo o que você vai encontrar.

Incorporar uma biblioteca abandonada ao seu próprio repositório significa que sua equipe agora é responsável por seus CVEs, e a maioria das equipes que segue esse caminho não conta com pessoal dedicado a isso. O código é copiado, mas a responsabilidade não vem junto.

A aplicação de patches em pacotes do Composer após o abandono do projeto pelo desenvolvedor original é uma disciplina específica, e esse é o problema em questão que o SecureChain para PHP foi desenvolvido para lidar com isso, em vez de ser uma capacidade que a maioria das organizações de engenharia deseja desenvolver e manter internamente.

O que acontece com os patches de segurança depois que o projeto original encerra suas atividades?

Na fase inicial, nada acontece. É isso que vale a pena deixar bem claro, porque muitas equipes simplesmente presumem, sem falar nada, que existe uma rede de segurança em algum lugar.

O Packagist não corrige pacotes. Os bancos de dados de alertas registram vulnerabilidades, o que é útil, mas diferente de corrigi-las. Um alerta relacionado a um pacote do Composer abandonado pode permanecer sem solução indefinidamente, sem uma versão oficial corrigida para a qual se atualizar, a menos que a manutenção seja retomada ou que um fork adote a correção.

A partir daí, suas opções são limitadas. Criar um fork e corrigir por conta própria, substituir a dependência, aceitar o risco com um controle compensatório documentado ou contratar alguém cuja função específica seja fazer o backport de correções para o código upstream que ficou para trás.

Observação: Se você aplicar um patch em um fork, escolha deliberadamente a estratégia do Composer. Para um aplicativo, o procedimento documentado é usar um repositório VCS que aponte para o seu fork, mantendo o nome original do pacote inalterado e definindo a restrição voltada para o seu ramo de desenvolvimento . Se você publicar o fork em seu próprio nome, será necessário substituir, para que tudo o que precisar do original ainda seja resolvido. Aliases inline são uma armadilha. Eles são um recurso exclusivo do usuário root, o que significa que o lado esquerdo do como seja descartado para quem depende do seu pacote, e o problema geralmente vem à tona meses depois na CI de outra pessoa.

Decidir o que fazer com cada dependência abandonada

Avalie o alcance do impacto juntamente com a gravidade. Uma vulnerabilidade que afete autenticação, pagamentos, envio de arquivos ou desserialização merece uma análise mais minuciosa, mesmo que se trate de uma vulnerabilidade moderada. No entanto, isso vale para os dois lados. Um alerta crítico e facilmente explorável em uma área menos visível não deve ser ignorado apenas porque o alcance do impacto parece menor.

Em seguida, analise a lista. Se houver um fork mantido e a API for compatível, mude para ele, teste e siga em frente. Isso abrange mais casos do que as equipes às vezes esperam, embora o esforço dependa do quanto a API tenha se desviado e da cobertura de testes com a qual você possa contar. Se o pacote for pequeno e você realmente o compreender, incorpore-o e assuma a manutenção, mas registre quem é o responsável, pois código incorporado sem responsabilidade definida é exatamente o que faz com que esse problema volte a surgir em três anos.

Se o pacote for grande, envolver questões de segurança e não tiver ninguém cuidando dele, pense bem antes de transformá-lo em um vendor. Essa é uma obrigação de correção de longo prazo para a qual sua equipe precisará alocar pessoal, e uma biblioteca relevante para a segurança sem um responsável é pior do que uma dependência externa óbvia.

Se uma dependência abandonada estiver impedindo uma atualização do PHP que você já se comprometeu a realizar, corrija a dependência primeiro e trate a atualização em tempo de execução como a segunda tarefa. Tentar resolver as duas coisas ao mesmo tempo transforma uma migração em tempo de execução com escopo limitado em um projeto de correção de dependências muito maior.

E se restrições regulatórias ou contratuais impedirem que você siga o cronograma do fornecedor de software de origem, a aplicação de patches fornecidos pelo fornecedor, tanto para o ambiente de execução quanto para os pacotes afetados, é outra opção. Isso garante que as correções de segurança continuem sendo aplicadas enquanto a migração ocorre de acordo com um cronograma que a empresa possa realmente financiar.

O tempo necessário para a atualização varia muito de acordo com a idade do aplicativo e a estrutura utilizada. Um aplicativo Laravel razoavelmente atual, com dependências mantidas ativamente, geralmente passa por um processo de atualização bastante simples. Um aplicativo de dez anos, desenvolvido em uma estrutura própria e com quarenta dependências diretas, é um desafio totalmente diferente, e quem atribuir o mesmo prazo para ambos claramente não já trabalhou o `composer why-not` ainda.

Você também pode saber mais sobre as melhores práticas de segurança do Laravel e a mitigação de ameaças ao framework em nosso guia dedicado.

Protegendo a cadeia de suprimentos do PHP

Os prazos de fim de vida útil do PHP são publicados com anos de antecedência, e qualquer equipe que tenha um calendário pode se planejar de acordo com eles. O problema mais difícil está no seu arquivo composer.lock agora mesmo, sem aviso prévio, sem programação e fora do controle de qualquer pessoa no momento em que um mantenedor se afasta.

As próprias ferramentas do Composer indicarão o que foi abandonado. Elas não aplicarão correções em nada disso. Essa é a lacuna que o SecureChain para PHP preenche, com pacotes recompilados a partir do código-fonte e verificados antes de chegarem à sua compilação, sendo depois monitorados e corrigidos à medida que surgem vulnerabilidades. Quando a manutenção do pacote upstream é encerrada, o TuxCare ELS amplia essa cobertura de correções e faz o mesmo para versões do PHP em tempo de execução que chegaram ao fim da vida útil.

Em vez de fazer um fork das bibliotecas para o seu próprio repositório e herdar silenciosamente suas vulnerabilidades (CVEs), você conta com uma alternativa verificada e recompilada a partir do código-fonte ao Packagist, que se integra perfeitamente ao mesmo fluxo de trabalho do Composer; assim, o “abandono” deixa de ser um risco que sua equipe tenha que arcar sozinha.

Perguntas frequentes

Quando o PHP 8.1 chega ao fim de sua vida útil?

O PHP 8.1 já atingiu o fim de vida útil em 31 de dezembro de 2025; portanto, qualquer sistema que ainda esteja rodando nessa versão não recebe mais correções de segurança do desenvolvedor original desde então, a menos que um acordo de correções de terceiros esteja preenchendo essa lacuna.

Quais versões do PHP ainda são compatíveis?

PHP 8.2, 8.3, 8.4 e 8.5. Dessas, as versões 8.2 e 8.3 estão em suporte exclusivamente de segurança, e a versão 8.2 perderá até mesmo esse suporte em 31 de dezembro de 2026. Consulte a página oficial de versões suportadas do PHP para verificar o status atual. 

Como faço para encontrar pacotes do Composer abandonados no meu projeto?

Executar composer audit, que, por padrão, apresenta falha em pacotes abandonados no Composer 2.7 e versões posteriores, ou composer audit –abandoned=report se preferir ver a lista sem interromper a compilação. Em seguida, execute composer show –outdated –direct para encontrar dependências diretas com versões mais recentes disponíveis e adicione –sort-by-age para colocar as mais antigas no topo. Os indicadores de abandono do Packagist não são completos; portanto, verifique a atividade do repositório para identificar qualquer item que pareça desatualizado.

O que acontece com um pacote do Composer que tenha um CVE e não tenha mantenedor?

O aviso é publicado, mas um projeto abandonado pode nunca lançar uma versão corrigida. Suas opções são: criar um fork e corrigir o problema por conta própria, substituir a dependência, documentar um controle compensatório ou recorrer a um fornecedor que faça o backport de correções para pacotes abandonados.

A atualização do PHP corrige as dependências desatualizadas do Composer?

Não, e geralmente a relação funciona ao contrário. Um pacote abandonado com uma restrição restrita de versão do PHP costuma ser justamente o que impede a atualização em tempo de execução, e é por isso que composer why-not php 8.4 deve estar no início de qualquer conversa sobre o escopo da atualização, e não no final.

Usar uma versão do PHP que chegou ao fim da vida útil (EOL) é um problema de conformidade?

Pode ser. Quando uma estrutura exige a correção oportuna de vulnerabilidades ou o uso de software com suporte do fornecedor, um ambiente de execução em fim de vida útil (EOL) torna-se difícil de conciliar com isso, pois, assim que as correções do desenvolvedor original cessam, as equipes precisam de outra maneira de comprovar que as vulnerabilidades recém-divulgadas ainda estão sendo corrigidas. A extensão do suporte a patches de segurança, como o oferecido pela TuxCare oferece, pode ajudar a manter essa evidência intacta durante uma migração; no entanto, o que satisfaz um auditor depende da estrutura específica e de como ela é implementada.

Resumo

Nome do artigo

O fim do ciclo de vida do PHP e as dependências do Composer que ninguém monitora

Descrição

É fácil acompanhar as datas de fim de vida útil do PHP. Já os pacotes do Composer abandonados dentro do seu aplicativo não são tão fáceis de rastrear e, geralmente, são eles que realmente impedem a atualização.

Autor

Tim Walker

Nome da editora

TuxCare

Logotipo da editora