- O Chrome automatiza, com agentes baseados no Gemini, desde a descoberta de vulnerabilidades até classificação, correção, distribuição e aplicação das atualizações, e corrigiu 1.072 bugs de segurança no Chrome 149 e 150 — mais do que a soma dos 23 milestones anteriores
- O sistema de detecção de vulnerabilidades combina vários modelos, uma base de conhecimento com CVEs e histórico Git do Chrome, o SECURITY.md e um agente crítico separado, operando em um ambiente com acesso à internet e ao sistema local estritamente limitado
- A classificação automática remove spam e duplicatas, coleta reprodução e stack traces, adiciona metadados como severidade e atribui responsáveis, com estimativa de economizar centenas de horas de trabalho de desenvolvedores por mês
- Para reduzir a janela entre patch e exploração após a divulgação da correção, o Google testa releases de segurança duas vezes por semana e desenvolve patch dinâmico com troca de processos-filho sem reinício, além de reinício automático no macOS
- Em vez de apenas corrigir bugs individuais, o Chrome aumenta a segurança de memória com MiraclePtr,
std::spane Rust, além de prevenir a entrada de vulnerabilidades com inspeção por IA no momento do envio de código e atualização automática de mais de 2.300 dependências externas
O ciclo de vida dos bugs de segurança transformado pela IA
- Os LLMs ampliaram a detecção automática de vulnerabilidades para uma escala além da que a especialização humana em segurança consegue cobrir sozinha, e o Chrome usa IA para encontrar e corrigir centenas de bugs de segurança com mais rapidez
- Enquanto bugs de funcionalidade comum causam problemas como travamento da interface, bugs de segurança podem ser usados em exploits que permitem a atacantes ler dados pessoais ou controlar o computador sem que o usuário perceba
- Bugs de segurança são tratados em sequência: descoberta, classificação, correção, distribuição do Chrome com a correção incluída, reinício do navegador e aplicação da atualização — e a meta é encurtar ao máximo todas essas etapas
Expansão da detecção de vulnerabilidades
- A equipe de segurança do Chrome vem evoluindo técnicas de detecção baseadas em LLM ao longo de vários anos
- Em 2023, desenvolveu formas de ampliar o alcance e o desempenho do fuzzing de segurança
- Em 2024, desenvolveu com o Project Zero o Naptime, fornecendo aos LLMs ferramentas especializadas para pesquisa de vulnerabilidades
- Em 2025, desenvolveu com o DeepMind e o Project Zero o Big Sleep, e esse agente encontrou bugs no motor JavaScript V8 e na stack gráfica
- O harness de agentes Gemini, construído no início de 2026, aumentou a eficiência da detecção em uma base de código mais ampla do Chrome e reduziu falsos positivos
- O bug de escape de sandbox descoberto podia permitir que um renderer comprometido enganasse o navegador para ler arquivos locais, e havia permanecido no código por mais de 13 anos
- Os seguintes recursos foram adicionados ao harness de detecção
- Interoperabilidade entre modelos, aproveitando os pontos fortes tanto de modelos com pesos abertos quanto de modelos proprietários
- Uma base de conhecimento que inclui todos os CVEs existentes e todo o histórico Git do Chrome
- Diretrizes de redação do SECURITY.md para comunicar com clareza limites de confiança e modelos de ameaça
- Um agente crítico que lê o SECURITY.md em um contexto separado
- Verificações repetidas da base de código para refletir a não determinismo dos modelos e as melhorias ao longo do tempo
- A IA analisa apenas código-fonte armazenado em equipamentos bloqueados sem acesso à internet aberta
- Todas as requisições de rede são interceptadas, aplicando listas de permissão baseadas em aplicação e destino
- Os modelos não são executados em modo irrestrito, e mudanças no sistema por subagentes e acesso a arquivos fora dos diretórios de código designados são limitados
- A detecção por IA não substitui os testes de segurança já existentes
- O fuzzing é particularmente eficaz para bugs que surgem de interações de longa distância entre áreas separadas do código ou da combinação de várias operações aparentemente sem relação
- Pesquisadores externos continuam sendo recompensados por encontrar vulnerabilidades difíceis e de alto impacto por meio do Chrome Vulnerability Reward Program
- No início de 2026, aumentaram as denúncias de todos os tipos, e em março foram recebidos mais relatórios de bugs do que em todo o ano de 2025
- Em resposta, o Google alterou o VRP para valorizar resultados adicionais em relação à detecção interna e focar em relatórios que o pipeline automatizado consiga absorver com facilidade
Classificação automática e correção com múltiplos agentes
- No passado, classificar um único relatório de segurança levava de 5 minutos a mais de 30 minutos e dependia principalmente da especialização humana, mas agora o processo combina sistemas baseados em regras e IA para aumentar volume e precisão
- A classificação automática ocorre em quatro etapas
- Remove spam e duplicatas, e verifica se o relatório atende aos critérios de recebimento e contém uma explicação clara de uma vulnerabilidade de segurança do Chrome
- Confirma prova de conceito e reprodutibilidade, testa na versão do navegador e sistema operacional correspondente e anexa informações como stack trace
- Adiciona o ponto em que o bug foi introduzido pela primeira vez e a severidade
- As diretrizes de severidade foram organizadas de forma mais clara para facilitar a aplicação automática
- Desenvolvedores podem alterar classificações incorretas de severidade e complementar informações sobre limites de segurança no SECURITY.md
- Faz o encaminhamento automático do problema para o componente e o responsável corretos
- Embora seja difícil medir com precisão, estima-se que a classificação automática economize centenas de horas de trabalho de desenvolvedores por mês
- Um fluxo de trabalho com múltiplos agentes é aplicado à correção de vulnerabilidades
- Um agente de correção recebe o contexto de cada problema e gera vários patches candidatos
- Um agente crítico avalia o candidato mais adequado e produz os artefatos necessários para a revisão do desenvolvedor
- Os dois agentes repetem um processo semelhante a code review, verificando comportamento funcional, conformidade com o estilo do Chromium e do Google e adesão às convenções locais do código
- Um agente de criação de testes verifica os testes em todas as plataformas e configurações suportadas pelo Chrome antes da revisão humana, economizando potencialmente semanas de tempo
- Hoje, os LLMs geram correções candidatas para a maioria das vulnerabilidades
- No Chrome 149 e 150, foram corrigidos 1.072 bugs de segurança, superando a soma dos 23 milestones anteriores
- Big Sleep e CodeMender, desenvolvidos em colaboração com o DeepMind e o Project Zero, foram integrados ao CI e inspecionam todos os CLs a cada 24 horas
- Só em maio, mais de 20 vulnerabilidades, incluindo problemas críticos S1+, foram bloqueadas antes de chegarem à produção
Redução da janela de patch e aplicação das atualizações
- O período de ataque N-day em que atacantes podem fazer engenharia reversa e explorar uma correção depois que o código corrigido entra no repositório open source público, mas antes de chegar aos usuários, é chamado de janela de patch
- Normalmente leva semanas até que uma correção refletida na árvore principal chegue ao canal Stable, usado pela maioria dos usuários
- Dependendo da severidade, as correções são mescladas diretamente no branch do release Stable atual, enquanto novos conflitos ou regressões seguem sendo monitorados
- Com a mudança dos principais milestones do Chrome para um ciclo de duas semanas, atualizações de segurança já são fornecidas semanalmente
- Para acompanhar o ritmo de ataques baseados em IA, também estão sendo testados releases de segurança duas vezes por semana
- Todos os bugs de segurança que chegam ao Stable são documentados publicamente, independentemente de terem sido descobertos interna ou externamente
- Para eliminar gargalos manuais e reduzir o tempo entre descoberta e divulgação, o Google trabalha na geração automática, a partir do patch, das notas de release e descrições de CVE
- O Chrome usa desde 2008 atualizações automáticas que baixam novos binários em segundo plano e os deixam prontos para aplicação no próximo reinício
- Classificação, correção, teste e distribuição levam de 1 a 2 dias, mas a espera até o usuário reiniciar também pode contribuir fortemente para o risco de exploração N-day
- Como reiniciar interrompe o trabalho e exige um momento separado, os usuários tendem a adiar
- Estão sendo desenvolvidos recursos para não transferir ao usuário o peso do reinício
- O patch dinâmico aproveita a arquitetura multiprocessos do Chrome para substituir gradualmente processos-filho em segundo plano, como Renderer e GPU, por novos binários, com o objetivo de eliminar na maioria dos casos a necessidade de reiniciar o navegador inteiro
- Também está sendo avaliada uma forma de salvar mais estado localmente para restaurar a sessão mesmo em situações complexas
- O navegador será reiniciado automaticamente quando a restauração completa da sessão puder ser garantida
- O Chrome 150 detecta no macOS quando todas as janelas foram fechadas, mas o app permanece em segundo plano, e reinicia automaticamente se houver uma atualização pendente
- No longo prazo, a meta é um navegador sempre atualizado, combinando patch dinâmico contínuo e reinício automático em momentos de menor interrupção
- As recomendações para administradores de TI corporativos são as seguintes
- Usar a política RelaunchNotification para aplicar gradualmente desde notificações até reinício forçado após um período definido
- Em ambientes sensíveis que exigem validação de mudanças, usar o Chrome Extended Stable Channel
- Acompanhar todas as versões do navegador e gerenciar atualizações de forma detalhada com o dashboard independente de sistema operacional do Chrome Enterprise Core ou Premium
Defesas em C++ e transição para Rust
- O Chrome usa uma estratégia dupla: neutralizar em tempo de execução vulnerabilidades existentes em C++ e, no longo prazo, migrar para linguagens com segurança de memória
- Como a maior parte do código do Chromium é em C++, a toolchain e as mitigações em runtime são a primeira linha de defesa imediata
- Tecnologias da família de biblioteca padrão reforçada e MiraclePtr vêm reduzindo vulnerabilidades de Use-After-Free (UAF)
- O roadmap de defesa em C++ é composto por três eixos
- Expansão de MiraclePtr e MiracleObject
- O MiraclePtr está sendo ampliado para Skia, ANGLE, Dawn, iteradores de C++ e contêineres
std:: - O MiracleObject troca desempenho localizado em runtime por segurança temporal, com a meta de neutralizar até 90% das vulnerabilidades UAF na thread principal da GPU
- O MiraclePtr está sendo ampliado para Skia, ANGLE, Dawn, iteradores de C++ e contêineres
- Transição para
std::span- Estruturas antigas que usam ponteiros e tamanhos juntos estão sendo substituídas por
std::span, verificável pelo compilador, para eliminar acessos fora dos limites (OOB) - 97% do código próprio do Chrome já compila sem problemas com avisos rígidos de unsafe-buffer, e essa exigência está sendo expandida para Skia, ANGLE e Dawn
- Estruturas antigas que usam ponteiros e tamanhos juntos estão sendo substituídas por
- Fortalecimento estrutural e de alocação
- Checked math é aplicado aos cálculos de alocação de memória para bloquear caminhos de overflow inteiro
- Particionamento adicional de heap, com separação rígida entre tipos com ponteiro e sem ponteiro, dificulta a exploração de UAF
- Expansão de MiraclePtr e MiracleObject
- O Google vê as mitigações em runtime para C++ como algo com retorno marginal decrescente nos próximos anos
- Verificações em runtime custam mais do que garantias em tempo de compilação, e até binários C++ fortemente mitigados exigem sandboxes rígidos com restrições de desempenho para cumprir a Rule of Two
- No longo prazo, a migração para Rust está avançando
- Flywheel de Rust: criação de um SDK central que oferece APIs e ferramentas do Chromium diretamente em Rust, para que novos componentes possam escolhê-lo no dia a dia
- Eliminação de áreas densas em bugs: substituição estratégica de códigos historicamente propensos a bugs, como parsers complexos de dados, codecs de imagem e stacks de fonte
- Modularização de alto privilégio: novos módulos escritos em Rust para executar funções complexas em áreas de alto privilégio, como o processo do navegador, sem o custo de desempenho de sandbox
- Também está sendo avaliada a implementação da interface de mais alto nível do navegador em HTML, CSS e TypeScript para reduzir ainda mais a dependência do framework legado em C++
Bloqueio de vulnerabilidades antes do envio do código
- Apenas escanear periodicamente toda a base de código não basta para acompanhar a velocidade de desenvolvimento do Chrome, por isso a inspeção por IA está sendo posicionada próxima ao momento do envio do código
- O modelo de defesa do CI e da commit queue (CQ) inspeciona automaticamente as mudanças
- Sugere correções de transição para
std::span - Sinaliza dangling pointers
- Impõe segurança nas operações numéricas
- Sugere correções de transição para
- Um código que parece seguro isoladamente pode se tornar um problema sério de segurança potencial ao se combinar com pequenas mudanças lógicas em outro ponto
- A análise semântica contínua por LLM dentro da CQ encontra interações sutis ou complexas que a análise estática tradicional deixa passar e as bloqueia antes que o código entre na árvore
Ecossistema open source e dependências externas
- A segurança da web depende não só do Chrome em si, mas também de projetos open source e da capacidade de resposta de seus mantenedores
- O Google doou, junto com outros participantes, US$ 12,5 milhões ao projeto Alpha-Omega para garantir que mantenedores tenham ferramentas e suporte para responder rapidamente a relatórios de vulnerabilidades
- Também participa como membro fundador do projeto Akrites, cujo objetivo é reduzir a carga dos mantenedores upstream com um ponto central de recebimento de relatórios de vulnerabilidade e uma equipe de resposta a incidentes de segurança
- O Chromium e projetos relacionados como V8, BoringSSL, Skia, ANGLE e Dawn têm mais de 2.300 dependências externas
- Destas, cerca de 1.700 são distribuídas aos usuários por meio de vários produtos, incluindo dispositivos Android, plataformas de edge computing e stacks de grandes empresas de nuvem
- O pipeline automatizado de inspeção de vulnerabilidades coleta dados de feeds internos do Google, do NVD do governo dos EUA e do OSV, voltado a open source
- Como o monitoramento posterior ainda pode deixar uma lacuna de risco, o Google começou a migrar para um pipeline de atualização automática que renova proativamente todas as dependências externas do Chrome para as versões upstream mais recentes
- No processo de automação, sinais de segurança de projetos como GOSSIP também são usados para refletir outros riscos do ecossistema open source externo
Um navegador protegido continuamente
- O aumento do número de bugs descobertos e corrigidos com LLM não é um fracasso; cada bug corrigido representa um ponto de apoio a menos para os atacantes
- Descobrir e corrigir não basta: é preciso distribuir a correção e aplicá-la no ambiente do usuário antes que atacantes a explorem
- Ao combinar releases mais rápidos, patch dinâmico, reinício automático em momentos de menor interrupção e defesas estruturais, o objetivo é um Chrome protegido continuamente sem atrapalhar o usuário
1 comentários
Opiniões no Hacker News
Recentemente, enquanto o trabalho estava corrido, usei bastante IA para otimização de desempenho, mas ela foi quase inútil para definir direções em alto nível. Mesmo quando apontava trechos suspeitos em consultas SQL, a diferença de desempenho antes e depois era mínima; perdi tempo com sugestões inúteis e ainda tive de lidar com pessoas jogando saídas brutas de IA como se fossem contribuições significativas.
Por outro lado, ficou muito mais fácil implementar mudanças que eu mesmo havia identificado ou mover joins para CTEs.
Mesmo repetindo para as ferramentas de IA “seja conciso”, “responda apenas à pergunta” e “não forneça informações não solicitadas”, elas produzem mais do que o necessário, o que parece uma tentativa sutil de consumir mais tokens.
Só pelo texto do código não dá para saber tamanho de cache, volume do banco de dados ou latência de rede; fornecer esse contexto leva a resultados melhores.
Um dado essencial é que, no Pwn2Own de Berlim em maio passado, o Firefox não pagou nenhum prêmio. Desde 2007, ele havia pago prêmios em todos os eventos, então o fato de não haver nenhuma vulnerabilidade confirmada parece indicar que quase não restam vulnerabilidades fáceis e que esses modelos são úteis em alguma medida.
Acredito que seja possível corrigir muitos bugs, mas fico curioso sobre o processo real. Também é possível que o Google tenha publicado o blog e incentivado correções de bugs por alguns sprints para que gestores mostrassem à alta liderança os resultados da adoção de IA, fazendo as equipes trabalharem muito mais do que o normal.
O desempenho de uma LLM depende da estrutura iterativa em que ela roda, e essa estrutura depende da qualidade dos verificadores, então isso é explicável sem uma exibição de resultados por parte da gestão.
Em vez de deixar a IA trabalhar sem rumo, é preciso usá-la como ferramenta de aceleração, mas os críticos parecem confundir as duas coisas. É um espantalho parecido com ficar bravo com o Excel porque o retorno sobre o investimento é ruim; em vez de discutir mais, prefiro compartilhar discretamente formas de uso com quem quer empregá-la de maneira adequada e eficiente.
Se deixada solta, a qualidade piora depois de algumas iterações; se guiada com cuidado, gera valor, mas o esforço fica parecido com escrever o código diretamente, especialmente quando há tarefas repetitivas.
Não se sabe quantas das correções automáticas foram revertidas, quantos bugs novos elas criaram, nem qual é a taxa de falsos positivos do agente de detecção. A postagem traz apenas números de sucesso e nada sobre o que pode dar errado
Mesmo que, ao corrigir 10 bugs, sejam criados 2 novos, o ganho líquido é grande se eles não forem bugs graves exploráveis isoladamente. Como ataques a navegadores exigem cadeias de vulnerabilidades cada vez mais longas, é difícil ignorar a vantagem de usar IA para encontrar bugs potenciais
https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1....
Há preocupação de que, no futuro, o Google conclua que o Chromium não precisa mais de uma busca coletiva e pública por bugs e encerre o desenvolvimento aberto. Nesse caso, os navegadores atuais baseados em Chromium se tornariam, na prática, forks da última versão pública, e a dificuldade de manutenção de cada fork poderia variar, já que eles não teriam recursos para se manter como o Chrome com suporte do Gemini
As críticas à IA muitas vezes se concentram na categoria estreita de que gerar código às cegas é ruim, e isso é fácil de reconhecer. Mas testes adversariais, validação de premissas de desenvolvedores, sugestões de refatoração, pequenas ferramentas de desenvolvimento, programação com orientação e rastreamento de dependências e comportamentos em grandes bases de código ficam do outro lado e podem ajudar muito
Críticas que se aplicam à geração cega de código são misturadas com facilidade demais a todos esses usos
A questão central, para começar, é quantos desses bugs surgiram em código escrito por LLMs. Criar 100 vezes mais bugs e corrigir 100 vezes mais não é motivo de orgulho
Como é um projeto open source, também é possível verificar diretamente se os bugs foram realmente criados por LLMs
Fico curioso para saber se o Chrome também corrigiu os bugs de rastreamento comportamental que tentam rastrear usuários onde quer que estejam e façam o que fizerem