Como o AI slop travou o bug bounty da Apple em 2025

Segundo o Tecnoblog.net, a Apple travou o próprio programa de bug bounty. Pesquisadores agora têm limite de submissões — e o motivo é um problema que eu vejo acontecer toda semana em projetos de IA: alucinação em escala industrial. Nesta análise, vou destrinchar o que aconteceu, por que modelos de linguagem são péssimos em achar vulnerabilidades reais e como isso muda o jogo pra quem trabalha com segurança ofensiva.

O que realmente aconteceu com o programa da Apple

A Apple opera um dos programas de bug bounty mais generosos do mercado, com pagamentos que podem chegar a US$ 5 milhões (cerca de R$ 25,7 milhões em conversão direta). Em 2025, ela lançou uma nova leva de recompensas e abriu as portas para receber notificações em volume. O que ninguém previu foi o tsunami de relatórios gerados por IA.

O termo usado pela própria Apple foi “AI slop” — aquele conteúdo de baixa qualidade produzido automaticamente. No contexto de segurança, isso se traduz em pesquisadores (e amadores) rodando modelos de linguagem contra o código-fonte e nos endpoints, coletando saídas e submetindo cada “achado” como se fosse uma vulnerabilidade real. O resultado: os analistas da maçã passaram mais tempo triando lixo do que caçando falhas de verdade.

A solução foi dura: limite de submissões por pesquisador, com cooldown de 30 dias quando o teto é atingido. Casos graves ainda podem pedir exceção, o que mostra que a empresa tenta preservar o canal crítico sem deixar a fila virar um depósito de falso positivo.

Por que IAs alucinam vulnerabilidades (e isso é arquitetural, não acidental)

Na minha experiência, esse é um dos mal-entendidos mais perigosos sobre LLMs aplicados a segurança. Um transformer não “encontra” bugs — ele prevê a próxima sequência de tokens mais provável dado um prompt. Quando você pede para um modelo “analisar este código em busca de vulnerabilidades”, ele retorna padrões que se parecem com vulnerabilidades que ele viu em dados de treino. Não há análise semântica real do fluxo de dados.

Três armadilhas técnicas explicam o problema:

• Falta de grounding no modelo de ameaça: o LLM não sabe qual é o ativo que está sendo protegido, quem é o atacante, nem qual superfície de ataque é alcançável.
• Confusão entre padrão e exploitabilidade: uma função que parece com um sink de SQL injection não significa que existe um caminho de dados até ela controlado por input externo.
• Repetição de más práticas históricas: modelos treinados em CVEs antigos regurgitam recomendações defasadas (tipo “use MD5 com salt”) porque é o que aparece com mais frequência no corpus.

Na Prática: como um scanner ingênuo “acha” bugs falsos

Para mostrar o problema em código, montei um exemplo de um analisador baseado em regex (que é basicamente o que muitos wrappers de LLM fazem por baixo):

import re

# Scanner ingenuo - "estilo LLM wrapper"
PATTERNS_SUSPEITOS = [
    (r"eval\s*\(", "Code Injection: uso de eval() detectado"),
    (r"SELECT.*FROM.*WHERE.*\+\s*\w+", "SQL Injection: concatenação direta"),
    (r"password\s*=\s*['\"]", "Hardcoded credential detectado"),
    (r"os\.system\s*\(", "Command Injection: os.system() é perigoso"),
    (r"innerHTML\s*=", "XSS: atribuição direta de innerHTML"),
]

def scan_file(path: str) -> list:
    findings = []
    with open(path, "r", encoding="utf-8") as f:
        content = f.read()
    for pattern, message in PATTERNS_SUSPEITOS:
        for match in re.finditer(pattern, content, re.IGNORECASE):
            findings.append({
                "line": content[:match.start()].count("\n") + 1,
                "snippet": match.group(0),
                "message": message,
                "severity": "HIGH"  # sempre HIGH, porque confianca!
            })
    return findings

# Resultado: 47 falsos positivos em um projeto legitimo
print(len(scan_file("app.py")))

Esse código é caricato, mas representa o que acontece quando alguém cola a saída bruta de um LLM num relatório. A regex acima vai marcar eval() mesmo em comentários, vai acusar hardcoded credentials em arquivos de teste, e vai transformar qualquer innerHTML em XSS — inclusive onde o valor vem de uma função interna que escapa tudo. Um analista humano gasta 20 minutos para descartar cada um. A Apple recebia milhares por dia.

O scanner correto precisa de três coisas que um LLM puro não entrega bem: taint analysis (rastrear de onde vem o dado), reachability (chegar até o sink?) e contexto do sanitizer (existe uma função de limpeza no meio do caminho?).

Comparativo: como cada gigante lida com bug bounty e IA

Vale comparar a postura da Apple com a de outras empresas, porque cada uma encontrou um atalho diferente:

Perceba o padrão: cada empresa resolveu o problema de um jeito. A Microsoft proibiu; o Google exigiu prova; a Meta construiu uma ferramenta interna; a Apple cortou o volume. Não existe bala de prata — e isso vale também para o seu próprio fluxo de code review.

