Dívida técnica: a hora do pagamento chegou

A primeira- ministra do Japão, Sanae Takaichi, deixou no X, nesse mesmo dia, pouco antes das dez da noite em Tóquio, um invulgar “pedido urgente” às empresas nipónicas para atualizarem o PHP nessa noite ou, não o conseguindo, suspenderem temporariamente os seus sites.

Na véspera da divulgação, os códigos com que as duas falhas tinham sido registadas no catálogo internacional de vulnerabilidades (CVE) apareceram em fóruns e redes sociais, ainda sem pormenores técnicos e, nessa mesma noite, a Calif, uma das empresas que as tinham descoberto, publicou, aparentemente por engano, um vídeo em que demonstrava como as falhas podiam ser exploradas; o vídeo foi apagado, mas as cópias espalharam-se e, segundo a PHP Foundation, aceleraram o aparecimento de provas de conceito públicas. Por causa da fuga, a divulgação coordenada, prevista para dia 22, foi antecipada em vinte e quatro horas e, na manhã de 21, a Chainguard, uma distribuidora de software já compilado, publicou as novas versões, mais de seis horas antes da hora prevista, o que, para um atacante, capaz de comparar o código novo com o anterior e chegar à falha, podia ser considerado um convite.

Não que o problema fosse novo. Em 2024, um dos programadores do core do PHP reparou num comportamento anómalo na forma como o PHP reagia quando um programa esgotava a memória que lhe estava atribuída, mas ninguém conseguiu demonstrar como explorá-lo, e o assunto ficou por resolver. No passado mês de agosto, a Calif, que trabalhou com um modelo da OpenAI, e uma equipa da própria OpenAI chegaram, cada uma por si, à mesma causa; a Wiz, com modelos da Google e da OpenAI, construiu ataques funcionais contra o WordPress, o Drupal e o Joomla. Foi a partir destas descobertas que o projeto preparou as versões de outubro.

O custo de passar da suspeita à demonstração mudou, e não apenas no PHP: em outubro, a Microsoft lançou patches, de uma só vez, para cerca de mil e quatrocentas vulnerabilidades — mais, segundo a Zero Day Initiative, do que em qualquer ano anterior, seja qual for a parte desse aumento que se fique a dever à IA. A dívida técnica acumulada em décadas de desenvolvimento de software é, há muito, tema de discussão nas conferências e nas reuniões empresariais, mas foi sendo empurrada de orçamento em orçamento, enquanto encontrar e explorar as falhas foi caro. Esse adiamento acabou: a IA trouxe a dívida a pagamento, e os juros capitalizam depressa, como mostram os ataques que a Cloudflare registou contra os seus clientes ainda antes das novas versões.

O caso de 2024 mostra onde está, de facto, o estrangulamento. Sem uma forma de exploração demonstrada, um problema identificado compete por tempo e recursos com tudo o resto que os responsáveis de um projeto têm em mãos, e raramente ganha.

A proposta de solução nipónica — desligar o que não se consegue atualizar a tempo — pressupõe que alguém saiba o que tem ligado. A percentagem de vulnerabilidades corrigidas dentro do prazo, a métrica durante muitos anos usada pelas comissões de avaliação de risco, mede, na verdade, o ritmo de quem as trata, mas diz pouco sobre o que fica, entretanto, exposto. Agora que a fatura chegou, mais útil será a lista do que fica por corrigir, ou desligado, durante quanto tempo e por decisão de quem. E essa lista deve começar pelas bibliotecas de código aberto de que cada organização depende e para cuja manutenção, muitas vezes, nunca contribuiu: é a parte da dívida que, até agora, foi paga por outros.