Aikido

Bug bounty não está morto, mas o modelo antigo está em colapso

Escrito por
Mackenzie Jackson

Bug bounty tem sido um tópico muito discutido ultimamente. 

Estamos vendo programas de alto perfil serem desativados ou mudarem fundamentalmente: o IBB (um dos programas mais importantes para projetos de código aberto) está pausando as submissões, o curl está removendo os pagamentos e o Node.js está eliminando sua recompensa por completo. Isso não é ruído, é um sinal. 

Eu queria entender para onde o bug bounty está realmente caminhando, então conversei com duas das vozes mais credíveis em lados opostos desta conversa:

  • Daniel Stenberg, criador do curl, que está vivenciando a realidade do mantenedor e recentemente suspendeu os pagamentos de bug bounty 
  • Casey Ellis, fundador da Bugcrowd, uma das pessoas que ajudaram a estabelecer o modelo.

O que descobri foi que o modelo de bug bounty está em uma encruzilhada, e estamos no meio de uma grande mudança. 

Por que o bug bounty funcionou tão bem

Antes de nos aprofundarmos para onde o modelo está caminhando, vamos dar um passo atrás e entender por que ele tem sido uma das ideias mais eficazes em segurança na última década.

Tudo isso deriva da ideia de deixar a internet tentar quebrar suas coisas antes que os atacantes o façam. E funcionou porque deu às empresas uma escala que elas nunca conseguiriam contratar.

Como Casey colocou:

Se você está tentando ser mais esperto que um grupo global de atacantes com alguém trabalhando das 9 às 5, a conta não fecha.”

Essa é a mágica do bug bounty. Em vez de depender de um punhado de pessoas internas, você acessa um grupo global com diferentes conjuntos de habilidades, perspectivas e motivações - todos atacando seu sistema de maneiras que sua equipe interna simplesmente não pensou. E isso sem os custos significativos necessários para contratar especialistas internamente. 

É por isso que se tornou fundamental para os programas de segurança modernos.

O que está quebrando agora

O que está mudando não é a demanda por segurança, mas sim a economia de como o bug bounty opera.

A IA alterou o equilíbrio, e não para melhor. Encontrar bugs agora é mais barato do que nunca, escrever relatórios é ainda mais fácil, e enviá-los tornou-se praticamente sem atrito. Enquanto isso, o custo de validar esses relatórios e realmente corrigir os problemas não mudou em nada.

  • Encontrar bugs → barato
  • Escrever relatórios → mais barato
  • Enviar relatórios → praticamente grátis
  • Validá-los → ainda caro
  • Corrigi-los → muito caro

Estamos vendo isso acontecer na prática. Existem três tipos de remetentes de relatórios. Há as empresas que usam uma nova abordagem para relatórios legítimos. Estes são relatórios que utilizam abordagens de IA em camadas que combinam os pontos fortes de múltiplos modelos de IA, guardrails, orquestração e contexto, como as próprias capacidades de pentest de IA da Aikido. Depois, há indivíduos que aprimoram sua pesquisa e escrita de relatórios com a IA como ferramenta. E, finalmente, há indivíduos que conseguem aprimorar suas habilidades por meio desses modelos de IA para gerar relatórios que parecem tecnicamente plausíveis, mas ainda estão completamente errados. 

Daniel descreveu-o perfeitamente: lixo mais convincente é pior do que lixo óbvio.

Você não pode descartá-lo rapidamente, precisa investigá-lo e desperdiça tempo real provando que é um absurdo.

Em escala, isso deixa de parecer um modelo de contribuição externa útil e começa a se assemelhar a algo mais próximo de um ataque de negação de serviço às pessoas responsáveis pela segurança. 

E o impacto é devastador:

  • O Internet Bug Bounty (IBB) pausou novas submissões porque a IA aumentou drasticamente o volume de descobertas além do que os mantenedores podem lidar.
  • Node.js perdeu sua recompensa quando o financiamento desapareceu; os relatórios ainda chegam, mas os pagamentos acabaram.
  • curl removeu as recompensas financeiras após ser inundado com relatórios gerados por IA.

Este é um problema antigo, amplificado 

Casey enfatizou que este não é um problema novo, é um problema antigo, apenas massivamente acelerado.

