Em resumo: um processo de gestão de patches define como as atualizações decorrem desde a entrada até ao comprovativo: em que classe cai um patch, em que janela é instalado, como se testa e se reverte, quem reinicia e como se comprova o êxito. As atualizações de rotina seguem um ritmo planeado, os patches de emergência seguem uma via rápida acordada de antemão. Assim, os combates a incêndios tornam-se um procedimento repetível.
Quando cada patch é uma emergência
Na noite de 21/10/2026, repetiu-se em muitas empresas o mesmo padrão. Os patches estavam disponíveis, o BSI (Gabinete Federal Alemão para a Segurança da Informação) insistia, e começaram as perguntas: podemos simplesmente atualizar agora? Quem testa? Quem reinicia os serviços? Quem avisa a gerência de que a loja ficará indisponível por pouco tempo? E como provamos depois que correu bem?
Nas empresas sem processo, tudo isto tem de ser esclarecido no momento. Nas empresas com processo, a resposta já está definida. A diferença não está na técnica, mas em acordos feitos antes.
Os elementos de um processo de gestão de patches
Um processo sustentável distingue primeiro a urgência de um patch. Três classes costumam bastar:
| Classe | Motivo típico | Janela | Teste | Aprovação |
|---|---|---|---|---|
| Rotina | correções de erros, atualizações de segurança de baixo risco | data mensal fixa | staging, testes padrão | TI, segundo o plano |
| Urgente | classificação elevada, sistema acessível ao público | antecipada, a curto prazo | reduzido, processos mais importantes | direção de TI |
| Emergência | vulnerabilidade crítica, ataques comunicados, p. ex. PHP2Shell | imediata | teste rápido após a instalação | aprovação de emergência concedida previamente |
Quem atribui cada classe deve estar tão definido quanto os critérios para isso. A avaliação em si pertence ao passo anterior, veja Gestão de vulnerabilidades para PME.
Importante é a aprovação de emergência concedida previamente. A gerência decide uma vez, com calma, que, nos patches de emergência, se pode agir de imediato, mesmo que isso signifique uma breve interrupção. Numa emergência, ninguém precisa então de obter uma autorização a meio da noite.
Igualmente importantes são os papéis. Para cada sistema deve estar definido quem instala as atualizações, quem testa do ponto de vista funcional se a loja ou o portal funciona depois e quem é informado. Nos sistemas externalizados, o fornecedor de alojamento e a agência fazem expressamente parte, com nome e contacto. A janela de manutenção fixa deve ser conhecida internamente, para que vendas e apoio ao cliente saibam quando são possíveis breves interrupções.
Meça também quanto tempo o seu processo demora de facto: da publicação de um patch até à conclusão comprovada, por classe. Estes valores próprios mostram onde há atrasos e tornam visíveis as melhorias. Um processo cuja duração ninguém conhece dificilmente se pode gerir.
O percurso de um patch em oito passos
Todo o patch, seja qual for a classe, passa pelas mesmas etapas. Só o ritmo e a profundidade dos testes diferem.
- Entrada: o alerta ou a atualização disponível é registado, com data e fonte.
- Classificação: definir a classe, determinar os sistemas afetados segundo o inventário.
- Preparação: cópia de segurança ou snapshot, descrever o caminho de regresso, informar os envolvidos.
- Teste: primeiro em staging ou num sistema menos crítico.
- Instalação: na janela acordada, sistema a sistema.
- Reinício: todos os serviços e processos afetados, e não apenas os pacotes.
- Comprovativo: registar o estado do pacote, a entrada do changelog e o arranque dos processos.
- Verificação: testar o funcionamento e, em caso de vulnerabilidades de segurança, procurar também vestígios de uma intrusão anterior.
O passo 6 é esquecido com surpreendente frequência. O PHP carrega o seu código quando os processos arrancam. Enquanto houver workers antigos do PHP-FPM ou processos Apache com mod_php em execução, continuam a trabalhar com o estado antigo e vulnerável. Porque é assim e como reiniciar corretamente, explica-o Depois da atualização: reiniciar o PHP-FPM e todos os workers.
Comprovativos que contam mais tarde
Um patch sem prova, na dúvida, não foi instalado, pelo menos perante clientes, seguradoras ou auditores. Registe, por sistema, que estado do pacote está instalado, se os números CVE constam do changelog e quando arrancaram os processos em execução. Em sistemas Debian e Ubuntu, ajudam comandos de leitura como estes (adapte o nome do pacote ao seu sistema):
# O pacote instalado contém as correções?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Quando arrancaram os processos PHP-FPM em execução?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
Se a hora de arranque dos processos for anterior à instalação do pacote, falta o reinício. Comprovar números CVE no changelog do pacote descreve-o em pormenor.
Um patch fecha uma vulnerabilidade para o futuro. Não remove software malicioso introduzido antes e não prova que antes não aconteceu nada. Nos patches de emergência, uma busca de vestígios faz por isso parte integrante do procedimento.
Automatizar onde é seguro
As atualizações de segurança automáticas dos pacotes do sistema operativo retiram muito trabalho de rotina. Só aliviam, porém, se existirem cópias de segurança, se alguém ler os resultados e se os serviços afetados também forem reiniciados. Como configurar isto em Linux e quais os limites, descreve-o Atualizações de segurança automáticas em servidores Linux.
Os contentores precisam de um caminho próprio. Aí não se atualiza no sistema em execução; reconstrói-se a imagem com a versão corrigida do PHP e implanta-se. Um processo de patches que só conhece servidores facilmente ignora estes sistemas. Inclua por isso também os pipelines de compilação e os registos de imagens na lista dos caminhos de patch, com uma pessoa responsável e o mesmo comprovativo que nos servidores clássicos: que versão do PHP corre no contentor implantado, e desde quando?
As aplicações, os CMS e os plugins precisam em geral de um caminho próprio e testado, porque aí as atualizações alteram funcionalidades com mais frequência. A data mensal fixa é o lugar certo para isso. O importante é, no fim, que todos os caminhos convirjam na mesma documentação: um sítio onde se vê que sistema está em que estado.
Como ajuda concretamente a PHP SOS?
- Escrevemos consigo as classes de patches, as janelas e as aprovações, adequadas aos seus sistemas e à sua organização.
- Configuramos atualizações de segurança automáticas com verificação de reinício e notificação, onde isso faz sentido.
- Assumimos os patches de emergência, incluindo reinício, comprovativo e busca de vestígios, através do nosso serviço de patches PHP.
- Mantemos os comprovativos por sistema de modo a que os possa apresentar a clientes, seguradoras ou auditores.
Conclusão: a gestão de patches parece pouco espetacular enquanto funciona. É precisamente esse o objetivo: quando chegar o próximo alerta crítico, corre um procedimento já treinado e ninguém tem de improvisar.
Perguntas frequentes
Qual é a diferença entre a gestão de patches e a gestão de vulnerabilidades?
A gestão de vulnerabilidades regista e avalia as falhas e decide o que fazer. A gestão de patches executa a decisão: testar as atualizações, instalá-las, reiniciar os serviços e comprovar o êxito. Ambas se encaixam uma na outra.
As atualizações de segurança devem ser instaladas automaticamente?
Para os pacotes do sistema operativo, isso faz muitas vezes sentido, desde que existam cópias de segurança e se verifique o resultado depois da execução. É importante que também os serviços afetados sejam reiniciados. No caso do PHP, ficam de outro modo processos antigos com o código vulnerável na memória.
Como comprovo que um patch realmente funciona?
Com o estado do pacote instalado e os números CVE no changelog do pacote, o momento da instalação e a hora de arranque dos processos em execução, que tem de ser posterior à instalação.
O que fazer se uma atualização estragar alguma coisa?
Para isso existe o caminho de regresso: uma cópia de segurança ou snapshot antes da atualização e um procedimento descrito para reverter. No caso das atualizações de segurança, reverter deve ser a exceção e ser combinado com uma medida provisória.