O novo paradoxo da cybersecurity: descobrir falhas ficou mais fácil. Corrigi-las, não.

Durante décadas, convivemos com vulnerabilidades que ninguém havia descoberto. Agora, a IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → começa a mostrar o quanto essa aparente segurança era frágil.

Comecei a trabalhar com software quando os sistemas eram muito menores e menos complexos. Acompanhei a evolução das linguagens, dos sistemas operacionais e das ferramentas de teste. E aprendi uma lição que continua válida: um programa funcionar durante anos não significa que esteja livre de defeitos. Significa apenas que determinados problemas ainda não foram identificados.

Por isso, os resultados recentes dos modelos de fronteira em cybersecurity↳Segurança171 conteúdosCibersegurança no Brasil: 6 passos para sair da estagnaçãoDevSecOps · jul 2025O papel do CISO para transformar a cibersegurança em uma alavanca de reputação para as empresasDevSecOps · mar 2024Itaipu Parquetec e Exército Brasileiro realizam exercício de cibersegurança em BrasíliaDev (Back & Front) · set 2025Ver tudo em DevSecOps → me chamaram a atenção. Não porque os LLMs tenham adquirido compreensão humana do software, mas porque estamos diante de um avanço concreto na investigação de sistemas complexos.

Em março de 2026, a Anthropic divulgou que o Claude Opus 4.6 identificou 22 vulnerabilidades no Firefox, sendo 14 classificadas pela Mozilla como de alta severidade. Em abril, a Mozilla anunciou ter corrigido, no Firefox 150, outras 271 falhas identificadas com auxílio do Claude Mythos Preview.

Em novembro, a OpenAI apresentou os resultados de uma investigação automatizada do kernel Linux. Segundo a empresa, o sistema examinou 2.308 achados candidatos, reproduziu dinamicamente 1.724 vulnerabilidades e produziu 948 demonstrações funcionais de exploração para elevação local de privilégios, em ambiente controlado. O custo informado foi de aproximadamente US$ 1,21 milhão em créditos de API.

São números impressionantes, mas não diretamente comparáveis. Uma vulnerabilidade confirmada não significa exploração viável em qualquer ambiente, assim como uma demonstração de exploração local não equivale ao comprometimento remoto de uma empresa.

O avanço resulta da combinação entre modelos mais capazes e ambientes de investigação construídos ao seu redor. Durante o treinamento, os LLMs aprendem regularidades de linguagens de programação, estruturas de software e documentação técnica. Integrados a compiladores, depuradores e ferramentas de teste, podem examinar código, formular hipóteses e executar experimentos para verificar comportamentos suspeitos.

Esse conjunto de ferramentas e mecanismos de orquestração, chamado de harness, permite investigações iterativas e produção de evidências verificáveis. Seu desempenho depende tanto do modelo quanto da qualidade do ambiente e dos recursos computacionais disponíveis.

Há outro aspecto interessante. A Anthropic afirmou que não treinou explicitamente o Claude Mythos Preview para aquelas capacidades específicas de cybersecurity. Segundo a empresa, elas resultaram de melhorias gerais em programação, raciocínio e autonomia. Isso não significa ausência de conhecimento sobre segurança no treinamento, mas sugere que avanços gerais em engenharia de software podem ampliar capacidades especializadas de descoberta e exploração de vulnerabilidades.

A consequência que mais me interessa, entretanto, não é tecnológica. É econômica e organizacional.

Historicamente, encontrar vulnerabilidades complexas exigia especialistas, ferramentas sofisticadas e investigações demoradas. Essa dificuldade funcionava como barreira prática, embora nunca fosse garantia de segurança.

A automação começa a modificar essa relação entre esforço humano, recursos computacionais e resultados. Permite investigar mais código, beneficiando defensores, mas também potencialmente atacantes com acesso a capacidades semelhantes. Isso não implica uma explosão inevitável de ataques, pois a exploração real depende de condições específicas e controles defensivos. Mas modifica as premissas de risco.

E aqui aparece uma assimetria fundamental. Descobrir uma vulnerabilidade e corrigi-la são problemas muito diferentes.

A descoberta identifica um comportamento suspeito e demonstra seu potencial de risco. A correção exige compreender a causa, alterar o software, verificar efeitos sobre outros componentes e implantar a mudança sem comprometer a operação.

Nas empresas, isso envolve sistemas legados, integrações pouco documentadas, fornecedores, exigências regulatórias e aplicações que não podem simplesmente ser interrompidas.