Erros comuns que devs cometem ao usar IA para encontrar vulnerabilidades

Trabalho com revisão de código e pen tests há anos, e estes são os deslizes que mais vejo em times que tentam acelerar a busca por falhas com IA:

1. Confiar no scoring de severidade do modelo. LLM devolve “Critical” sem entender o contexto. Severidade vem do impacto, não da aparência do código.
2. Submeter relatório cru sem reproduzir o exploit. Sem PoC funcional, é ruído. A Apple confirmou que muitos relatórios nem tinham prova de conceito.
3. Não validar versão e ambiente. O bug pode existir no source do GitHub mas não no build distribuído. Versão, flag de compilação e patch level importam.
4. Misturar achado de SAST com bug bounty. SAST tradicional (Semgrep, CodeQL) já tem taxa alta de falso positivo. Rodar LLM por cima só piora.
5. Esquecer do modelo de ameaça. “A API aceita input sem validação” não é vulnerabilidade se a API é interna e não tem autenticação quebrada. Sem threat model, qualquer coisa vira CVE.
6. Não cruzar com inteligência de exploit pública. Se ninguém explora, o EPSS é baixo, e o impacto real pode ser mínimo mesmo que o achado seja tecnicamente correto.

O que muda para quem trabalha com segurança em 2026

A decisão da Apple é um sinal claro para o mercado: programas maduros vão endurecer a triagem. Se você é pesquisador independente ou lab pequeno (como a italiana Bynario, citada na matéria, que achou 50+ bugs no macOS recente mas travou no limite), vai precisar investir em automação própria de validação antes de submeter.

Do lado defensivo, o recado também é forte. Use IA para acelerar a leitura de código, não para substituir a análise. No meu fluxo, a IA serve para três coisas:

• Resumir diffs grandes antes da revisão manual.
• Sugerir cenários de abuso a partir de uma feature nova.
• Gerar casos de teste de fuzzing com base em schemas conhecidos.

O que ela não faz é decidir se algo é vulnerável. Isso ainda é trabalho humano, com razão.

Como configurar um gate anti-AI-slop no seu próprio programa

Se você roda um programa de segurança interno ou gerencia o canal de bug bounty de uma empresa, a lição da Apple serve como template. Monte um funil em três camadas:

1. Pré-filtro automatizado: rejeite relatórios sem PoC, sem versão afetada e sem descrição do impacto. Isso corta 60% do lixo de cara.
2. Score de confiança: use ferramentas como Semgrep, CodeQL ou Snyk para validar se o padrão alegado é explorável. Se a ferramenta concorda, o relatório sobe na fila.
3. Análise humana focada: sobraram os relatórios de alto valor. Esses são os que merecem o tempo do seu time senior.

O segredo é mover o trabalho braçal para a máquina e reservar o humano para o que realmente exige julgamento. É o oposto do que muitos times fazem hoje — humano triando 500 relatórios para achar 5 reais.

FAQ — Perguntas frequentes de devs sobre IA e bug bounty

1. Posso usar IA para gerar relatórios de bug bounty?

Tecnicamente pode, mas cada programa define suas regras. A Microsoft proíbe explicitamente. A Apple, na prática, vai te cortar no limite. Google e Meta aceitam, desde que você prove execução manual. Resumo: use como assistente, não como autor.

2. Quais ferramentas de IA são úteis para security research?

Modelos de linguagem ajudam em leitura de código, sumarização e geração de payloads. Para achar bugs de verdade, prefira SAST baseado em regras (Semgrep, CodeQL), DAST (Burp, ZAP) e fuzzers (AFL, libFuzzer). A IA entra como complemento, não substituto.

3. Por que LLMs alucinam tantas vulnerabilidades falsas?

Porque eles não analisam fluxo de dados nem avaliam alcançabilidade. Eles geram texto que parece com um relatório de bug porque foi isso que aprenderam. Sem grounding semântico, a taxa de falso positivo é estruturalmente alta.

4. Vale a pena participar de bug bounty com ajuda de IA em 2026?

Vale se você souber filtrar e validar antes de submeter. Submeter em massa com saída crua de LLM vai te banir dos programas principais. Quem monetiza de verdade hoje combina automação agressiva com revisão humana criteriosa.

5. O limite da Apple é temporário ou veio para ficar?

Tendência é endurecer. Conforme os modelos ficam mais baratos, o volume de submissões ruins só cresce. Programas sem triagem automatizada vão复制ar o limite da Apple ou fechar para novatos, como já fizeram HackerOne em algumas categorias.

Veredito

A Apple fez o que qualquer time saturado faria: cortou o ruído na origem. A decisão é dura, mas reflete uma verdade que devs precisam internalizar — IA generativa é uma ferramenta de produtividade, não um analista de segurança. Use para ler mais rápido, sugerir vetores e gerar payloads. Mas a decisão final sobre o que é vulnerável continua sendo humana. Quem entender isso vai entregar relatórios que os programas de bounty ainda aceitam de braços abertos. Quem não entender, vai bater no teto de 30 dias da Apple.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.