“Estamos fazendo coisas estúpidas mais rápido e com mais energia.”

O bug bounty sempre teve um problema com a igualdade de condições: uma pessoa envia um relatório e outra pessoa precisa validá-lo. Isso parece igual no papel, mas na prática, sempre foi difícil para uma pessoa acompanhar a validação, mesmo antes da existência da IA. Agora, é praticamente impossível.

Estamos agora em um mundo onde qualquer pessoa pode gerar dezenas de relatórios, fazê-los parecerem críveis e enviá-los instantaneamente. No entanto, do lado receptor, as restrições não mudaram. Ainda são humanos revisando, priorizando e tomando decisões.

O código aberto é o primeiro a sentir o impacto 

É no código aberto que essa pressão aparece primeiro, em grande parte porque já operava perto de seus limites. A maioria dos projetos é mantida por pequenas equipes, muitas vezes voluntários, com tempo e recursos limitados, mas eles sustentam grandes porções da internet.

Adicione incentivos financeiros, participação global e, agora, submissões geradas por IA, e o sistema fica sobrecarregado.

O programa IBB afirmou diretamente:

A descoberta assistida por IA alterou o equilíbrio entre as descobertas e a capacidade de remediação

Tradução:
Estamos encontrando mais bugs do que podemos lidar.

Então, agora a recompensa se foi, mas a expectativa de relatar permanece. Mas a questão é: a forma como os programas de bug bounty têm sido usados para escalar efetivamente as equipes de segurança e melhorar a postura de segurança ainda é viável sem incentivos financeiros?

Casey não acredita necessariamente nisso: 

Toda organização deveria ter um programa de divulgação de vulnerabilidades, porque se você está na internet, as pessoas encontrarão problemas. Mas nem toda organização está em posição de executar um programa de recompensa público e baseado em prêmios.

Em suas palavras, o curl provavelmente não deveria ter tido um para começar:

“Não acho que toda organização deveria [executar um programa de recompensas]… o programa curl não deveria ter sido um programa de recompensas em primeiro lugar.” 

E, no entanto, a experiência de Daniel mostra algo mais sutil. Daniel vê o programa de recompensas como um sucesso, porque incentivou um escrutínio real do código:

“Sempre pensei nisso como um sucesso porque é uma ótima maneira de realmente encorajar as pessoas a examinar o código…”

O que acontece quando você remove incentivos financeiros

Você presumiria que, ao remover os incentivos financeiros, você se livraria do AI slop, mas também reduziria a probabilidade de vulnerabilidades genuínas serem divulgadas. 

 Mas quando o curl removeu os incentivos financeiros, algo interessante aconteceu. O ruído de baixa qualidade, gerado por IA, desapareceu em grande parte. 

Ver postagem no Linkedin: https://www.linkedin.com/feed/update/urn:li:activity:7446667043996725249/

Daniel disse: “Paramos de receber relatórios de segurança AI slop… Em vez disso, recebemos uma quantidade cada vez maior de relatórios de segurança realmente bons… enviados com uma frequência nunca antes vista e que nos colocam sob uma carga séria.”

Em vez de se afogarem em relatórios de baixa qualidade, os mantenedores agora estão lidando com um alto volume de descobertas genuinamente úteis, muitas delas impulsionadas por pesquisas assistidas por IA. A barreira de entrada caiu, não apenas para relatórios ruins, mas também para os bons.

O que cria um novo tipo de pressão.

Mesmo relatórios de alta qualidade levam tempo para serem compreendidos, validados e corrigidos. E muitas dessas descobertas “boas” ainda caem em áreas cinzentas, bugs que podem não atender aos limites de segurança, mas que ainda exigem atenção. O resultado é uma carga sustentada, e de certa forma aumentada, sobre equipes já limitadas.

Então, de uma forma estranha, o sistema não foi aliviado. Ele foi refinado.

Quebrando o sistema para melhorá-lo

E é aqui que fica interessante. Porque, embora isso seja claramente doloroso a curto prazo, pode ser, na verdade, um passo na direção certa.

Ao remover os incentivos financeiros, eliminamos uma grande parte do ruído. O que resta é um sinal que é, em média, de maior qualidade, mais intencional e mais alinhado com os resultados reais de segurança.

