As Regras de Bug Bounty da Apple e do Google Convergem à Medida que Spam de IA Exige Repressão

As regras de bug bounty da Apple e do Google chegaram ao mesmo ponto de inflexão após uma onda sem precedentes de relatórios de vulnerabilidades de baixa qualidade gerados por IA.

Segundo relatos, a Apple limitou o número de relatórios ativos que pesquisadores podem manter em seu portal de segurança. Também introduziu um período de espera após os pesquisadores atingirem esse limite. As regras públicas da empresa agora preveem pausas mais longas e eventual remoção em caso de envios inválidos recorrentes.

A comparação é relevante porque o Google já havia endurecido seu programa de vulnerabilidades de código aberto após o que chamou de um aumento massivo de relatórios gerados por IA. O GitHub seguiu o mesmo caminho, com requisitos de participação mais rigorosos e uma estrutura de recompensas reformulada. Juntas, essas ações mostram que a descoberta automatizada de vulnerabilidades colidiu com um recurso escasso: a revisão especializada feita por humanos.

O conflito não é simplesmente IA contra pesquisadores de segurança. Trata-se de descoberta em escala versus evidência verificável. Um sistema de IA pode propor centenas de fraquezas plausíveis, mas uma equipe de segurança ainda precisa reproduzir cada alegação e determinar se invasores conseguem explorá-la.

Esse desequilíbrio cria uma inversão desconfortável. A IA deveria ajudar defensores a localizar falhas graves mais rapidamente. Em vez disso, envios não validados podem soterrar os relatórios que merecem atenção imediata.

Apple Impôs Novas Barreiras à Sua Fila de Segurança

A resposta da Apple mira o volume de envios, mas suas regras públicas se concentram mais diretamente na validação e no comportamento dos pesquisadores.

De acordo com a reportagem original sobre a cota, a Apple introduziu um limite para relatórios ativos de vulnerabilidades e um período de resfriamento para pesquisadores que o atingirem. Pesquisadores podem, segundo relatos, solicitar um limite maior quando seu trabalho justificar capacidade adicional.

Essa restrição operacional é separada das sanções publicadas nas atuais diretrizes do Security Bounty da Apple. A Apple afirma que pode pausar o processamento de relatórios por 180 dias quando um pesquisador envia repetidamente descobertas inelegíveis.

Mais de dois períodos de pausa podem levar à remoção permanente do programa. Durante uma pausa, os pesquisadores geralmente perdem acesso a recompensas, crédito em avisos de segurança e ao processamento regular de relatórios.

A Apple prevê exceções limitadas. Um pesquisador suspenso ainda pode enviar evidências que capturem uma Target Flag aplicável ou incluam uma virtualização totalmente empacotada de iOS ou macOS.

Uma Target Flag é um valor protegido inserido em um sistema da Apple para comprovar que um exploit alcançou uma fronteira de segurança específica. Ela transforma uma alegação teórica em evidência mensurável.

As diretrizes de envio de relatórios da Apple agora identificam várias qualidades que um envio válido deve ter. Um relatório precisa de uma explicação precisa, um exploit funcional ou prova de conceito confiável e etapas concisas de reprodução.

A empresa instrui explicitamente os pesquisadores a evitar descrições extensas geradas por ferramentas de IA. Também classifica como inelegíveis descobertas teóricas de IA sem validação adequada.

Essas disposições não proíbem pesquisas assistidas por IA. Elas traçam uma linha entre usar IA durante uma investigação e transferir a saída não testada de um modelo de IA para a fila da Apple.

Os termos do programa da Apple reforçam essa distinção. A empresa pode encerrar a participação após spam recorrente, alegações falsas ou envios assistidos por IA que não tenham sido revisados.

Essa combinação oferece à Apple várias camadas de aplicação. Uma cota no portal limita o volume simultâneo. Uma pausa de 180 dias aborda comportamentos repetidos de baixa qualidade. A exclusão permanente continua disponível para pesquisadores que não melhorarem.

A distinção importa porque cotas, por si só, não conseguem identificar qualidade. Um pesquisador cuidadoso pode ter várias descobertas legítimas sob investigação ativa. Um remetente de spam pode enviar menos relatórios que ainda assim consumam muitas horas.

