A corrida de compras de segurança de navegadores em 2026 concentrou a maior parte dos investimentos em controles aplicados sobre o Google Chrome. Shioupyn Shen, fundador e CEO da CloudMosa, observa que esses controles ainda deixam o mecanismo de renderização do Chrome executando código web não confiável nos dispositivos dos funcionários.

No primeiro semestre de 2026, a CrowdStrike adquiriu a Seraphic, a Zscaler comprou a SquareX e a Akamai tomou a LayerX, além da compra da Talon pela Palo Alto Networks por US$ 625 milhões e a avaliação de US$ 4,85 bilhões da Island. Os produtos adquiridos funcionam por meio de extensões, sobreposições de políticas, instrumentação de tempo de execução e compilações reforçadas do Chromium, mas todos continuam a executar conteúdo web no endpoint.

Essa situação representa um problema de governança e também técnico. Segundo Shen, comprar de vários fornecedores disfarça uma dependência de um único mecanismo que nenhuma empresa controla. “Quando o gigante cair, você cai junto com ele”, explica. “O Chrome é uma base sólida, mas o setor inteiro está construindo sobre essencialmente a mesma base sem um Plano B significativo”.

Em fins de julho, a equipe de segurança do Chrome anunciou ter corrigido 1 072 vulnerabilidades nas versões 149 e 150, mais do que o total corrigido nas 23 versões anteriores combinadas. O Google atribui esse aumento ao uso de descoberta de vulnerabilidades com IA, correções geradas por máquinas e a um programa que lança duas atualizações de segurança por semana, apresentando o crescimento como prova de que o navegador fica mais seguro a cada versão.

Ferramentas mais avançadas encontram mais falhas, mas a preocupação também é quantos desses defeitos continuam sendo expostos. Um mecanismo de renderização de navegador precisa analisar e executar conteúdo proveniente de praticamente toda a internet, em grande parte não confiável, por isso, quando uma nova geração de scanners descobre bugs em ritmo muitas vezes superior ao anterior, surge também o questionamento sobre quanta execução vulnerável está sendo revelada — e se atacantes com capacidades semelhantes poderiam achar algumas delas primeiro.

Os agentes atacantes têm acesso às mesmas ferramentas de IA, reduzindo a experiência e o tempo necessários para explorar um grande código‑base em busca de falhas exploráveis. Um modelo de segurança que só funciona quando os defensores descobrem cada defeito primeiro se torna cada vez mais difícil de sustentar à medida que ambos os lados aceleram. Todos os produtos baseados no Chrome herdam a exposição se a descoberta de falhas supera o ciclo de correção do Google.

O investimento empresarial em segurança de navegadores divide‑se basicamente em duas categorias: controles que regem o comportamento do navegador e arquitetura que determina onde o código potencialmente vulnerável é executado. Detecção, filtragem de URL, prevenção de perda de dados e imposição de políticas fortalecem a primeira categoria, mas, em geral, deixam o ambiente de renderização do navegador operando no endpoint.

Parte desse dinheiro deveria ser usada para reduzir a quantidade de execução potencialmente vulnerável que chega ao dispositivo, com detecção, correção e políticas atuando sobre uma arquitetura concebida para limitar danos quando a prevenção falha. A escolha é entre gastar mais que os concorrentes com a arquitetura antiga ou superá-los com uma nova arquitetura, segundo Shen.

A CloudMosa adota essa visão com o Puffin Cloud Security, que executa conteúdo web remotamente em vez de no endpoint. “Imagine código vulnerável como um prisioneiro perigoso”, diz Shen. “A primeira pergunta que as pessoas fazem é quão forte é a cela. A questão mais fundamental é onde construir a cela. O Puffin Cloud Security coloca a prisão em um local onde o prisioneiro não pode alcançar o dispositivo, os dados ou os aplicativos do usuário”.

A arquitetura de navegador dividido do Puffin remonta a 2010 e foi utilizada em mais de 200 milhões de downloads. Originalmente, foi concebida para resolver um problema de desempenho em dispositivos com recursos limitados, e não um problema de segurança de navegadores. “Construímos o Puffin há 15 anos porque os dispositivos eram lentos”, relata Shen. “O que aprendemos nesse período é que a mesma arquitetura que solucionou problemas de desempenho também cria uma fronteira de segurança fundamentalmente diferente, essencial na era da IA”.

No modelo de navegador dividido, o componente de rasterização de tela no dispositivo processa cerca de 5% da carga de trabalho do navegador. O restante — renderização HTML, execução de scripts e outras tarefas — ocorre nos servidores da CloudMosa. Quando um usuário abre um site, o lado remoto carrega e renderiza a página e envia o resultado para o dispositivo, que exibe a imagem na tela. Um navegador Chrome comum, ou uma compilação reforçada do Chromium com controles adicionais, executa o mecanismo de renderização e o código da página no endpoint.

O cliente foi projetado como um host de bastião pequeno e reforçado, com pouco código e poucas funcionalidades para um atacante explorar. O renderizador na nuvem contém o código grande e rico em recursos onde se concentram as vulnerabilidades do navegador. O servidor envia a saída renderizada para o cliente em um formato PostScript, e essa troca foi concebida para que código malicioso que rode no renderizador na nuvem não tenha um caminho direto para executar no dispositivo.

Com informações de: VentureBeat AI