A IA pode sugerir correções e gerar testes, mas uma alteração aparentemente correta pode introduzir novos defeitos. A dificuldade não está apenas em produzir a solução, mas em validá-la e implantá-la com segurança.

Conheço bem essa realidade. Uma vulnerabilidade é identificada, a equipe avalia sua gravidade, consulta fornecedores, verifica dependências, solicita aprovação e aguarda uma janela de manutenção.

Esses procedimentos têm justificativas legítimas. Uma correção mal executada pode provocar prejuízos relevantes. Mas, quando prolongam desnecessariamente a exposição, transformam uma questão técnica em decisão empresarial de risco.

Tenho visto empresas investirem em ferramentas sofisticadas enquanto convivem com inventários incompletos, aplicações sem responsáveis definidos e processos de correção lentos.

Suspeito que um dos próximos desafios da cybersecurity será administrar o volume crescente de descobertas. Será necessário validar achados, eliminar falsos positivos, avaliar possibilidades reais de exploração e priorizar correções.

Por isso, contar vulnerabilidades encontradas diz pouco sobre a segurança efetiva. Importa medir o tempo de exposição dos ativos críticos, as falhas exploráveis ainda abertas e a eficácia das medidas de mitigação.

Há também uma consequência arquitetural. Segurança não pode depender exclusivamente da eliminação de defeitos. Segmentação, isolamento, permissões mínimas, autenticação robusta, monitoramento e recuperação limitam as consequências de uma exploração bem-sucedida.

Isso é especialmente relevante para empresas com sistemas legados. Não considero correto afirmar que todo software antigo seja inseguro, mas tampouco podemos presumir segurança porque uma aplicação funciona há vinte anos sem incidentes conhecidos.

Quando a correção imediata não é viável, controles compensatórios precisam reduzir a exposição. E os próprios agentes utilizados nas investigações exigem proteção, pois podem acessar repositórios privados, documentação interna e informações sensíveis.

Mas o ponto central para a alta administração é que essa evolução modifica as decisões sobre cybersecurity.

Para CEOs e conselhos, vulnerabilidades relevantes representam exposições capazes de comprometer operações, receitas, contratos e reputação. A liderança precisa compreender quais processos críticos dependem de sistemas vulneráveis e quais riscos exigem decisões além da autoridade das equipes técnicas.

Às vezes, manter um sistema funcionando significa aceitar temporariamente uma exposição conhecida. Em outras situações, uma correção imediata pode representar risco operacional maior do que a vulnerabilidade. Essas escolhas exigem informações confiáveis, responsabilidades definidas e critérios explícitos de aceitação de riscos.

Para os CIOs, a prioridade é desenvolver capacidade de testar, validar e implantar mudanças com segurança, reduzindo dependências que transformam cada correção em um projeto complexo.

Para os CISOs, o desafio é traduzir vulnerabilidades em cenários de risco empresarial. A severidade técnica, isoladamente, não determina prioridade. É necessário considerar possibilidade de exploração, exposição, controles existentes e consequências para o negócio.

Para os CFOs, a questão é econômica. A automação pode reduzir custos de descoberta, mas não elimina despesas com validação, remediação, testes e eventuais interrupções. Isso exige avaliar investimentos em modernização, automação de testes, isolamento, detecção e recuperação segundo sua contribuição efetiva para reduzir riscos.

Indicadores como tempo de exposição de falhas exploráveis, concentração de riscos em processos críticos e capacidade comprovada de recuperação deveriam ganhar espaço nos relatórios à diretoria e ao conselho.

Os resultados recentes não demonstram nem de longe que os LLMs alcançaram inteligência geral ou compreendem software como especialistas humanos. Demonstram algo mais concreto: modelos de fronteira, combinados com ferramentas e verificação, conseguem automatizar parcelas crescentes de investigações técnicas complexas.

Identificar falhas antes que sejam exploradas representa uma oportunidade extraordinária. Mas é um erro imaginar que novas ferramentas de IA, isoladamente, resolverão os problemas de segurança empresarial.

Sem inventários confiáveis, arquitetura adequada, processos de remediação e critérios claros de priorização, poderão produzir mais relatórios do que proteção efetiva.

Essa evolução reforça uma convicção que venho defendendo há bastante tempo: cybersecurity não é apenas uma disciplina técnica. É uma capacidade permanente de gestão empresarial, com consequências sobre continuidade operacional, resultados financeiros e valor econômico.

O verdadeiro diferencial não será quantas vulnerabilidades a IA consegue encontrar, mas quanto tempo a empresa permanece exposta depois que elas são descobertas, e se sua liderança assume as decisões necessárias para reduzir essa exposição.