Por isso, a Apple permite que evidências mais robustas funcionem como exceção. Exploração confiável, comportamento reproduzível e confirmação do alvo podem fazer um relatório superar os controles de volume.

A mudança também restringe o que é considerado descoberta útil de vulnerabilidade. Encontrar código suspeito já não é suficiente. Os pesquisadores precisam explicar como um invasor alcança esse código e qual controle, dado ou privilégio ele obtém.

Esse padrão é familiar para caçadores de bugs experientes. O que mudou foi a necessidade de declará-lo diretamente em resposta ao volume gerado por IA.

Por Que a Resposta da Apple e do Google Chegou Agora

A repressão da Apple e do Google reflete uma assimetria econômica: máquinas geram alegações de segurança a baixo custo, enquanto engenheiros precisam invalidá-las uma a uma.

Modelos generativos podem examinar código, descrever padrões inseguros, redigir narrativas de ataque e formatar relatórios com aparência profissional. Nenhuma dessas capacidades estabelece que uma vulnerabilidade funcione em uma configuração de produto compatível.

Um modelo pode identificar um buffer overflow em código inacessível. Pode interpretar erroneamente uma fronteira de permissões ou inventar uma função que não existe. Também pode exagerar o impacto de um defeito rotineiro de software.

Ainda assim, cada alegação pode parecer crível à primeira vista. Engenheiros de segurança precisam inspecionar o código relevante, configurar um ambiente de teste, reproduzir o comportamento e avaliar a exposição no mundo real.

O Google descreveu exatamente esse problema quando alterou seu Open Source Software Vulnerability Reward Program em março de 2026. A empresa afirmou ter enfrentado um aumento massivo de relatórios gerados por IA ao longo de várias semanas.

O Google observou condições de acionamento alucinadas, impacto de segurança insignificante e descobertas em caminhos de código inacessíveis. Sua atualização de regras do OSS passou, consequentemente, a exigir provas mais fortes para partes do programa.

Dependendo do nível do repositório, as evidências aceitáveis podem incluir uma reprodução via OSS-Fuzz ou um patch integrado. OSS-Fuzz é o serviço contínuo de fuzzing do Google para software de código aberto.

Mais tarde, o Google removeu recompensas monetárias e crédito público para algumas vulnerabilidades de produtos de nível inferior e outros problemas de segurança. Essa mudança alterou a estrutura de incentivos, e não apenas o formato dos relatórios.

A Apple adotou uma rota operacional diferente. Seu limite relatado controla o número de casos ativos vinculados a um único pesquisador. Sua política escrita ameaça suspensões quando relatórios repetidos permanecem teóricos ou inválidos.

Ambas as abordagens introduzem atrito antes que recursos escassos de triagem desapareçam. Nenhuma presume que uma redação bem-acabada equivale a uma vulnerabilidade verificada.

A palavra “slop” pode obscurecer o mecanismo real. O problema não é a IA ter escrito uma frase. O problema é que a geração automatizada elimina o custo natural que antes limitava relatórios especulativos.

Antes da IA generativa, elaborar um envio convincente de vulnerabilidade exigia trabalho manual substancial. Um pesquisador normalmente precisava inspecionar um alvo, provocar comportamento inesperado e documentar resultados reproduzíveis.

A IA reduz o custo de produzir o documento sem necessariamente reduzir o custo de produzir a evidência. Isso cria mais relatórios cuja aparência supera sua substância técnica.

Uma recompensa pode amplificar esse comportamento. Quando até mesmo um único envio aceito pode receber uma recompensa, sistemas automatizados conseguem gerar muitas tentativas especulativas.

O remetente paga pouco por cada alegação adicional. A organização que a recebe arca com um custo de revisão especializada a cada vez.

Este é um problema clássico de filas. Se chegadas inválidas aumentarem mais rapidamente do que a capacidade de revisão, casos legítimos esperam mais tempo, independentemente de sua qualidade.

Adicionar mais revisores oferece apenas uma resposta parcial. Engenheiros experientes de segurança de produtos são difíceis de contratar, e o trabalho de triagem compete com remediação, análise de ameaças e resposta a incidentes.

