Os programas de recompensa por falhas têm sido um tema muito em voga ultimamente.
Estamos a assistir ao encerramento ou a mudanças profundas em programas de grande visibilidade: o IBB (um dos programas mais importantes para o software de código aberto) suspendeu as submissões, o curl está a eliminar os pagamentos e o Node.js está a eliminar completamente o seu programa de recompensas. Isto não é ruído, é um sinal.
Queria perceber para onde é que o programa de recompensas por bugs está realmente a caminhar, por isso conversei com duas das vozes mais credíveis de lados opostos neste debate:
- Daniel Stenberg, criador do curl, que está a viver a realidade de um mantenedor e recentemente suspendeu os pagamentos do programa de recompensa por bugs
- Casey Ellis, fundador da Bugcrowd, uma das pessoas que ajudou a estabelecer o modelo.
O que descobri foi que o modelo de recompensas por falhas de segurança encontra-se numa encruzilhada e que estamos no meio de uma grande mudança.
Por que é que o programa de recompensas por falhas funcionou tão bem
Antes de abordarmos o rumo que este modelo está a tomar, vamos dar um passo atrás e compreender por que razão tem sido uma das ideias mais eficazes no domínio da segurança ao longo da última década.
Tudo parte da ideia de deixar que a Internet tente atacar os seus sistemas antes que os atacantes o façam. E funcionou porque proporcionou às empresas uma escala que nunca teriam conseguido alcançar por conta própria.
Como disse o Casey:
“«Se estás a tentar ser mais esperto do que um grupo global de atacantes com alguém a trabalhar das 9 às 5, a conta não bate certo.»
É essa a magia dos programas de recompensa por falhas de segurança. Em vez de depender de um pequeno grupo de colaboradores internos, recorre-se a um conjunto global de competências, perspetivas e motivações diversas — todos a testar o seu sistema de formas que a sua equipa interna simplesmente não teria imaginado. E tudo isto sem os custos significativos associados à contratação de especialistas internos.
É por isso que se tornou fundamental para os programas de segurança modernos.
Notícias de última hora
O que está a mudar não é a procura por segurança, mas sim a dinâmica económica do funcionamento dos programas de recompensa por falhas.
A IA alterou o equilíbrio, e não para melhor. Detectar erros é agora mais barato do que nunca, redigir relatórios é ainda mais fácil e o seu envio tornou-se, na prática, um processo sem complicações. Entretanto, o custo de validar esses relatórios e de resolver efetivamente os problemas não se alterou de todo.
- Detectar erros → barato
- Elaboração de relatórios → mais barato
- Envio de relatórios → basicamente gratuito
- Validá-los → continua a ser dispendioso
- Reparar → muito caro
Estamos a assistir a isto na prática. Existem três tipos de autores de relatórios. Por um lado, há as empresas que adotam uma nova abordagem para relatórios legítimos. Trata-se de relatórios que utilizam abordagens de IA em camadas, combinando os pontos fortes de vários modelos de IA, mecanismos de proteção, orquestração e contexto, como pentest de IA próprias pentest de IA Aikido. Depois, há indivíduos que aprimoram a sua investigação e a elaboração de relatórios utilizando a IA como ferramenta. E, finalmente, há indivíduos que conseguem aperfeiçoar as suas competências graças a estes modelos de IA, para gerar relatórios que parecem tecnicamente plausíveis, mas que continuam a estar completamente errados.
O Daniel descreveu-o na perfeição: uma treta mais convincente é pior do que uma treta óbvia.
Não se pode descartar isso de imediato; é preciso investigar e acaba-se por perder tempo a provar que é um disparate.
Em grande escala, isto deixa de parecer um modelo útil de contribuição externa e começa a assemelhar-se mais a um ataque de negação de serviço contra os responsáveis pela segurança.
E o impacto é devastador:
- O Internet Bug Bounty (IBB) suspendeu o envio de novas propostas porque a IA aumentou drasticamente o volume de descobertas, ultrapassando a capacidade de gestão dos responsáveis pela manutenção
- O Node.js perdeu o seu programa de recompensas quando o financiamento acabou; continuam a chegar denúncias, mas já não há pagamentos
- A Curl eliminou as recompensas financeiras após ter sido inundada com relatórios gerados por IA
Este é um problema antigo, que se agravou
Casey salientou que este não é um problema novo; é um problema antigo, apenas que se agravou enormemente.
«Estamos a fazer coisas estúpidas mais depressa e com mais energia.»
Os programas de recompensa por falhas sempre tiveram um problema em termos de equilíbrio: uma pessoa envia um relatório e outra tem de o validar. No papel, isso parece equitativo, mas, na prática, sempre foi difícil para uma única pessoa dar conta da validação, mesmo antes da existência da IA. Agora, é praticamente impossível.
Vivemos hoje num mundo em que qualquer pessoa pode gerar dezenas de relatórios, fazê-los parecer credíveis e enviá-los instantaneamente. Do lado de quem os recebe, porém, as limitações não mudaram. Continuam a ser pessoas que analisam, classificam e tomam decisões.
O software de código aberto é o primeiro a sentir o impacto
É no código aberto que esta pressão se manifesta primeiro, em grande parte porque já funcionava perto dos seus limites. A maioria dos projetos é mantida por pequenas equipas, muitas vezes compostas por voluntários, com tempo e recursos limitados, mas que sustentam grande parte da Internet.
Junte a isso incentivos financeiros, participação global e, agora, contribuições geradas por IA, e o sistema fica sobrecarregado.
O programa IBB foi direto ao ponto:
A descoberta assistida por IA alterou o equilíbrio entre as descobertas e a capacidade de correção
Tradução:
Estamos a encontrar mais erros do que conseguimos resolver.
Assim, agora que o prémio desapareceu, a expectativa de que se continuem a comunicar falhas mantém-se. Mas a questão é: será que a forma como os programas de recompensas por falhas têm sido utilizados para expandir eficazmente as equipas de segurança e melhorar a postura de segurança continua a ser viável sem incentivos financeiros?
Casey não acredita necessariamente nisso:e:
Todas as organizações devem ter um programa de divulgação de vulnerabilidades, porque, se estiverem na Internet, as pessoas irão encontrar falhas. Mas nem todas as organizações estão em condições de implementar um programa de recompensas público.
Segundo ele, o curl provavelmente nem devia ter tido um, para começar:
«Não acho que todas as organizações devam [ter um programa de recompensas]… o programa do curl nem sequer devia ter sido um programa de recompensas.»
No entanto, a experiência de Daniel revela uma realidade mais matizada. Daniel considera o programa de recompensas um sucesso, porque incentivou uma análise rigorosa do código:
«Sempre considerei isso um sucesso, porque é uma excelente forma de incentivar as pessoas a analisarem o código...»
O que acontece quando se eliminam os incentivos financeiros
Seria de esperar que, ao eliminar os incentivos financeiros, se acabasse com as práticas de má qualidade na IA, mas também se reduzisse a probabilidade de que vulnerabilidades reais fossem divulgadas.
Mas quando o Curl eliminou os incentivos financeiros, aconteceu algo interessante. O ruído de baixa qualidade gerado pela IA desapareceu quase por completo.
Daniel disse: «Deixámos de receber relatórios de segurança de má qualidade gerados por IA… 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, o que nos coloca sob uma carga de trabalho considerável.»
Em vez de se virem sobrecarregados com relatórios de baixa qualidade, os responsáveis pela manutenção lidam agora com um grande volume de conclusões verdadeiramente úteis, muitas das quais resultam de investigação apoiada por IA. A barreira à entrada diminuiu, não só para os relatórios de má qualidade, mas também para os de boa qualidade.
O que cria um novo tipo de pressão.
Mesmo os relatórios de alta qualidade levam tempo a compreender, validar e corrigir. E muitas dessas «boas» conclusões continuam a situar-se em zonas cinzentas: erros que podem não atingir os limiares de segurança, mas que ainda assim requerem atenção. O resultado é uma carga de trabalho contínua e, em alguns aspetos, crescente, sobre equipas já sobrecarregadas.
Assim, de uma forma estranha, o sistema não foi simplificado. Foi aperfeiçoado.
Quebrar o sistema para o melhorar
E é aqui que a coisa fica interessante. Porque, embora isto seja claramente doloroso a curto prazo, pode, na verdade, ser um passo na direção certa.
Ao eliminar os incentivos financeiros, eliminamos grande parte do ruído. O que resta é um sinal que é, em média, de melhor qualidade, mais intencional e mais alinhado com os resultados reais em matéria de segurança.
Ao mesmo tempo, a IA está a reduzir as barreiras que impedem os investigadores de realizar um trabalho significativo. Está a permitir que mais pessoas identifiquem problemas reais, mais rapidamente do que nunca. Essa combinação — menos ruído, mais sinal, mas ainda assim um volume avassalador — sugere que nos encontramos numa fase de transição.
O modelo atual está a ceder sob a pressão. Mas o que está a surgir por baixo dele poderá ser melhor.
Um sistema em que:
- espera-se que haja transparência, não que esta seja incentivada
- as recompensas são mais específicas, não genéricas
- e o foco passa de mais relatórios para melhores resultados
Ainda não chegámos lá. Neste momento, estamos numa fase de transição complicada, em que o modelo antigo já não funciona e o novo ainda não está totalmente definido.
Mas, se tudo correr como previsto, não acabaremos por ter menos recompensas por erros.
Acabamos por ficar com uma versão mais sustentável do mesmo, .
Os hackers não vão desaparecer
Um dos maiores equívocos em tudo isto é a ideia de que, se os programas de recompensa por bugs enfrentam dificuldades, os hackers desaparecem de alguma forma com eles.
Não é assim que as coisas funcionam.
Os hackers não param, eles mudam de estratégia. Aproveitam as oportunidades, a complexidade e as lacunas no conhecimento. Quando uma área fica saturada, eles passam para outra, quer se trate de APIs, cadeias de abastecimento ou, cada vez mais, sistemas de IA e falhas de lógica complexas.
Como Casey salientou, mesmo que resolvêssemos os problemas que temos hoje, os atacantes não iriam simplesmente fazer as malas e ir embora. Haverá sempre novas tecnologias, novos sistemas e novos erros para explorar.
Enquanto os seres humanos continuarem a criar software, haverá vulnerabilidades.
O que significa que a necessidade de as pessoas as encontrarem não desaparece.
No entanto, hunters de recompensas por falhas hunters a abandonar esta atividade, em parte devido à frustração que sentem ao lidar com triadores esgotados e, em parte, devido à retirada dos incentivos financeiros. Em vez disso, estão a optar por funções de consultoria e cargos de investigação interna.
O que acontece a seguir
Os programas de recompensa por falhas não desaparecem, mas evoluem.
O que provavelmente nos espera é um modelo em que a divulgação de vulnerabilidades se torne uma expectativa básica em todo o setor, em vez de algo opcional ou incentivado. Os programas públicos de recompensas não desaparecem, mas tornam-se mais controlados, mais direcionados e mais alinhados com a maturidade organizacional.
Ao mesmo tempo, a IA irá inevitavelmente desempenhar um papel mais importante na filtragem e triagem do volume crescente de denúncias. Não resolverá o problema por completo, mas passará a fazer parte da forma como o gerimos.
Veremos também uma mudança no que é efetivamente recompensado. À medida que os sistemas automatizados se tornam mais eficazes na deteção de problemas de baixo nível, o valor dessas descobertas diminuirá. Em vez disso, os incentivos passarão a incidir sobre trabalhos de maior impacto: aqueles que exigem criatividade, contexto e uma compreensão mais profunda dos sistemas.
Isso significa que os investigadores irão concentrar-se cada vez mais em áreas como o encadeamento de vulnerabilidades, a exploração da lógica de negócio e a quebra de tecnologias complexas ou emergentes, onde a automatização ainda enfrenta dificuldades.
Por outras palavras, o nível de exigência está a subir; os investigadores não vão desaparecer, mas as recompensas têm de aumentar na mesma proporção.
