Stenberg retirou o dinheiro, não as máquinas
Daniel Stenberg encerrou a recompensa por falhas da curl por causa daquilo que o dinheiro atraía, não daquilo que escrevia os relatórios. A 31 de janeiro de 2026 pôs fim a um programa que decorria desde abril de 2019, que tinha confirmado 87 vulnerabilidades reais e pago mais de 100.000 dólares. O motivo foi o desmoronamento da taxa de acerto. Antes de 2024, mais de 15 por cento das submissões revelavam-se problemas de segurança genuínos. Ao longo de 2025 essa fatia caiu abaixo dos 5 por cento, o que, nas suas próprias palavras, significava que nem sequer um em cada vinte era real. Uma equipa voluntária de sete pessoas passava horas a refutar cada um deles, um trabalho que descreveu como um desgaste mental sério.
A sua explicação merece uma leitura rigorosa. O objetivo principal do encerramento, escreveu, era retirar o incentivo para as pessoas enviarem material fraco e mal investigado. Repare-se no que essa frase não diz. Não nomeia qualquer tecnologia nem propõe detetar alguma. Identifica um pagamento como aquilo que premiava o mau trabalho, e elimina o pagamento. O seu critério para quem comunica é igualmente independente do instrumento: nunca se deve comunicar uma vulnerabilidade sem a compreender verdadeiramente e sem a conseguir reproduzir.
O volume duplicou e a taxa de acerto triplicou
O resultado seguiu o sentido oposto ao da previsão óbvia. Deixar de pagar não esvaziou a fila. Em abril de 2026, depois de a curl ter regressado à comunicação não remunerada, as submissões chegavam a um ritmo cerca de duas vezes superior ao de 2025, e 15 a 16 por cento eram confirmadas como vulnerabilidades reais. O número de descobertas confirmadas ultrapassou o nível de 2024, isto é, o anterior à enxurrada.
O pormenor mais importante soa a contradição. Quase todos os relatórios continuavam a parecer assistidos por IA. O que tinha mudado é que a maioria era agora boa. O lixo deixara de ser um problema, comunicou Stenberg em abril. O instrumento não saiu da fila. O lixo é que saiu.
Lida como um problema de controlo, a recompensa era um filtro apontado ao alvo errado. Um prémio em dinheiro por uma descoberta aceite paga em função do volume de submissões multiplicado pela sorte, pelo que premeia enviar depressa e com esperança em vez de verificar primeiro. Essa pressão já existia antes dos modelos generativos e era apenas suportável; a geração barata tornou-a fatal. A escala vê-se também noutros sítios. Na Bugcrowd, o volume de relatórios mais do que quadruplicou em três semanas de março. A HackerOne registou até março uma subida homóloga de 76 por cento nas submissões, ainda que nessa plataforma a fatia que assinalava vulnerabilidades reais se tenha mantido estável perto dos 25 por cento, o que matiza a ideia de que todas as filas ruíram ao mesmo tempo.
Na realidade ninguém proibiu nada
O único levantamento que se deu ao trabalho de contar encontrou zero proibições absolutas. Um estudo integralmente contabilizado de 53 programas de divulgação, abrangendo quatro plataformas de coordenação, 20 fabricantes e 29 projectos de código aberto, foi consultado a 28 de julho de 2026. Nem um único proíbe de forma direta os relatórios de falhas escritos com IA. A afirmação tantas vezes repetida de que o setor os proibiu descreve uma regra que nenhum programa da amostra alguma vez pôs por escrito.
A distribuição real é menos dramática e mais útil. Trinta e seis programas, 67,9 por cento, nada dizem sobre IA nas políticas publicadas. Dezasseis, 30,2 por cento, regulam-na com condições. Desses dezasseis, treze exigem verificação humana da descoberta, onze exigem uma reprodução funcional, oito recusam submissões puramente autónomas continuando a admitir a assistência de IA, e três exigem que o uso de IA seja declarado: Intigriti, Django e FFmpeg. A verificação humana, e não a proibição, é a norma para que todos convergem.
O levantamento encontrou ainda um defeito que vale a pena anotar. Três programas publicaram as suas regras sobre IA num local diferente da página principal da política. Uma condição que quem comunica nunca viu e nunca aceitou não lhe pode ser oposta, o que reduz uma regra escrita a mera decoração. Também os programas que mudaram de estado nada proibiram: a curl fechou a sua recompensa em janeiro de 2026, a Nextcloud suspendeu os prémios pagos em abril, e a Internet Bug Bounty pôs as submissões em pausa.
A Apple e o GitHub foram atrás da pessoa
As orientações da Apple ligam agora a sanção à reputação de quem comunica, e não ao relatório. A Apple afirma sem rodeios que recebe muitos relatórios que dizem respeitar a problemas graves de segurança ou de privacidade mas que são gerados por modelos de linguagem e apresentados sem a prova exigida nem validação por uma pessoa. O remédio é uma suspensão. Se alguém apresentar repetidamente relatórios inadmissíveis, incluindo os inexequíveis sobre questões teóricas ou os descobertos por IA sem validação adequada, a Apple pode deixar de tratar os seus relatórios durante 180 dias. Com mais de dois períodos de suspensão, essa pessoa pode ser removida em definitivo do programa.
A segunda metade dessa sanção é a mais afiada. Enquanto dura a suspensão, a pessoa fica afastada não só do pagamento mas também da menção nos avisos de segurança, e para um investigador profissional o reconhecimento público é a moeda duradoura. Os termos de serviço da Apple chegam ao mesmo ponto por outro caminho, ao proibir um padrão constante, repetido ou de grande volume de afirmações falsas, como os relatórios gerados com o auxílio de IA e não validados por revisão humana. O que decide é essa última parte. A cláusula não proíbe o auxílio, proíbe entregar o resultado sem o verificar.
O GitHub seguiu a outra via da identidade e dividiu o programa em dois escalões com efeitos a partir de 27 de julho de 2026. As recompensas públicas desceram para 250 dólares numa descoberta de gravidade baixa, 2.000 numa média, 5.000 numa alta e 10.000 numa crítica, face aos anteriores 500 a 1.000, 5.000, 20.000 e 30.000. Os montantes antigos vivem agora num escalão por convite que paga 1.000, 7.500, 20.000 e 30.000 dólares ou mais. Entrar exige um percurso demonstrado: uma descoberta crítica aceite, ou duas altas, ou quatro médias, ou sete baixas. Quem comunica pela primeira vez no programa público enfrenta um requisito de sinal, com um máximo de quatro submissões iniciais para provar o seu valor. O objetivo declarado pela engenheira de segurança de produto Catherine Cassell é reduzir o ruído para que a equipa se possa concentrar no sinal.
Quem é travado pode ser justamente quem importa
Filtrar por reputação tem um custo que nenhum destes anúncios quantifica. Cada um destes desenhos premeia um percurso já existente, o que é uma forma sensata de ordenar quem comunica com frequência. Mas a pessoa que encontra uma única falha crítica no seu produto e nunca apresentou um relatório em lado nenhum é, por definição, o perfil sem percurso algum, e é precisamente esse o relatório que menos lhe convém travar. A resposta do GitHub são quatro submissões para demonstrar sinal, a da Apple é um estado que pode ficar parado meio ano. Ambas se defendem, nenhuma é gratuita, e o custo recai justamente sobre quem encontra algo uma só vez e cujo único relatório pode ser o mais valioso do ano.
Para um fabricante europeu, esta questão deixa de ser filosófica a 11 de setembro de 2026, quando começam a aplicar-se as obrigações de comunicação do Regulamento da Ciberresiliência. O fabricante que tome conhecimento de que uma vulnerabilidade do seu produto está a ser ativamente explorada tem de notificar a ENISA e o CSIRT nacional competente no prazo de 24 horas, apresentar uma avaliação mais completa em 72 horas e entregar um relatório final nos 14 dias seguintes à disponibilidade de uma medida correctiva. Em Portugal, a porta de entrada é o CERT.PT, do Centro Nacional de Cibersegurança. O Regulamento exige ainda uma política de divulgação coordenada de vulnerabilidades, ou seja, uma via ordenada pela qual alguém o possa avisar antes de os pormenores chegarem ao público. Lido o prazo com atenção, o problema da caixa de entrada passa a ser um problema de conformidade. O relógio arranca com o conhecimento, e uma fila soterrada em relatórios não validados é uma máquina para atrasar justamente esse conhecimento.
Daqui decorrem três coisas para quem gere essa entrada. Exija uma reprodução funcional e escreva-o na página que quem comunica aceita, porque uma reprodução é demonstrável e uma afirmação sobre que instrumento redigiu o texto não o é. Corrija o incentivo antes de escrever uma regra, dado que a fila da curl melhorou quando o pagamento desapareceu, e não quando mudou uma política. E meça a taxa de descobertas confirmadas em vez do número de relatórios, porque o volume é precisamente o valor que subiu no único caso em que tudo melhorou. Nada no Regulamento da Ciberresiliência o obriga a pagar a um único comunicante. Obriga-o a estar contactável e a saber distinguir um relatório verdadeiro de um verosímil com rapidez bastante para pôr o relógio a andar a tempo.
Leia a seguir: Siri AI teve preço antes de ter data na UE | Os serviços da Apple caíram de um trimestre para o outro