A triagem automatizada pode ajudar a priorizar relatórios, mas introduz outra camada de verificação. Um classificador pode suprimir um relatório incomum que descreve de forma deficiente um exploit genuíno.

A resposta da Apple e do Google, portanto, trata a validação humana como o ponto de controle essencial. A IA pode auxiliar a descoberta, mas uma pessoa continua responsável por provar a alegação antes do envio.

A Verdadeira Troca É Acesso Versus Sinal

Barreiras mais rigorosas podem proteger equipes de segurança, mas também podem prejudicar novos pesquisadores e atrasar descobertas incomuns.

Programas abertos de bug bounty ampliam o alcance defensivo de uma empresa. Pesquisadores independentes testam configurações, componentes e caminhos de ataque que equipes internas podem deixar passar.

Essa abertura funciona porque a participação não exige emprego, status institucional ou uma relação prévia com o fornecedor. Um pesquisador com uma descoberta forte pode entrar na mesma fila que uma empresa de segurança estabelecida.

Limites de envio alteram esse equilíbrio. Eles preservam a capacidade de revisão, mas também tornam o acesso condicionado à qualidade anterior dos relatórios ou à cota disponível.

O risco fica mais claro quando várias descobertas legítimas chegam ao mesmo tempo. Uma equipe de pesquisa que audita uma grande plataforma pode identificar muitas vulnerabilidades relacionadas durante um único projeto concentrado.

Se casos anteriores permanecerem abertos, a equipe pode atingir um limite de relatórios ativos mesmo quando suas novas evidências são sólidas. Solicitar um aumento oferece uma possível solução, mas a decisão permanece com o operador do programa.

A Apple tem um motivo legítimo para proteger sua fila. Seu programa de segurança abrange produtos e serviços voltados ao público, utilizados em uma grande base de dispositivos.

A empresa afirma que apenas o primeiro relatório completo e acionável se qualifica para uma recompensa. Essa regra torna o envio oportuno importante quando vários pesquisadores investigam a mesma fraqueza.

Uma cota pode, portanto, criar uma corrida não intencional. Pesquisadores podem priorizar o relatório com maior probabilidade de receber recompensa em vez da questão com maior impacto para os usuários.

A Apple tenta neutralizar essa pressão ao enfatizar evidências completas. Um relatório apressado sem reprodução confiável continua inelegível, mesmo quando chega primeiro.

A questão cética da política é se a Apple consegue distinguir volume de abuso de forma consistente. A documentação pública explica o que torna um relatório acionável, mas não divulga todos os limites de triagem ou decisões de escalonamento.

Os pesquisadores também não podem medir independentemente quantos relatórios inválidos gerados por IA entram no sistema da Apple. A empresa descreveu o problema, mas não publicou uma divisão mensal detalhada.

Essa ausência não invalida a resposta da Apple. Ela limita a avaliação externa sobre se uma cota é proporcional e se melhora os tempos de processamento.

Preocupações históricas com os tempos de resposta dos fornecedores tornam a transparência importante. Pesquisadores precisam saber se o silêncio reflete um relatório fraco, uma investigação longa ou uma fila sobrecarregada por envios não relacionados.

Uma barreira mal implementada pode desestimular a divulgação responsável. Um pesquisador que não consegue enviar uma descoberta de forma privada pode adiar o relato, procurar outro coordenador ou divulgá-la publicamente após perder confiança no processo.

A divulgação pública antes de uma correção pode aumentar o risco para os usuários. As regras da Apple também tornam a divulgação prematura inelegível para pagamento de recompensa.

A empresa, portanto, controla tanto o canal aceito quanto as condições para manter a elegibilidade. Esse arranjo funciona melhor quando os pesquisadores recebem feedback específico e oportuno.

O padrão mais defensável é o atrito baseado em evidências. Um pesquisador que envia repetidamente descobertas alucinadas deve enfrentar restrições. Um pesquisador com exploits reproduzíveis deve ter um caminho claro de escalonamento.

A exceção de Target Flag da Apple aponta nessa direção. Ela privilegia o impacto verificável em vez da reputação isolada.

