Google usa IA e corrige mais bugs do Chrome em dois lançamentos do que nos 23 anteriores

O time de segurança do Chrome publicou um post detalhado sobre como está usando modelos de linguagem (LLMs) para acelerar cada etapa do ciclo de vida de uma vulnerabilidade: descoberta, triagem, correção e entrega da atualização. O número que chama atenção: nos dois últimos marcos de versão, Chrome 149 e 150, a empresa corrigiu 1072 bugs de segurança, superando o total corrigido nos 23 marcos anteriores somados.

O que a Google descreveu

Segundo o post, o time usa LLMs em segurança há anos. Em 2023 aplicou modelos para ampliar cobertura de fuzzing; em 2024 trabalhou com o Project Zero no Naptime; e em 2025 colaborou com o DeepMind e o Project Zero no Big Sleep, agente que encontrou bugs no motor JavaScript V8 e na pilha gráfica.

No início de 2026, a empresa construiu um harness de agente usando o Gemini para varrer a base de código do Chrome. Um dos achados foi uma falha de sandbox escape que, segundo o post, sobreviveu silenciosamente na base por mais de 13 anos, permitindo que um renderizador comprometido enganasse o navegador para ler arquivos locais.

A automação foi aplicada em todas as etapas:

• Descoberta: agentes rodam sobre o código, com base de conhecimento que inclui todos os CVEs anteriores e o histórico Git completo do Chrome. Arquivos SECURITY.md ajudam os modelos a entender limites de confiança.
• Triagem: o processo, que antes levava de 5 a 30+ minutos por relatório e dependia de humanos, agora combina regras e IA em quatro fases (filtrar ruído, reproduzir, enriquecer com metadados e atribuir). A Google estima economia de centenas de horas de desenvolvedor por mês.
• Correção: fluxos multiagente geram correções candidatas, avaliadas por um agente "crítico" que imita um code review, além de agentes que escrevem testes.

As ferramentas Big Sleep e CodeMender estão integradas ao sistema de integração contínua (CI), rodando a cada 24 horas. Segundo o post, só em maio isso bloqueou mais de 20 vulnerabilidades antes de chegarem à produção, incluindo uma crítica classificada como S1+.

Reduzindo o patch gap

O post trata do chamado patch gap: o intervalo entre a correção aparecer no código-fonte aberto (onde atacantes podem fazer engenharia reversa) e ela chegar à máquina do usuário, o que abre espaço para ataques "N-day". A empresa afirma estar em transição para uma cadência de duas semanas nos marcos maiores, com atualizações semanais de segurança, e está pilotando duas releases de segurança por semana.

Há ainda um esforço no lado da aplicação da atualização. A Google diz estar investindo em dynamic patching, que substitui processos-filho (Renderer, GPU) por binários atualizados em tempo real, sem exigir reinício completo. No Chrome 150, no macOS, o navegador passou a reiniciar automaticamente quando detecta atualização pendente e está sem janelas abertas.

Prevenção e memory safety

O post reforça a estratégia de segurança de memória em duas camadas: endurecer o ambiente de execução em C++ e migrar para linguagens seguras. A empresa cita que 97% do código próprio do Chrome compila sem avisos de buffer inseguro graças ao esforço de spanification, além da expansão do MiraclePtr e MiracleObject contra bugs de use-after-free. No longo prazo, aposta em Rust, com um SDK centralizado para reduzir o atrito de adoção.

O que muda para quem desenvolve no Brasil

O Chrome (e o Chromium por baixo dele) é a base de trabalho de boa parte dos devs brasileiros: DevTools, testes end-to-end, Electron, WebViews em apps mobile e navegadores derivados como Edge, Brave e Opera. Correções chegando mais rápido e com menor patch gap significam menos janela de exposição a ataques N-day nas máquinas de desenvolvimento e nos produtos que embarcam o motor.

Para quem administra frota corporativa, o post recomenda três práticas de admin de TI: aplicar a policy RelaunchNotification para forçar reinício e aplicar atualizações pendentes, usar o Chrome Extended Stable Channel em ambientes sensíveis que precisam validar mudanças, e acompanhar versões via dashboard do Chrome Enterprise Core ou Premium.

O post também detalha a escala do desafio de dependências: o Chrome tem mais de 2.300 dependências de terceiros entre Chromium e projetos satélites como V8, BoringSSL, Skia, ANGLE e Dawn, das quais cerca de 1.700 chegam aos usuários. A Google diz ter se juntado a outros para doar US$ 12,5 milhões ao projeto Alpha-Omega e ter sido fundadora do projeto Akrites, ambos voltados a apoiar mantenedores de open source na resposta a vulnerabilidades.

Fonte: Hacker News