Eu acompanho bug bounty há anos e nunca vi nada parecido. A Apple acabou de colocar um teto no número de vulnerabilidades que cada pesquisador pode reportar — não porque descobriu menos bugs, mas porque está afogada em “AI slop”. Segundo o Tecnoblog.net, pesquisadores estão usando modelos de linguagem para varrer código automaticamente e mandando um volume absurdo de relatórios com falhas que simplesmente não existem. É o colapso da triagem causado pela alucinação de IA, e isso abre uma conversa séria sobre como devs e times de segurança precisam repensar o uso de LLMs em auditoria.
O que realmente está acontecendo com o programa da Apple
A Apple lançou em 2025 um novo programa de notificações de vulnerabilidades com pagamentos que podem chegar a US$ 5 milhões (cerca de R$ 25,7 milhões em conversão direta) por falha crítica. O problema é que a porta de entrada virou um gargalo. Modelos de IA usados por pesquisadores estão identificando “riscos” que não existem —经典的 alucinações que confundem padrões sintáticos com falhas reais.
O resultado prático: a Apple instituiu um limite por pesquisador ou empresa. Atingiu o teto, precisa esperar 30 dias para voltar a submeter. Se aparecer uma vulnerabilidade grave no intervalo, é possível pedir um aumento. A Bynário, startup italiana de cibersegurança, declarou ao Financial Times ter encontrado mais de 50 bugs no macOS mais recente em apenas três semanas — e travou no formulário de envio da maçã.
Por que IA alucina tanto em análise de segurança
Na minha experiência, quem usa LLM para pentest esquece um detalhe fundamental: esses modelos são probabilísticos, não determinísticos. Eles aprendem a “parecer” uma análise de segurança, não a fazer uma análise de segurança. Quando você pede para um modelo varrer um repositório procurando por SQL injection, ele vai retornar candidatos que parecem vulneráveis — porque o contexto do código lembra padrões vistos em datasets de treinamento.
Mas “parecer vulnerável” e “ser vulnerável” são coisas completamente diferentes. Um prepared statement mal formatado pode parecer problemático para o modelo, mas estar totalmente seguro em runtime. O oposto também acontece: falhas reais que fogem do padrão aprendido passam batido porque o modelo nunca viu aquele contexto específico.
O mecanismo técnico da alucinação
LLMs funcionam prevendo o próximo token mais provável dado um contexto. Quando você alimenta código-fonte e pergunta “isso é vulnerável?”, o modelo não está executando análise simbólica, não está rastreando fluxo de dados, não está fazendo taint analysis. Ele está calculando: “dado esse padrão de código, qual a resposta estatisticamente mais provável para a pergunta ‘isso é vulnerável’?”
O viés de confirmação agrava tudo. Se o prompt do pesquisador já carrega a expectativa (“encontre vulnerabilidades em X”), o modelo tenderá a “encontrar” o que foi pedido. É o mesmo efeito de pedir para uma pessoa tendenciosa revisar uma prova — ela achará erros onde quer que olhe.
Na Prática: como identificar relatório gerado por IA
Se você trabalha em blue team ou gerencia um programa de bug bounty, vai começar a receber mais relatórios assim. Aprendi a filtrar com alguns sinais. Anota aí:
- Linguagem genérica demais. “The application may be vulnerable to XSS” sem endpoint exato, sem payload, sem screenshot, sem request/response completo. LLM adora hedge words como “may”, “could potentially”, “might be”.
- Falta de cadeia de exploração. Relatório sério mostra pré-condições, caminho de exploração, impacto real. Relatório de IA pula direto para “isso é perigoso” sem explicar o porquê.
- Severidade inflada. Tudo vira “critical” ou “high”. Em programa maduro, 90% das submissões válidas são medium/low. Se o cara só manda critical, desconfie.
- Código reproduzido incorretamente. Trechos que quase batem com o original, com nomes de variáveis trocados ou imports inventados. Sinal clássico de modelo “resumindo” o código em vez de citá-lo.
- Sem prova de conceito funcional. CVE precisa de PoC. Relatório de IA geralmente tem descrição narrativa, sem curl, sem script, sem payload HTTP válido.
Exemplo concreto: alucinação vs. vulnerabilidade real
Veja este trecho em Python. Um LLM poderia “marcar” como vulnerável, mas está completamente seguro:
from flask import Flask, request
import sqlite3
app = Flask(__name__)
@app.route('/user/<id>')
def get_user(id):
conn = sqlite3.connect('users.db')
cursor = conn.cursor()
# Parece SQLi, mas é parametrizado corretamente
cursor.execute("SELECT name, email FROM users WHERE id = ?", (id,))
return cursor.fetchone()
Um modelo olhando isso friamente pode dizer: “concatenação de string, vulnerável a SQL injection, severity high”. Mas o ? com tupla separada faz o driver usar prepared statement internamente. Não tem injeção. Relatório baseado nisso é ruído.
Agora contraste com este, que é vulnerável:
@app.route('/search')
def search():
query = request.args.get('q', '')
conn = sqlite3.connect('users.db')
cursor = conn.cursor()
# Vulnerabilidade real: f-string monta SQL dinâmico
cursor.execute(f"SELECT * FROM products WHERE name LIKE '%{query}%'")
return cursor.fetchall()
A diferença? No segundo, a entrada do usuário entra direto na string SQL. Um bom relatório vem com ?q=' OR '1'='1 como payload e mostra o retorno com todos os produtos vazados. Relatório de IA geralmente só aponta a presença do f-string sem demonstrar exploração real.
Comparativo: como outros gigantes lidam com isso
A Apple não está sozinha nesse problema. O Google reduziu pagamentos do programa Chrome em 2024 por motivos parecidos. A Microsoft implementou triagem automatizada com análise estática real (semântica, não estatística). A HackerOne, plataforma que hospeda a maioria dos programas, passou a exigir prova de conceito executável e penaliza pesquisadores que mandam lixo repetidamente.
Na minha visão, a abordagem da Apple de limitar submissões é paliativa. O problema de fundo é que democratizaram o acesso à “análise de segurança” via prompts, sem democratizar o conhecimento de como essa análise realmente funciona. Limite de 30 dias não vai resolver alucinação — só vai atrasar a enxurrada.
Erros comuns que devs cometem ao usar IA em segurança
Cuidado com essas armadilhas. Já vi gente cometendo todas elas:
- Confiar em relatório de LLM sem validar manualmente. Rodar o exploit você mesmo é obrigatório. Se você não consegue reproduzir, não é vulnerabilidade — é conjectura.
- Submeter relatório de IA achando que ninguém vai perceber. Triadores experientes identificam em segundos. Sua reputação no programa vai pro espaço.
- Usar IA para escrever o relatório final. Mesmo que a descoberta seja real, texto gerado por IA tem vícios estilísticos que denunciam. Escreva à mão, com clareza.
- Não entender o que está sendo reportado. Pior que mandar lixo é mandar vulnerabilidade real mas descrita errada. O time gasta tempo tentando reproduzir algo que não faz sentido e marca seu relatório como inválido.
- Esquecer que severidade importa mais que quantidade. Um bug crítico bem reportado vale mais que 50 relatórios médios. Foque em profundidade, não em volume.
O impacto real para quem programa
Se você é dev, três implicações práticas. Primeiro: nunca use LLM como única camada de revisão de segurança do seu código. Use como assistente de brainstorming, mas valide cada achado com ferramenta dedicada (Semgrep, Snyk, CodeQL). Segundo: ao receber CVE ou alerta, confira se foi reportado por humano ou máquina — tratamento de falsos positivos mudou. Terceiro: se quiser entrar em bug bounty, foque em uma área específica (mobile, web, firmware) e aprenda a análise real, não a promptagem.
IA é ferramenta, não substituto. Em segurança, essa diferença entre usar e depender é o que separa pesquisador profissional de gerador de slop.
FAQ — Perguntas que devs realmente fazem
Vale a pena entrar em bug bounty em 2026?
Vale, mas expectativas precisam ser realistas. Concorrência subiu absurdamente com IA. Os primeiros 6 a 12 meses costumam ser de prejuízo financeiro. Quem persiste e aprende análise real consegue viver disso — mas não é mais o “ouro fácil” de 2018.
Como diferenciar relatório gerado por IA de análise humana?
Relatório humano tem contexto específico do app, cadeia de exploração testada, screenshots, request/response reais. Relatório de IA tem linguagem genérica, hedge words excessivos, falta de PoC executável e reproduzibilidade duvidosa.
A Apple vai bloquear totalmente relatórios feitos com IA?
Improvável. O que eles fizeram foi um limite de volume. Mas a tendência é que triadores passem a exigir evidência muito mais robusta. Se você usou IA para encontrar, tudo bem — mas precisa validar manualmente antes de submeter.
Quais ferramentas de análise estática real valem a pena em 2026?
CodeQL (GitHub), Semgrep, Snyk Code, Bearer e SonarQube. Todas fazem análise semântica do código, não estatística. Para mobile, MobSF e Frida são padrão. Complementar IA com essas ferramentas é o caminho.
Bug bounty de US$ 5 milhões da Apple é para qualquer um?
Não. Esse teto é para vulnerabilidades extremas — bypass de boot, execução remota sem interação do usuário, extração massiva de dados do iCloud. O pagamento médio real fica entre US$ 5 mil e US$ 50 mil. Não espere ficar rico no primeiro relatório.
Esse caso da Apple é só a ponta. A indústria inteira de segurança está recalibrando como lida com automação. Quem aprende a usar IA como ferramenta auxiliar sem terceirizar o pensamento crítico vai sair na frente — seja como pesquisador, seja como dev se protegendo.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.