Ainda assim, as Target Flags não abrangem todas as categorias de vulnerabilidade. Algumas falhas lógicas importantes resistem a uma comprovação simples baseada em flags, e alguns relatos exigem avaliação contextual.

Esse equilíbrio não pode ser resolvido por uma única política. A Apple precisa filtrar com rigor suficiente para proteger a triagem, mantendo abertura suficiente para captar pesquisas inesperadas.

Google e GitHub mostram que esta é uma mudança no setor

A Apple não está agindo sozinha, e o modelo emergente do setor recompensa o impacto demonstrado em vez do volume de descobertas automatizadas.

A atualização do Google de março de 2026 oferece a comparação mais clara. A empresa reconheceu que a IA pode acelerar a pesquisa de vulnerabilidades, ao mesmo tempo em que exigiu que pesquisadores validem seus resultados durante a investigação.

O Google não rejeitou relatos apenas porque a IA contribuiu para eles. Aumentou os requisitos de comprovação para determinados níveis de repositório e reduziu os incentivos para categorias de menor valor.

Seu Vulnerability Reward Program mais amplo agora inclui fatores de qualidade do relato, como precisão técnica, capacidade de resposta e exatidão factual. As regras publicadas identificam “AI slop” como um sinal negativo de qualidade.

Essa linguagem reflete uma mudança: em vez de julgar apenas a vulnerabilidade alegada, passa-se a avaliar também o processo de envio. Os pesquisadores precisam demonstrar que entendem o alvo e conseguem responder a perguntas de acompanhamento.

O GitHub adotou outra variação em julho de 2026. Reestruturou seu programa público de recompensas e criou uma faixa permanente, acessível apenas por convite, para pesquisadores selecionados.

A empresa também adicionou um requisito de sinal da HackerOne ao seu programa público. Signal é uma medida de reputação baseada na frequência com que os relatos de um pesquisador recebem resultados favoráveis.

O GitHub afirmou que o requisito foi criado para reduzir envios de baixo esforço e gerados por IA. Relatos enviados a partir de 27 de julho passaram a entrar na estrutura revisada.

As mudanças do GitHub mostram como um programa aberto pode gradualmente se tornar condicionado à reputação. Novos pesquisadores recebem oportunidades limitadas para construir um histórico útil.

O modelo da Apple atualmente parece menos dependente de uma pontuação de reputação de terceiros. Em vez disso, combina critérios para relatos, limites de casos ativos e sanções progressivas.

As três empresas estão resolvendo o mesmo problema de alocação com controles diferentes.

O Google aumenta os requisitos de evidência e restringe as categorias elegíveis. O GitHub ajusta acesso, reputação e recompensas. A Apple limita a ocupação da fila e penaliza envios inválidos repetidos.

Essas abordagens podem melhorar o sinal, mas cada uma traz um risco de exclusão diferente. Os requisitos de evidência favorecem pesquisadores com ferramentas mais maduras. Barreiras de reputação favorecem participantes estabelecidos. Cotas favorecem aqueles cujos casos anteriores são encerrados rapidamente.

O padrão vai além das grandes empresas de tecnologia. Mantenedores de projetos open source também relataram alegações de vulnerabilidade geradas por IA que consomem tempo de voluntários.

Esses projetos enfrentam um desequilíbrio ainda maior. Uma biblioteca popular pode ter apenas alguns mantenedores, enquanto scanners automatizados podem produzir relatos continuamente.

Plataformas de bug bounty responderam com regras mais rígidas contra hipóteses de IA não validadas. Algumas exigem testes manuais e confirmação antes que um pesquisador envie uma descoberta.

Essa convergência deixa um ponto claro: o setor não está proibindo a pesquisa de segurança assistida por máquinas. Está retirando recompensas e atenção de alegações geradas por máquinas sem verificação humana responsável.

Essa distinção moldará os futuros agentes de segurança. Ferramentas que apenas produzem relatos plausíveis perderão valor. Ferramentas que reproduzem exploits, coletam rastros e explicam caminhos de ataque alcançáveis continuarão úteis.

A oportunidade competitiva está na automação de evidências. Um agente de segurança não deve parar após identificar código suspeito.

