A Bitcoin Red Team, campanha de segurança assistida por inteligência artificial, informou ter gerado 6.700 achados em 425 projetos do ecossistema Bitcoin. A operação alcançou esse volume durante as primeiras 55 horas.

Do total, a iniciativa classificou 1.029 ocorrências com severidade alta ou crítica. Contudo, esses números representam materiais inseridos em uma fila de triagem, e não vulnerabilidades confirmadas.

Na atualização de 6 de agosto no X, a campanha não apresentou definições auditáveis para as classificações. Também não informou resultados individuais, taxa de falsos positivos ou proporção de correções.

Por isso, os dados não permitem calcular quantos alertas se transformaram em vulnerabilidades comprovadas. Também faltam números sobre relatórios rejeitados, rebaixados ou corrigidos pelos mantenedores.

Números da campanha de segurança

Ainda assim, as primeiras 55 horas mostraram que sistemas de IA conseguem preencher rapidamente uma fila de revisão. Depois dessa etapa, especialistas precisam reproduzir falhas, preparar divulgações e obter respostas dos responsáveis pelos projetos.

A campanha publicou dois retratos da operação enquanto ampliava a quantidade de participantes e a carga de trabalho:

Na atualização de 27,5 horas no X, a Bitcoin Red Team mencionou 390 projetos e 4.962 achados. Após 55 horas, a cobertura cresceu em 35 projetos, enquanto o total de ocorrências aumentou em 1.738.

Nesse intervalo, os achados de severidade alta ou crítica passaram a representar 15,4% do total. A publicação posterior também esclareceu que três dos 24 participantes eram bots.

Já o primeiro levantamento separou os níveis crítico e alto. A atualização seguinte reuniu as duas categorias. Em ambos os casos, as classificações partiram da campanha, sem confirmação pública dos mantenedores.

Revisão humana orienta os relatórios

Rob Hamilton descreveu no X o Kimi K3 como responsável pela análise mais intensa. Conforme seu relato, GPT Sol, Fable/Opus e GLM 5.2 apoiaram a documentação.

Hamilton afirmou que o Cyber Harness, da OpenAI, analisou componentes selecionados que ele considerava estruturais. Um dia depois, ele explicou no X que especialistas poderiam alterar uma avaliação com poucas informações adicionais.

Nos exemplos apresentados, uma ou duas frases de contexto elevaram preocupações intermediárias para níveis alto ou crítico. Um pequeno bloco de código também poderia mudar a classificação.

Em contrapartida, Hamilton identificou a triagem, as operações e a transferência das divulgações como gargalos. Os modelos realizaram buscas amplas, enquanto os especialistas interpretaram resultados e tentaram reproduzir os problemas.

Além disso, a equipe humana decidiu quais relatórios estavam prontos para envio aos mantenedores. Portanto, a iniciativa funcionou como um sistema de revisão conjunta entre especialistas e IA.

Divulgação limita o impacto da análise

Na atualização de 55 horas, a Bitcoin Red Team afirmou que 19,5% dos projetos analisados possuíam um arquivo SECURITY.md. Entre os projetos, 13,1% incluíam um endereço de e-mail nesse arquivo.

Porém, a publicação não detalhou o conjunto de projetos, o denominador adotado ou o método de medição. Assim, os percentuais descrevem apenas a varredura realizada pela campanha.

Em 3 de agosto, Hamilton afirmou que a operação havia gastado mais de US$ 10.000 para analisar mais de 100 repositórios. Ele também relatou a divulgação imediata de achados críticos quando uma prova de conceito demonstrava explorabilidade.

A publicação de Hamilton no X indicou que a equipe priorizava esses casos comprovados. No dia seguinte, ele reportou cerca de US$ 20.000 em gastos, mais de uma dúzia de divulgações e 150 repositórios analisados.

Mesmo com o crescimento da varredura, a campanha apontou o contato, a transferência e a triagem como restrições operacionais. Dessa forma, o volume de achados avançou mais rapidamente do que a capacidade pública de validação.

Validação determinará o resultado

A campanha não apresentou um denominador comparável para as divulgações após 55 horas. Consequentemente, os dados não medem a velocidade relativa entre identificar um possível problema e obter sua correção.

Mais tarde, Hamilton apontou no X o incidente separado da Coldcard como catalisador da campanha mais ampla. Entretanto, o registro da operação não atribuiu a descoberta dessa falha à corrida de análise.

Um levantamento público mais completo separaria os achados reproduzidos, reconhecidos, rebaixados, rejeitados e corrigidos. Cada indicador também precisaria apresentar definições e denominadores claros.

O crítico público JW Weatherman argumentou no X que a campanha não conseguiria triar a própria produção. Porém, ele não identificou um problema, uma correção ou um aviso ligado à iniciativa.

Assim, a crítica não permite estabelecer uma taxa mensurável de falha. Por enquanto, os 6.700 registros representam achados classificados pela campanha e candidatos à revisão.

A operação demonstrou a velocidade da análise assistida por máquinas. Seu valor duradouro, contudo, dependerá da parcela que especialistas conseguirem validar, divulgar e transformar em correções.