Ao mesmo tempo, a IA está diminuindo a barreira para que pesquisadores realizem trabalhos significativos. Ela está permitindo que mais pessoas encontrem problemas reais, mais rapidamente do que nunca. Essa combinação: menos ruído, mais sinal, mas ainda um volume avassalador — sugere que estamos em uma fase de transição.

O modelo atual está cedendo sob a pressão. Mas o que está surgindo por baixo pode ser melhor.

Um sistema onde:

  • a divulgação é esperada, não incentivada
  • as recompensas são mais direcionadas, não amplas
  • e o foco muda de mais relatórios para melhores resultados

Ainda não chegamos lá. No momento, estamos no meio do caos, onde o modelo antigo não funciona mais e o novo ainda não se formou completamente.

Mas se isso se desenrolar corretamente, não terminaremos com menos bug bounty.

Acabamos com uma versão mais sustentável dele.

Hackers não vão a lugar nenhum 

Um dos maiores equívocos em tudo isso é a ideia de que, se o bug bounty enfrentar dificuldades, os hackers de alguma forma desaparecerão com ele.

Nunca é assim que funciona.

Hackers não param, eles se movem. Eles seguem oportunidades, complexidade e lacunas de entendimento. Quando uma área se torna saturada, eles mudam para outra, seja APIs, cadeias de suprimentos, ou agora, cada vez mais, sistemas de IA e falhas de lógica complexas.

Como Casey apontou, mesmo que resolvêssemos os problemas que temos hoje, os atacantes não simplesmente fariam as malas e iriam para casa. Sempre haverá novas tecnologias, novos sistemas e novos erros para explorar.

Enquanto humanos estiverem construindo software, haverá vulnerabilidades.

O que significa que a necessidade de pessoas para encontrá-las não desaparece.

No entanto, os bug bounty Hunters estão se afastando da função, em parte pela frustração de lidar com triagers esgotados, e em parte pelo incentivo financeiro que está sendo removido. Eles estão migrando para funções de consultoria e posições de pesquisa interna. 

O que acontece a seguir

O bug bounty não desaparece daqui, mas evolui.

O que provavelmente estamos caminhando é para um modelo onde a divulgação de vulnerabilidades se torna uma expectativa básica em toda a indústria, em vez de algo opcional ou incentivado. Programas de bounty públicos não desaparecem, mas se tornam mais controlados, mais direcionados e mais alinhados com a maturidade organizacional.

Ao mesmo tempo, a IA inevitavelmente desempenhará um papel maior na filtragem e triagem do volume crescente de relatórios. Ela não resolverá o problema completamente, mas se tornará parte de como o gerenciamos.

Também veremos uma mudança no que realmente é recompensado. À medida que os sistemas automatizados se tornam melhores em encontrar problemas de baixo nível, o valor dessas descobertas diminuirá. Em vez disso, os incentivos se moverão para trabalhos de maior impacto: o tipo que exige criatividade, contexto e um entendimento mais profundo dos sistemas. 

Isso significa que os pesquisadores se concentrarão cada vez mais em áreas como encadeamento de vulnerabilidades, exploração de lógica de negócios e quebra de tecnologias complexas ou emergentes onde a automação ainda tem dificuldades.

Em outras palavras, o nível está subindo, os pesquisadores não desaparecerão, mas as recompensas precisam se expandir igualmente. 

Compartilhar:

https://www.aikido.dev/blog/bug-bounty-isnt-dead

Assine para receber notícias

4.7/5
Cansado de falsos positivos?

Experimente Aikido como 100 mil outros.
Começar Agora
Obtenha um tour personalizado

Confiado por mais de 100 mil equipes

Agende Agora
Escaneie seu aplicativo em busca de IDORs e caminhos de ataque reais

Confiado por mais de 100 mil equipes

Iniciar Escaneamento
Veja como o pentest de IA testa seu aplicativo

Confiado por mais de 100 mil equipes

Iniciar Testes

Fique seguro agora

Proteja seu código, Cloud e runtime em um único sistema centralizado.
Encontre e corrija vulnerabilidades rapidamente de forma automática.

Não é necessário cartão de crédito | Resultados da varredura em 32 segundos.