A Cloudflare liga falhas achadas por IA ao tráfego real. Achar uma falha e saber se importa não é igual

A IA barateou a descoberta de vulnerabilidades. A emergência do PHP desta semana mostrou uma consequência: modelos de fronteira acharam falhas críticas em código auditado havia anos. A consequência mais silenciosa é o backlog. Todo scanner, todo agente de código e todo modelo de segurança produz agora mais achados do que qualquer time consegue ler, e a pergunta que define o risco deixou de ser “isso é um bug?” e passou a ser “esse bug importa aqui, hoje?”.

A resposta da Cloudflare, descrita num caso de cliente publicado pela OpenAI em 21 de outubro, é parar de julgar os achados só pelo código.

Evidência do código mais evidência da produção

A Cloudflare, que segundo a própria empresa intermedeia cerca de um quinto do tráfego da web, oferece em acesso antecipado um serviço de descoberta e correção de vulnerabilidades construído com os modelos Daybreak da OpenAI. A abordagem liga uma vulnerabilidade no código-fonte ao que está acontecendo em produção, por meio de três perguntas:

• A rota afetada está ativa? Uma falha num endpoint que ninguém chama tem prioridade diferente de uma no caminho de login.
• Ela está recebendo tráfego suspeito? Tentativas de exploração nas requisições reais transformam um achado teórico num incidente em andamento.
• Os controles existentes já a protegem? Um achado atrás de uma regra de firewall que funciona é menos urgente do que um sem nada na frente.

A partir desses sinais, o serviço entrega aos clientes evidências para priorizar, proteções de borda propostas, como regras de web application firewall, e correções de código propostas. Nas palavras da OpenAI, os clientes “mantêm o controle sobre quais mudanças implementar”. Nada na descrição mostra o sistema corrigindo sozinho as aplicações dos clientes.

Por que a exposição é o dado que faltava

A maioria dos programas de vulnerabilidade ordena os achados por notas de severidade calculadas a partir da própria falha. Essa ordem ignora os fatos que decidem o risco real: se o código vulnerável está em produção, se é alcançável e se está sob ataque. Os times de segurança preenchem essa lacuna à mão, exatamente o trabalho que não escala quando a IA multiplica os achados.

É o mesmo padrão que vimos no Block, onde os agentes de segurança guardam a evidência bruta de cada investigação, e na decisão do GitHub de medir se os desenvolvedores corrigem os achados, e não quantos são encontrados. O modelo é útil nos três casos. O que o torna confiável é a evidência da qual ele é obrigado a partir: logs de tráfego, estado do firewall, registros de deploy. São fatos que o modelo não gerou e não consegue contornar com argumentos.

Também confirma o que defendemos sobre a capacidade de verificação ser o novo gargalo. Quando gerar é barato, o recurso escasso é decidir o que merece a atenção de uma pessoa. A evidência de produção é um verificador barato para essa decisão.

Os números de produtividade, lidos com cuidado

O mesmo texto relata que todos os desenvolvedores da Cloudflare, cerca de um terço da empresa, usam o Codex, e que um time de quatro pessoas reconstruiu em três dias um produto adiado, com US$ 1.100 em tokens. Mark Anderson, presidente de receita da Cloudflare, estima que sem isso levaria meses e “talvez 10 vezes mais desenvolvedores”.

São números informados pelo cliente sobre um único projeto, e os US$ 1.100 cobrem tokens, não o tempo dos engenheiros, a revisão ou os testes. São um sinal útil de que times capazes estão entregando muito mais código. Lidos ao lado da parte de segurança da história, também explicam por que priorizar pela exposição virou urgente: mais código, escrito mais rápido, significa mais achados, mais rápido.

O que copiar

1. Cruze os achados com dados de runtime antes de ordená-los. Atividade das rotas, sinais de tráfego e cobertura de controles fazem parte da priorização, não de um dashboard separado.
2. Mantenha separadas duas saídas: a mitigação e a correção. Uma regra de firewall ganha tempo; uma mudança de código remove a falha. As duas precisam de aprovação, e têm donos diferentes.
3. Exija evidência em toda ação proposta, com link para os logs de onde ela veio, para que quem revisa possa conferir em vez de confiar.
4. Meça o tempo até a decisão, e não só o tempo até o patch. Se os achados esperam dias para alguém julgar a relevância, o gargalo é esse.

A OpenAI também publicou no mesmo dia uma proposta de política que chama este período de “janela do defensor” e pede relatórios de incidentes mais fortes e avaliações independentes. É uma proposta, não lei. A versão operacional da mesma ideia é mais simples: quem defende aproveita a janela quando os achados chegam com a evidência necessária para agir.