Bitcoin Core tem razão: quando uma IA acha a falha, o sigilo é puro teatro

De que adianta um segredo que qualquer chatbot consegue regenerar com um único prompt? Essa é, em essência, a pergunta que o Bitcoin Core acabou de responder, e achamos que respondeu certo.

Na quinta-feira, 22 de outubro, o projeto incorporou uma mudança em sua política de segurança, escrita por Antoine Poinsot, desenvolvedor da Chaincode Labs. Até agora, o Core classificava cada vulnerabilidade por gravidade e definia o momento da divulgação de acordo com isso. Falhas de baixa gravidade eram reveladas duas semanas depois do lançamento da versão principal seguinte. As de gravidade média e alta podiam ficar ocultas até duas semanas depois de a última versão afetada chegar ao fim da vida útil, uma espera que pode se estender por cerca de um ano. Agora os mantenedores podem rotular um bug como "facilmente descobrível" durante a triagem. Esse rótulo cobre um bug que pode ser encontrado com um simples prompt para um LLM. Esse tipo de bug recebe uma correção portada para todas as versões mantidas, uma versão de manutenção o mais rápido possível e um aviso de segurança com alguns detalhes. Bugs críticos ficam fora da política padrão e são tratados caso a caso.

O embargo era uma aposta na dificuldade, e as chances mudaram

Um embargo longo só funciona se for improvável que os atacantes encontrem a brecha por conta própria. Corrigir em silêncio dá tempo para os operadores de nós atualizarem antes que alguém saiba onde está a fraqueza. O próprio diagnóstico de Poinsot, citado pelo CoinDesk, é que os LLMs reduziram "drasticamente" a barreira para encontrar certas classes de problemas ou para identificar correções disfarçadas. Essa segunda parte é a mais subestimada. Uma correção silenciosa já é, por si só, uma pista, e um modelo sabe ler um diff.

Portanto, para esse tipo de bug, o embargo não protege ninguém além do atacante, que já sabe. Enquanto isso, usuários honestos ficam em versões antigas sem correção, esperando uma versão principal. A política diz isso com clareza: "O período de embargo alcança pouco, mas atrasa a disponibilidade de uma versão corrigida."

As evidências mostram que isso não é hipotético

Pense no que aconteceu neste verão. Um grupo voluntário de 16 desenvolvedores, o Bitcoin Red Team, executou modelos de IA em 390 projetos de Bitcoin em cerca de um dia e registrou 4.962 achados, 85 deles críticos, segundo o CoinDesk. Nem todos foram reproduzidos (um relatório diz que apenas cerca de um quinto naquele momento), então o número deve ser lido com essa ressalva. Ainda assim, em poucos dias uma falha no BTCPay Server que o grupo havia relatado em particular estava sendo explorada em servidores reais de lojistas. O relato privado não chegou antes dos atacantes.

O quadro mais amplo aponta na mesma direção. Uma nota de pesquisa da Cloud Security Alliance argumenta que o modelo clássico de divulgação coordenada, com sua janela típica de 90 dias, foi concebido para pesquisadores humanos trabalhando em velocidade humana. Vemos a decisão do Bitcoin como um caso concreto desse argumento.

A transparência tem um preço, e vale a pena pagá-lo

A mudança não é de graça. Poinsot admite que correções mais rápidas têm menos "tempo de maturação" nos testes. É um risco real, porque um patch apressado em um software que protege uma rede enorme pode dar errado. A alternativa proposta pelo desenvolvedor Antoine Riard, lançar correções sem aviso em alguns casos, foi rejeitada, e concordamos com a rejeição. Poinsot argumentou que alertar os usuários sem detalhes poderia provocar migrações apressadas de pessoas que nem seriam afetadas. Meio sigilo traz o pânico sem a informação.

Há também uma preocupação legítima com a própria linha divisória. Nenhum bug foi sinalizado até agora sob a nova regra, então, como observa o Crypto Briefing, a dúvida é com que consistência os mantenedores decidirão o que é "facilmente descobrível". Um rótulo vago poderia virar brecha em qualquer direção. Nossa opinião é que o critério é honesto, porque depende de quão fácil é achar uma falha, e não de qual ferramenta a achou.

O que outros projetos devem tirar disso

A lição não é "divulgar tudo imediatamente". Bugs difíceis de achar ainda merecem tempo, e o Core mantém para eles o cronograma por gravidade. A lição é que a premissa padrão se inverteu. Os projetos agora devem perguntar se um bug pode ser redescoberto a baixo custo e, se puder, tratar a velocidade da correção como prioridade, e não a discrição. Projetos críticos de código aberto com cultura lenta de atualização têm mais a ganhar, pois têm mais a perder com uma longa janela de exposição.

Nosso veredito: o Bitcoin Core fez uma jogada pragmática e um pouco desconfortável, e é a certa. Os operadores devem ficar atentos a versões de manutenção e avisos e estar prontos para atualizar rápido. Todos os outros que mantêm código amplamente usado deveriam rever suas regras de embargo e perguntar quais ainda protegem os usuários e quais protegem apenas o hábito.