A era dos patches agora roda na velocidade das máquinas, e os ciclos trimestrais acabaram

O que acontece quando encontrar um bug fica mais barato do que corrigi-lo? Acabamos de ver isso ao vivo, e não foi bonito. Governos tiraram sites do ar, e quem cuida da encanação da internet passou a semana em modo de triagem.

Resumindo: duas falhas críticas no PHP, que, segundo a AFP, roda boa parte dos sites do mundo, foram encontradas com modelos de IA. Conforme relata o L'Express, sites governamentais na Europa e em outros lugares saíram do ar por precaução enquanto os responsáveis corriam para aplicar a correção. Duas empresas de segurança, Calif e Wiz, disseram ter achado os bugs de forma independente, e a Wiz afirmou ter usado modelos da OpenAI e do Google. Os bugs estavam no código havia anos.

Na nossa visão, as falhas em si importam menos do que aquilo que elas revelam. A descoberta agora acontece na velocidade das máquinas. A maioria das organizações ainda aplica correções na velocidade humana.

O assustador não é o bug, é o relógio

Michael Daniel, presidente da Cyber Threat Alliance e ex-coordenador de cibersegurança da Casa Branca, deu à AFP o número que mais nos marcou. Antes levava um ou dois meses para sair uma prova de conceito, e mais um ou dois para ela aparecer em kits de exploração. Agora, diz ele, isso se mede em horas ou dias.

Veja o que isso faz com um ciclo trimestral de patches. Se o intervalo entre a divulgação de uma falha e o uso dela pelos atacantes cai para horas ou dias, um processo baseado em janelas de manutenção mensais é, a nosso ver, uma decisão de ficar exposto. A investigação da Reuters resumida pelo Distributique diz que dados da VulnCheck mostram o número de vulnerabilidades descobertas dobrando em um ano. Dobrar o volume que chega enquanto a janela de resposta desmorona é um aperto que contratar mais gente provavelmente não resolve.

Precisamos ser justos com as ressalvas, porém. Daniel observa que historicamente só cinco ou seis por cento das vulnerabilidades foram exploradas, e nada sugere que essa fatia esteja crescendo. Sobre esta falha específica, os relatos se contradizem. Pesquisadores citados pelo Distributique disseram que, na época da investigação da Reuters, nenhum exploit funcional havia sido confirmado. O L'Express, por sua vez, informa que empresas de tecnologia alertaram que alguns hackers já estavam explorando as falhas. Não temos como resolver isso daqui. Nossa leitura é que, antes de tudo, é um problema de velocidade, e dizer que a internet já está pegando fogo seria exagero. Encolher os ombros seria pior.

"Testar tudo por semanas" era um luxo, não uma política

A ideia mais incômoda da entrevista de Daniel é sobre tolerância a risco. A maioria das empresas adotava o que ele chama de tolerância zero a qualquer quebra, então testava os patches de forma exaustiva. Ele argumenta que elas não têm mais esse tempo. Se um patch tem um por cento de chance de quebrar alguma coisa, mas um ataque pode custar US$ 50 milhões, a conta muda.

Achamos que ele tem razão, ainda que muitos departamentos de TI não gostem de ouvir isso. Aplicar patches devagar e com cuidado era racional quando a exploração era lenta. Agora o custo de esperar é o maior risco. Na prática, isso significa três coisas pouco glamorosas. Primeiro, um inventário preciso do que você roda e do que está exposto à internet. Segundo, caminhos automatizados de teste e implantação capazes de entregar uma correção rápido. Terceiro, mitigações temporárias para quando um patch não puder sair na hora. É mais ou menos a lista que o texto do Distributique apresenta, e nada disso exige IA. Exige disciplina, que é mais difícil.

As organizações pequenas são as grandes perdedoras. O conselho de Daniel para elas é direto: reorganizar-se para aceitar as atualizações dos fornecedores o mais rápido possível. Para quem usa uma plataforma gerenciada, isso quer dizer, principalmente, escolher fornecedores pela rapidez com que corrigem.

A dívida técnica é a verdadeira história, e a IA é o cobrador

Daniel fala da "dívida técnica chegando ao vencimento". O custo implícito de manter software antigo nunca aparece nos balanços até um episódio como este. Rob Joyce, ex-diretor de cibersegurança da NSA, chamou isso de "grande incêndio florestal purificador do software antigo". As duas imagens nos convencem.

Há também uma leitura esperançosa. Daniel espera que ferramentas de IA passem a ser aplicadas ao software antes de ele entrar em produção, de modo que o código novo já nasça com menos brechas. Jason Clinton, executivo de segurança da Anthropic, escreveu no X que as coisas vão piorar muito antes de melhorar e que será preciso aguentar cerca de 18 meses, segundo o 01net. É uma previsão, não um fato, e vem de uma empresa que constrói esses modelos. Ainda assim, a lógica é plausível: com o tempo, os defensores terão as mesmas ferramentas.

Outra cautela é o ruído. Daniel admite com franqueza que muitos achados relatados por IA são alarmes falsos ou estão em software que nunca é exposto à internet. O gargalo parece ser a triagem, não a descoberta.

Nosso veredicto

Pare de tratar isso como uma história sobre PHP. Encare como um teste de estresse do seu processo de patches e pergunte com honestidade quanto tempo uma correção crítica teria levado aí nesta semana. Se a resposta for "semanas", esse é o projeto do próximo trimestre, não do próximo ciclo de patches. Faça o inventário do que você roda, automatize a implantação, aceite um pequeno risco de quebra e aposente o software que você mantém vivo por pura inércia. A enchente que Daniel descreve vem de qualquer jeito. A única escolha é se você construiu um vertedouro.