Ele deve construir um caso de teste, confirmar a versão afetada, isolar pré-condições e registrar a consequente elevação de privilégio ou exposição de dados. Pesquisadores humanos devem então examinar essas evidências antes da divulgação.

A comparação entre Apple e Google é, portanto, mais do que uma história de políticas. Ela define os requisitos de produto para a próxima geração de ferramentas automatizadas de segurança.

A IA pode encontrar vulnerabilidades reais, mas a comprovação continua sendo o gargalo

O argumento mais forte contra uma proibição ampla da IA é simples: sistemas automatizados já contribuem para descobertas genuínas de segurança.

O Google promoveu a pesquisa de vulnerabilidades assistida por IA por meio de projetos como Big Sleep, um agente desenvolvido pelo Google DeepMind e pelo Project Zero. O projeto combina raciocínio de modelos com ferramentas de segurança estabelecidas.

Esse trabalho mostra por que as empresas estão evitando proibições definitivas. A IA pode explorar grandes bases de código, gerar hipóteses e ajudar pesquisadores a investigar interações complexas.

As regras da Apple preservam essa distinção. Elas se referem a descobertas de IA sem validação adequada, e não a toda descoberta desenvolvida com assistência de IA.

Um pesquisador pode usar um modelo para inspecionar código-fonte ou aprimorar um relato. O envio final ainda deve descrever o comportamento observado, o comportamento esperado, o mecanismo contornado e um resultado de ataque crível.

Uma prova de conceito confiável continua sendo central. Uma prova de conceito é um teste mínimo que demonstra a vulnerabilidade sob condições definidas.

Para cadeias de ataque complexas, a Apple solicita versões compiladas e de código-fonte, payloads necessários e tudo o que for preciso para executar a cadeia. Essa exigência coloca a reprodutibilidade acima da confiança na narrativa.

A Apple tem motivos para preservar pesquisas externas de alta qualidade. Em uma atualização anterior sobre recompensas, a empresa disse ter pago mais de US$ 35 milhões a mais de 800 pesquisadores desde a abertura do programa público, em 2020.

Ela também relatou vários prêmios individuais de US$ 500.000. Esses números mostram que os envios externos não são uma parte periférica do processo de segurança da Apple.

O desafio é manter esse canal utilizável à medida que a automação se expande. Se as equipes de triagem gastarem tempo demais refutando cenários fabricados, o valor de todo o programa diminui.

No entanto, a triagem automatizada não pode ser tratada como infalível. Um exploit incomum pode parecer um falso positivo porque atravessa uma fronteira que os revisores não esperavam.

Um filtro baseado em modelos também pode favorecer uma estrutura convencional de relato. Pesquisadores que usam inglês menos refinado ou metodologias desconhecidas podem receber pontuações mais baixas, apesar de evidências válidas.

A Apple afirma que seus relatos recebem revisão humana, enquanto a IA ajuda a priorizar casos recebidos. Essa divisão pode reduzir o trabalho administrativo sem entregar as decisões finais inteiramente a um classificador.

Os detalhes continuam importantes. Os pesquisadores precisam saber se a priorização automatizada influencia o tempo de resposta, a elegibilidade ou apenas a ordem na fila.

Falsos negativos criam um risco diferente do spam. Um relato inválido rejeitado desperdiça o tempo de um pesquisador. Um relato válido rejeitado pode deixar milhões de dispositivos expostos.

A solução não é aceitar toda alegação gerada. É tornar os recursos, a escalada e os padrões de evidência suficientemente claros para que descobertas sólidas possam se recuperar de uma classificação inicial incorreta.

As equipes de segurança também devem medir resultados, não apenas a redução de volume. Uma política bem-sucedida deve reduzir o tempo necessário para validar relatos críticos sem suprimir o número de descobertas aceitas de alto impacto.

Os pesquisadores também têm responsabilidades. Devem reproduzir a saída do modelo, testar versões afetadas, descrever pré-condições e remover linguagem especulativa não sustentada por experimentos.

Textos gerados por IA podem fazer a incerteza soar como certeza. A revisão humana precisa inverter essa tendência, separando observações de suposições.

Um relato útil deve responder a quatro perguntas concretas. Que entrada dispara o comportamento? Qual configuração compatível é afetada? Qual fronteira de segurança falha? O que o invasor obtém?

