Depois do Mythos: por que bug bounties precisam de provas mais fortes

Há algumas semanas escrevi sobre Anthropic Mythos e Project Glasswing. Naquele momento, o foco era a linha geral: se os modelos realmente ficarem melhores em encontrar vulnerabilidades antigas, combinar caminhos de exploração e entender codebases inteiras, isso muda o vulnerability research.

O novo artigo da Sophos sobre bug bounties na era Mythos mostra agora o lado operacional disso.

A questão já não é apenas se a IA encontra vulnerabilidades melhores. A questão é se programas de bug bounty, times de security e organizações de engenharia conseguem distinguir rápido o suficiente entre lixo, alegações plausíveis e problemas reais de segurança.

O problema real não é só slop de IA

Quando se fala em IA e bug bounties, muita gente pensa logo em slop: reports gerados automaticamente, mensagens de erro mal compreendidas, cadeias de exploit inventadas, alegações não reproduzíveis e muito texto com pouca substância.

Isso é real. E é brutalmente irritante para maintainers, times de product security e pessoas de triagem.

Mas é só um lado.

O outro lado é mais perigoso: bons pesquisadores podem usar os mesmos modelos para encontrar vulnerabilidades reais mais rápido, testar hipóteses em codebases maiores e percorrer variantes de um padrão de forma sistemática. O que antes exigia dias ou semanas de trabalho manual pode, no futuro, chegar à fila em poucas horas.

Com isso, o problema muda. Antes a pergunta era muitas vezes: recebemos findings externos bons em quantidade suficiente? Hoje a pergunta tende a ser: conseguimos reconhecer, validar, priorizar e transformar em correções os findings reais rápido o bastante, enquanto o ruído também cresce?

Por que a Sophos é uma fonte interessante aqui

O artigo da Sophos não é um comentário genérico sobre IA. A Sophos olha para o próprio programa de bug bounty e cita números concretos.

Segundo a Sophos, o programa público roda na Bugcrowd desde dezembro de 2017. A empresa escreve que, até o momento do artigo, 1.343 vulnerabilidades foram recompensadas, com 7.091 submissões no total e 599.695 dólares em pagamentos.

Para 2025, a Sophos cita, entre outros pontos:

• 59.400 dólares pagos por mais de 52 reports
• cerca de 420 pesquisadores envolvidos
• até 80.000 dólares para Intercept X Endpoint sob certas condições
• até 50.000 dólares para Sophos Central
• até 50.000 dólares para Sophos Firewall
• 13 bugs válidos no Sophos Firewall em 2025, com 21.500 dólares de pagamento total
• 13 bugs válidos no Sophos Central em 2025, com 11.650 dólares de pagamento total

Não são números astronômicos, e exatamente por isso são interessantes. Eles mostram quanto trabalho de separação existe por trás de um programa relativamente maduro. Milhares de submissões não significam automaticamente milhares de problemas de segurança relevantes. E a IA provavelmente não vai aliviar essa proporção.

Vai torná-la mais dura.

Reprodutibilidade vira o ingresso

A consequência mais importante, na minha visão, é banal, mas desconfortável: um security report sem boa reprodutibilidade vai valer menos.

Não porque os times de triagem sejam preguiçosos. Mas porque o tempo deles fica mais escasso.

Se um report afirma mostrar uma remote code execution, um bypass de autenticação ou um vazamento crítico de dados, ele precisa provar claramente:

• qual versão é afetada
• qual configuração é necessária
• quais privilégios o atacante precisa
• quais passos levam de forma reproduzível ao resultado
• quais logs, requests, traces ou screenshots sustentam a alegação
• qual impacto foi de fato demonstrado
• onde fica a fronteira entre hipótese e prova

Isso soa rígido. E é. Mas é exatamente o que será necessário para que security teams não se afoguem em textos plausíveis.

Um report gerado por IA pode parecer muito convincente no texto. Pode citar código, formular como se fosse uma CVE e fingir uma estrutura limpa. Isso não o torna verdadeiro. Por outro lado, um report curto e seco com um bom proof of concept pode ser extremamente valioso.

A nova moeda não é a formulação. A nova moeda é a evidência.

IA torna bugs de autorização especialmente desagradáveis

Um ponto no artigo da Sophos me parece especialmente prático: a IA pode ajudar a escalar um bypass de autorização encontrado para superfícies de escopo maiores.

Isso combina com o que se vê em ambientes SaaS reais. Autorização raramente é um único interruptor. Ela vive em papéis, tenants, IDs de objetos, subdomínios, versões de API, superfícies administrativas, endpoints móveis, rotas legadas e funcionalidades migradas pela metade.

Quando um pesquisador encontra um padrão, a IA pode ajudar a testar sistematicamente suas variações:

• O bypass vale só para um endpoint ou para uma família inteira de endpoints?
• Ele funciona só em um tenant ou também entre tenants?
• A mesma lógica existe em APIs antigas e novas?
• Papéis de admin e usuário estão realmente separados em todos os lugares?
• Um objeto pode ser carregado por ID direto, mesmo que a UI não o mostrasse?

É exatamente aí que a IA se torna perigosamente útil. Não como hacker mágico, mas como acelerador de testes chatos, amplos e sistemáticos.

E isso é ruim para organizações cuja segurança depende muito do fato de ninguém ter tempo suficiente para testar todas as variantes chatas.

Bug bounty não é caixa postal de PR

Muitas empresas ainda tratam bug bounties quase como tema de imagem: temos um programa, então somos abertos, modernos e security-minded.

Isso já não basta.

Um programa de bug bounty é um sistema de produção. Precisa de regras claras, boa triagem, reprodução técnica, proximidade com o produto, responsabilidade de engenharia e conexão com incident response. Caso contrário, vira apenas uma caixa postal pública onde pesquisadores externos, slop de IA e atacantes reais entram pela mesma porta.

