Estamos encerrando o programa de bug bounty
(turso.tech)- A Turso encerrou o bug bounty que pagava US$ 1.000 por bugs com prova de corrupção de dados, após operá-lo por cerca de um ano
- Com a recompensa em dinheiro, houve uma enxurrada de PRs de baixa qualidade gerados por IA, e os mantenedores passaram dias gastando tempo para fechá-los
- No início, a empresa recompensou 5 pessoas, e algumas contribuições levaram a melhorias no simulador e à descoberta de mais de 10 bugs no SQLite
- A Turso chegou a usar um sistema de endosso para fechar automaticamente PRs suspeitos, mas bots passaram a repetir pedidos de revisão manual e a reenviar PRs semelhantes
- Para manter as contribuições abertas, a Turso escolheu remover o incentivo financeiro em vez de fechar o sistema
Por que a Turso interrompeu o bug bounty
- A Turso pagou US$ 1.000 por bugs capazes de demonstrar potencial corrupção de dados por quase um ano, mas agora está encerrando o programa
- Depois que a recompensa financeira foi criada, o repositório da Turso foi inundado por PRs de baixa qualidade gerados por IA, e os mantenedores passaram dias dedicando a maior parte do tempo a fechar esse tipo de PR
- A Turso quer continuar sendo um projeto aberto a contribuições, mas entende que pagar por um tipo específico de bug tornou a operação de contribuições abertas quase inviável
- A decisão foi divulgada com o reconhecimento de que todos ainda precisam aprender juntos a estabelecer a governança de código aberto nesta nova era
O contexto do lançamento do programa
- A Turso está reimplementando o SQLite, conhecido como um dos softwares mais confiáveis do mundo, e por isso precisa manter um padrão de confiabilidade igualmente alto
- Para alcançar ou superar o nível de confiabilidade do SQLite, a Turso opera vários sistemas de teste
- simulador determinístico nativo
- vários fuzzers
- mecanismo de teste diferencial baseado em oráculo, comparando com o SQLite
- simulador de concorrência
- execução extensiva no Antithesis
- A infraestrutura de testes também é software e, portanto, não é perfeita; ela só consegue encontrar bugs dentro das combinações que seus geradores realmente produzem
- Por exemplo, se um fuzzer não criar índices, fica difícil encontrar bugs relacionados a índices, mesmo estressando fortemente outras partes do sistema
- A Turso encontrou um bug que só aparecia quando o banco de dados tinha mais de 1 GB, mas como injetava falhas agressivamente em cada execução, o banco não conseguia crescer até esse tamanho e o bug escapava do simulador
- relacionado: Uma aventura escrevendo sistemas compatíveis
- Uma vantagem dos testes automatizados é que, mesmo quando um bug escapa uma vez, melhorar o gerador de testes pode eliminar uma categoria inteira de bugs
- O bug bounty existia para demonstrar confiança na metodologia de testes da Turso e, ao mesmo tempo, recompensar quem encontrasse áreas que o simulador não cobria bem
- O plano inicial era pagar US$ 1.000 por bugs de corrupção de dados até o lançamento do Turso 1.0 e, depois disso, ampliar gradualmente o valor e o escopo das recompensas
Resultados antes do aumento de submissões ruins geradas por IA
- No início do programa, um total de 5 pessoas recebeu recompensa, e elas contribuíram de forma significativa para o projeto
- Alperen foi um dos principais contribuidores do simulador da Turso e sabia onde ele podia ser melhorado
- Mikael usou LLMs de forma criativa para encontrar casos que o simulador não alcançava e depois foi contratado pela Turso
- Pavan Nambi combinou o simulador com métodos formais e encontrou não só bugs na Turso, mas também mais de 10 bugs no próprio SQLite
A carga operacional causada por submissões geradas por IA
- O tipo de submissão que a Turso queria não era apenas apontar um bug, mas estender o simulador para demonstrar um bug de corrupção de dados
- Essa exigência fez com que PRs maliciosos em busca de recompensa fossem raros, e também não havia muitos bugs reais de corrupção de dados
- Depois, passaram a surgir em grande volume submissões instruindo LLMs a encontrar bugs na Turso e ganhar a recompensa
- Quando recebiam esse tipo de instrução, os LLMs produziam algum tipo de saída, mas isso era diferente de ela ser válida
Exemplos representativos de submissões ruins
-
PR que corrompia manualmente o cabeçalho do banco de dados
- PR #6257 inseria manualmente bytes de lixo no cabeçalho do banco e então alegava que o banco havia sido corrompido
- Mesmo depois de um mantenedor apontar que esse era o resultado esperado, o autor ou bot continuou com longas respostas no estilo de LLM
-
Submissão que inseria acesso out-of-bound diretamente no código-fonte
- Outra submissão adicionava manualmente um acesso a array fora dos limites no código-fonte para corromper o banco de dados
- issue relacionada: tursodatabase/turso#5508
-
PR que tratava execução de SQL como vulnerabilidade
- PR #4322 estava cheio de tabelas, marcas de verificação verdes e travessões, e alegava ter encontrado uma vulnerabilidade crítica que permitia executar instruções SQL arbitrárias
- A Turso entende que o fato de um banco de dados SQL permitir a execução de instruções SQL não pode, por si só, ser considerado uma vulnerabilidade
-
PR que interpretava errado a funcionalidade de escrita concorrente da Turso
- PR #6874 ativava a escrita concorrente, um dos diferenciais da Turso, e mostrava que o SQLite não conseguia abrir o arquivo até que o modo de journal fosse revertido para WAL e a escrita concorrente fosse desativada
- Esse era o comportamento esperado do sistema, conforme projetado
-
Submissão cuja intenção era difícil de entender
- Outra submissão tinha um conteúdo difícil de interpretar
- O mantenedor Mikael concluiu que o autor havia visto o anúncio da recompensa e direcionado uma ferramenta de geração por IA para a Turso
Última resposta: sistema de endosso
- Como última tentativa de restaurar a ordem, a Turso projetou e implementou um sistema de endosso
- A ideia era fechar automaticamente submissões suspeitas de terem vindo de bots, e por um tempo isso funcionou razoavelmente bem
- Depois, os bots passaram a abrir issues pedindo revisão manual, contestando o motivo do fechamento dos PRs
- Em vários casos, após um PR ser fechado, o mesmo usuário ou outro usuário reabria imediatamente um PR idêntico ou muito parecido
O conflito entre contribuições abertas e incentivos financeiros
- Quem produz submissões de baixa qualidade pode gastar cerca de 1 minuto para gerá-las, mas a Turso precisa gastar horas para ler, entender e responder
- Esse tipo de submissão pode ser gerado a uma velocidade praticamente infinita
- É possível criar sistemas automatizados de controle, mas quando há uma recompensa financeira não desprezível, a IA continua tendo incentivo para discutir e reenviar o mesmo PR repetidamente
- A Turso valoriza sua comunidade de contribuidores de código aberto e continuará fortalecendo-a, mas no momento entende que nenhuma forma de incentivo financeiro funciona bem em sistemas abertos
- As opções são fechar o sistema ou remover o incentivo, e por enquanto a Turso escolheu a segunda alternativa
1 comentários
Opiniões do Hacker News
Isso mostra que o gargalo não está em escrever código, mas em ler e entender o código
Antigamente também sempre havia em algum time um engenheiro “produtivo” que abria PRs enormes cheios de refatorações em larga escala, independentemente de serem necessárias ou não. Isso já acontecia antes mesmo de alguém imaginar que redes neurais poderiam gerar tanto código assim
O resultado dessa “produtividade” não era acelerar o time, mas quase paralisá-lo. Ou todo mundo gastava o tempo revisando o PR com cuidado, ou davam um LGTM superficial e depois explodia em produção, obrigando todos a voltar para a prancheta. Além disso, por causa da “produtividade” dessa pessoa, a estrutura do projeto mudava rápido demais, e a única pessoa que sabia claramente onde ficava cada coisa era justamente aquela “pessoa muito inteligente, talentosa, produtiva e leal aos objetivos da empresa”
“Em quase toda organização de desenvolvimento de software, existe pelo menos um desenvolvedor que leva a programação tática ao extremo. É o tornado tático. O tornado tático é um programador prolífico, que produz código muito mais rápido que os outros, mas trabalha de forma totalmente tática. Quando se trata de implementar rapidamente uma funcionalidade, ninguém o supera. Em algumas organizações, gestores tratam o tornado tático como um herói. Mas o tornado tático deixa um rastro de destruição. Os engenheiros que depois precisam trabalhar nesse código muitas vezes não o veem como herói. Em geral, são outros engenheiros que precisam limpar a bagunça deixada pelo tornado tático, e por isso esses verdadeiros heróis acabam parecendo avançar mais devagar que o tornado tático.”
Além disso, quanto mais código gerado por IA houver, menos gente de fato vai entender esse código
Ainda assim, se os testes de regressão e o linter estiverem bem montados, e você souber que o código funciona e não está uma porcaria, a revisão deveria focar mais na qualidade geral em alto nível do que em examinar a precisão de cada caractere. Claro, a revisão em si continuou sendo dolorosa
Naturalmente, acabei lendo e entendendo mais código do que escrevendo, e às vezes meu número de linhas escritas era negativo, do que eu até me orgulhava
Agora, graças à IA, escrevo ainda menos código, e desisti do sonho de tirar satisfação disso. A habilidade de entender rapidamente grandes volumes de código de origem suspeita, seja feito por máquina ou por pessoa, espero que continue valiosa até eu me aposentar, especialmente com ajuda de IA. O que vocês acham?
Nós não escrevemos só código para a máquina executar, mas também código para pessoas lerem. Revisão de código, depuração e mudanças futuras envolvem alguém lendo e entendendo o código escrito por outra pessoa. E até existir uma IA que possa ser responsabilizada por suas ações, não dá para delegar esse entendimento a ela
É um ótimo momento para mencionar este excelente projeto, um repositório honeypot para atrair bots
https://github.com/UnsafeLabs/Bounty-Hunters
O ranking correspondente está aqui
https://clankers-leaderboard.pages.dev
Fico curioso para saber o que acontece se IAs treinarem nesses repositórios e nas atividades dentro deles. Os relatórios de bug nas issues são problemas reais que podem ser corrigidos ou delírios inventados?
Só que tem grande chance de em breve entrar em uma blocklist de bots de IA
Fechar o programa é totalmente razoável. Mas há outras opções. Dá para fazer o autor do envio pagar uma pequena taxa e receber o dinheiro de volta caso um bug real seja encontrado
Não importa se o programa realmente paga recompensas. Se um único relatório for encerrado indevidamente, essa história vai se repetir para sempre
Nesses casos, hoje você já perde tempo; no futuro, passaria a perder dinheiro também
Principalmente em empresas pequenas, não dá para saber antes do envio como a empresa vai reagir
Talvez fosse possível exigir a execução completa da suíte de testes do simulador antes do envio? Seria uma boa verificação de que o autor não quebrou o simulador e, de quebra, poderia gerar um artefato de prova de trabalho. Não sei se isso é viável, porque não entendo muito da parte de segurança
Passei mais de um ano tentando fazer o TursoDB carregar um único arquivo, mas não consegui: https://github.com/ClickHouse/ClickBench/issues/336
Fico imaginando como estaria o Hacktoberfest hoje se ainda desse camiseta para todo mundo. Provavelmente não haveria algodão suficiente no mundo
Não deveria ser responsabilidade de mantenedores individuais impedir isso; GitHub e GitLab é que deveriam barrar essas contas antes mesmo de elas chegarem ao ponto de poder abrir PRs. Isso é essencialmente spam
Veja o usuário que fez o PR mencionado primeiro no texto: https://github.com/Samuelsills. Contas assim não deveriam nem chegar perto de abrir PRs em repositórios populares
Posso estar fazendo uma pergunta boba por não conhecer bem a área, mas se fosse exigida no final a execução completa dos testes do simulador para verificar que a mudança enviada não quebrou funcionalidades existentes, isso poderia servir como prova de trabalho?
Em vez de um programa de bounty, e se criassem uma espécie de mercado de previsão verdadeiro/falso
A ideia seria apostar publicamente na resposta, cada um usando seus próprios tokens para validar a substância do relatório e então comprar a aposta. Se a maioria achar que é falso, o operador ganha; se a maioria achar que é real, o operador paga
Estou brincando, mas talvez não totalmente
Alguém já usou o Turso em produção? É uma implementação compatível com SQLite reescrita em Rust, com recursos como suporte a múltiplos escritores, e ao contrário do SQLite também é aberta a contribuições externas
Estou pensando em usar em um app full-stack em Rust, porque tudo funciona com cargo e não preciso trazer o SQLite separadamente
O Turso também oferece banco de dados como serviço com um plano gratuito bem generoso, e esse foi o principal motivo de eu ter usado
https://x.com/doodlestein/status/2052910351474209258
Não daria para contra-atacar do mesmo jeito e implantar seu próprio bot de IA para fazer uma triagem prévia dos PRs?
“É possível configurar sistemas automatizados para impedir isso, mas quando existe valor financeiro grande demais para ser ignorado, o incentivo para fazer IAs continuarem discutindo e reabrindo o mesmo PR é forte demais”
Do ponto de vista de quem está de fora, é um problema interessante. De quantos desses pedidos de bots os agentes estarão usando o Turso no próprio backend?