Quando essas respostas estão ausentes, mais texto não melhora o relato. Apenas aumenta o custo para encontrar as evidências que faltam.

O que observar após a repressão aos relatos de bugs por IA

O próximo teste é saber se regras mais rígidas melhoram a qualidade das respostas sem afastar pesquisadores confiáveis.

O primeiro sinal será o desempenho da Apple no processamento de relatos. Tempos menores de revisão inicial sustentariam o argumento da empresa de que envios inválidos estavam consumindo capacidade crítica.

A Apple atualmente não publica um painel público detalhado que cubra o tamanho da fila, os motivos de rejeição e o tempo mediano de resposta. Mais transparência facilitaria avaliar o efeito da política.

Pesquisadores ainda podem fornecer evidências indiretas. Relatos de confirmações mais rápidas, atualizações de status mais claras e menos casos prolongados sugeririam que os controles estão funcionando.

O padrão oposto enfraqueceria a explicação da Apple. Se relatos legítimos continuarem atrasados após as restrições de volume, o gargalo poderá envolver pessoal, coordenação interna ou capacidade de remediação.

O segundo sinal será o tratamento dado a pesquisadores de alto volume. A Apple supostamente permite solicitações de aumento de cota, criando uma importante válvula de escape para equipes com descobertas validadas.

Observadores devem acompanhar se essas solicitações recebem decisões rápidas e se as evidências, em vez da reputação isolada, determinam a aprovação.

Um processo de exceção que funcione bem permitirá que equipes sérias continuem auditorias concentradas. Um processo opaco fará o limite de relatos ativos parecer arbitrário.

O Google oferece uma referência externa útil. Seus requisitos mais altos de comprovação devem reduzir relatos inválidos, mas também podem reduzir a participação em projetos open source de menor nível.

As políticas da Apple e do Google parecerão mais defensáveis se ambos os programas mantiverem taxas robustas de descoberta enquanto reduzem o tráfego de baixo valor na fila. A queda no total de envios, por si só, não provaria sucesso.

O terceiro sinal virá de fornecedores de ferramentas de segurança e agentes de IA. O mercado agora tem um incentivo claro para produzir artefatos reproduzíveis em vez de especulação polida sobre vulnerabilidades.

Ferramentas úteis integrarão rastros de execução, informações de versão, ambientes de teste e pré-condições de exploit. Também rotularão inferências incertas, em vez de apresentá-las como comportamento confirmado.

Operadores de programas poderiam apoiar essa transição com esquemas de envio legíveis por máquina. Campos obrigatórios poderiam separar resultados observados, impacto inferido, detalhes do ambiente e etapas de validação humana.

Evidências padronizadas poderiam melhorar o encaminhamento automatizado sem substituir o julgamento especializado. Também tornariam envios em massa mais fáceis de auditar.

A questão mais difícil é se os invasores obtêm os mesmos benefícios da automação sem enfrentar regras de divulgação. Eles não precisam provar uma vulnerabilidade a um fornecedor antes de explorá-la.

Portanto, os defensores não podem responder à má automação rejeitando a automação por completo. Precisam de agentes melhores, pipelines de validação mais fortes e escalada humana mais rápida para descobertas críveis.

A política imediata da Apple protege a porta de entrada de seu programa de recompensas. Ela não resolve o desafio mais amplo da descoberta de vulnerabilidades em escala de máquina.

Para os pesquisadores, a mensagem prática é direta. Use IA para ampliar o espaço de busca, mas envie apenas o que puder reproduzir e defender sob questionamento técnico.

Para líderes de engenharia, a lição vai além dos bug bounties. Qualquer fluxo de trabalho que aceite conteúdo de IA gerado externamente precisa de uma barreira vinculada a evidências, responsabilidade e custo de revisão.

A mudança de política entre Apple e Google será, em última análise, julgada pelo que chega aos engenheiros após a filtragem. A fila contém menos relatos ou relatos melhores?

Essa diferença deve orientar a próxima fase. Acompanhe os tempos de resposta, observe como funcionam as solicitações de exceção e procure agentes de segurança que produzam evidências, em vez de texto confiante.