A Sophos junta dois pontos desconfortáveis no artigo:

Primeiro: bons pesquisadores ajudam. Visão externa, outros modelos mentais e pressão contínua são valiosos.

Segundo: um sistema com dinheiro e confiança também pode ser abusado. A Sophos menciona experiências em torno de Pacific Rim, Asnarök e Personal Panda, em que a proximidade temporal entre exploração ativa e reports de bug bounty posteriores levantou pelo menos perguntas. A Sophos não diz explicitamente que todo report desse tipo era malicioso. Mas o ponto operacional permanece: um programa de bug bounty não pode ser ingênuo.

Em termos concretos:

• Reports precisam ser correlacionados com telemetria.
• Um novo finding também deve poder acionar threat hunts retroativas.
• A triagem precisa saber se tentativas de exploit semelhantes já estavam visíveis.
• A reputação do pesquisador ajuda, mas não substitui verificação técnica.
• Safe harbor é importante, mas não substitui detecção de abuso.

Essa é a realidade sóbria: bug bounties fazem parte de Secure by Design, não são substituto para ele.

Provas mais fortes também significam responsabilidade maior

Existe aqui uma tensão que não deveria ser suavizada.

Historicamente, pesquisadores ouvem com frequência: parem cedo o suficiente. Mostrem o bug, mas não aprofundem demais. Não toquem em dados de clientes. Nada de movimento lateral. Nada de ações destrutivas.

Isso está certo.

Ao mesmo tempo, o peso da prova vai aumentar. Se a IA gerar em massa reports plausíveis, mas falsos, programas vão exigir mais evidência. Surge então a pergunta difícil: como um pesquisador pode provar melhor o impacto sem cair em comportamento perigoso?

A resposta não pode ser: “façam simplesmente mais”. A resposta precisa ser mais controlada:

• rules of engagement mais claras
• ambientes de teste dedicados
• caminhos seguros de reprodução
• limites acordados para prova de impacto
• melhores sistemas de sandbox e lab
• replays automatizados de proofs of concept

Para fabricantes maiores, isso se torna quase obrigatório. Quem paga bounties altos deveria ter infraestrutura para validar reports de forma limpa e rápida.

Para projetos menores, é mais amargo. Eles recebem a mesma onda de slop, mas não os mesmos recursos. Exatamente por isso alguns projetos vão reduzir bug bounties financeiros ou desligá-los completamente. Não porque não levem segurança a sério, mas porque operar o programa se torna um peso.

O que admins e MSPs podem aprender

Alguém poderia dizer: isso afeta só fabricantes e programas Bugcrowd.

Eu não acredito nisso.

O mesmo mecanismo atinge MSPs, times internos de TI e responsáveis por segurança. Em todo lugar onde findings externos ou internos precisam ser avaliados, a pressão aumenta:

• Scanners entregam mais findings.
• Assistentes de IA explicam findings de forma mais convincente.
• Desenvolvedores trazem notas de security geradas por IA.
• Clientes perguntam sobre CVEs antes de conhecer o contexto.
• A gestão quer saber se o risco é real ou apenas barulhento.

A resposta prática não é ignorar tudo. A resposta é um processo de validação mais duro.

Para mim, pelo menos estas perguntas fazem parte:

1. O problema é reproduzível?
2. O escopo afetado está claro?
3. Existe um caminho realista de ataque?
4. O impacto está tecnicamente comprovado ou apenas alegado?
5. Há logs ou telemetria que poderiam mostrar exploração?
6. A correção é patch, configuração, workaround ou só remendo?
7. É necessário buscar retroativamente se isso já foi explorado?

Parece mais trabalho. E é. Mas é um trabalho melhor do que reagir com pressa a cada report bem escrito.

Por que isso combina bem com Mythos

O ponto decisivo de Mythos, para mim, nunca foi apenas: “uau, um modelo encontra bugs”.

O ponto era: se essas capacidades se tornarem mais reais, o tempo entre encontrar, entender, reproduzir e explorar diminui. É exatamente aí que programas de bug bounty são atingidos. Eles ficam na interseção entre pesquisa, potencial ofensivo, engenharia e responsabilidade.

A Sophos formula algo parecido no próprio artigo: a questão não é como parar submissões de IA. A questão é como preservar confiança e sinal quando boa pesquisa e ruído podem ser produzidos em velocidade de máquina.

Para mim, essa é a síntese mais limpa do problema.

Nem toda organização precisa de um grande programa próprio de bug bounty. Mas toda organização precisa de mecanismos melhores para verificar alegações técnicas. Porque o fluxo de informações de segurança não vai diminuir. Ele vai ficar mais rápido, mais alto e mais bem escrito.

Minha leitura

Vejo o artigo da Sophos como um bom follow-up de Mythos, porque ele leva o debate da sala dos modelos para a sala de operações.

Mythos é o sinal espetacular. A triagem de bug bounty é a bancada onde se vê se os processos de segurança conseguem acompanhar.

Minha tese é simples:

• Quem apenas coleta mais reports vai perder.
• Quem exige evidência reproduzível vai priorizar melhor.
• Quem conecta bug bounty, telemetria, engenharia e incident response vai reagir mais rápido.
• Quem entende IA apenas como gerador de texto subestima seu valor para trabalho sistemático de segurança.
• Quem não filtra slop de IA queima o tempo das pessoas que deveriam resolver problemas reais.

Isso soa menos glamouroso do que um modelo frontier encontrando zero-days. Mas é exatamente aí que se decide se o ganho de segurança chega aos defensores ou se todos afundam em mais ruído.

Até a próxima,
Joe