Como usar LLM open weight para auditar código e achar falhas

Quando li essa matéria do Olhardigital.com.br sobre a DepthFirst usando IA para achar falhas no TikTok, meu primeiro pensamento foi: “isso muda tudo para quem trabalha com segurança”. Não é exagero. A combinação de modelos abertos com fine-tuning agressivo está virando o jogo, e a maioria dos devs ainda não entendeu o tamanho do problema.

O que realmente aconteceu — e por que devs deveriam prestar atenção

A startup DepthFirst pegou o modelo GLM, da chinesa Z.ai, modificou o código e usou a versão destravada para varrer o componente de código aberto que o TikTok consome. Em poucas horas, a ferramenta encontrou uma cadeia de vulnerabilidades que permitia acessar câmera e rolo de fotos remotamente. O TikTok confirmou e corrigiu.

Na minha experiência com auditoria de código, esse tipo de cadeia (chamada de exploit chain) é o que diferencia um bug “teórico” de um ataque real. Um CVE sozinho raramente é catastrófico. O perigo mora na combinação: CVE-A dá leitura de memória, CVE-B escala privilégio, CVE-C escapa de sandbox. Junte três e você tem acesso remoto total.

O ponto crítico aqui não é o TikTok em si. É que o modelo de IA usado é aberto, gratuito e modificável. Enquanto Anthropic e OpenAI colocam travas pesadas em recursos de segurança ofensiva, modelos como GLM e DeepSeek podem ser baixados, destrinchados e ajustados para qualquer finalidade. Isso não é teoria — é o que acabou de acontecer.

Por que modelos chineses abertos são diferentes dos americanos restritos

Trabalho com integração de LLMs há anos, e a diferença operacional é brutal:

• OpenAI e Anthropic: refusals duros em temas como “como explorar vulnerabilidade X”. Mesmo via API, há classificadores que bloqueiam prompts ofensivos antes mesmo de chegar ao modelo.
• DeepSeek, Z.ai, Qwen, Yi: modelos com pesos públicos, fine-tunáveis localmente, sem nenhum filtro de saída se você remover as camadas de RLHF.

Quando você roda um modelo localmente, não existe “OpenAI moderation endpoint” te observando. O modelo faz exatamente o que o prompt pede. Isso é liberdade de pesquisa — e também um presente para atacantes.

Comparando com o ecossistema: o Llama 3 da Meta também é aberto, mas a Meta aplica licença que restringe uso por empresas grandes. Já os chineses distribuem sem tantas amarras. Para red teaming legítimo, esses modelos viraram padrão de fato.

Na Prática: como um dev pode usar IA para auditar dependências

Você não precisa reinventar o que a DepthFirst fez. Dá para começar pequeno, no seu próprio projeto, e ir escalando. Aqui vai um fluxo que testei em produção:

1. Mapeie suas dependências abertas. Rode npm audit, pip-audit, cargo audit ou govulncheck. Anote quais são open source e recebem patches com frequência.
2. Submeta cada CVE conhecido ao modelo. Pegue a descrição técnica do CVE no NVD e peça ao modelo: “Gere um PoC conceitual para essa CVE no contexto de uma API REST que consome esta biblioteca”.
3. Triagem manual do output. O modelo vai alucinar muito. Filtre apenas o que tem coerência com seu stack real.
4. Valide em ambiente isolado. Nunca rode PoC em produção. Use Docker com network desativado ou VMs descartáveis.
5. Documente e comunique. Se achar algo relevante em dependência de terceiros, siga disclosure responsável (90 dias é o padrão).

Um exemplo real que rodei semana passada: subi o DeepSeek-Coder-V2 localmente via Ollama e pedi para ele revisar um trecho de um middleware Node.js que processa uploads. Ele apontou três pontos que eu tinha deixado passar — incluindo um path traversal sutil em multer que só aparecia com filenames Unicode específicos.

// Trecho vulnerável que o modelo pegou:
const storage = multer.diskStorage({
  destination: (req, file, cb) => cb(null, 'uploads/'),
  filename: (req, file, cb) => {
    // ❌ Nunca use o nome original direto — path traversal esperando acontecer
    cb(null, file.originalname);
  }
});

// Versão corrigida:
const path = require('path');
const storage = multer.diskStorage({
  destination: (req, file, cb) => cb(null, 'uploads/'),
  filename: (req, file, cb) => {
    const safe = path.basename(file.originalname)
      .replace(/[^a-zA-Z0-9._-]/g, '_')
      .slice(0, 100);
    const unique = `${Date.now()}-${crypto.randomUUID()}`;
    cb(null, `${unique}-${safe}`);
  }
});

O modelo não substitui um pentester humano. Mas acelera brutalmente a fase de reconhecimento.

Comparativo: ferramentas que valem a pena testar

Na minha rotina, Semgrep + revisão com LLM local pega 80% do que importa. O resto fica para pentest manual.

Erros comuns que devs cometem ao usar IA para segurança

Cuidado com essas armadilhas — todas vi acontecer em times reais:

• Confiar cegamente no output do modelo. LLM alucina CVE IDs, versões afetadas e até bibliotecas inteiras. Sempre valide no NVD antes de sair corrigindo.
• Colar código de produção em APIs públicas. Parece óbvio, mas já vi gente colando .env e chaves no ChatGPT pedindo “ache vulnerabilidades”. Use modelos locais para código sensível.
• Tratar IA como substituto do pentester. Modelo acha padrões no código. Não entende contexto de negócio, não testa autenticação real, não roda exploit contra infraestrutura viva.
• Esquecer o disclosure responsável. Se achar vuln em software de terceiros, não sai postando no Twitter. Contacta o maintainer, dá 90 dias, publica depois.
• Rodar modelo sem GPU suficiente e reclamar que “IA é ruim”. Modelo de 70B params no CPU é inviável. Use quantized (Q4_K_M) ou modelos menores (7B–13B) para tarefas focadas.
• Ignorar a cadeia. Dev foca em corrigir um CVE isolado e não percebe que combinado com outro vira exploit. Mapeie dependências cruzadas.

O “porquê” por trás do problema

O caso TikTok expõe uma tensão real: quanto mais inteligente a ferramenta, mais perigosa nas mãos erradas. Mas também mais útil para defesa. A mesma IA que automatiza busca por falhas é usada pela equipe de segurança do TikTok para varrer o próprio código antes do release.

Quando eu rodo análise de segurança hoje, tenho duas opções: esperar um CVE público sair e correr atrás do patch, ou usar IA para identificar padrões suspeitos proativamente. A segunda opção está virando padrão de mercado — empresas como GitHub (Copilot Security), Snyk e CodeRabbit já vendem isso como produto.

A diferença é que modelos abertos como GLM democratizaram o acesso. Antes, só empresas com budget para contratar NCC Group ou Trail of Bits faziam isso. Agora qualquer dev com uma GPU 3090 e paciência pode fazer triage do próprio código. Isso é uma revolução silenciosa.

FAQ — Perguntas que devs realmente fazem

IA vai substituir pentesters humanos?
Não no curto prazo. LLM acelera reconhecimento e gera hipóteses, mas validação, criatividade de cadeia e engenharia social continuam sendo humanas. O profissional que usar IA como ferramenta vai substituir quem não usa.

É legal usar modelos chineses para red teaming?
Depende da jurisdição e do que você faz com o resultado. Pesquisa em ambiente isolado, em software que você mantém ou tem autorização, é legal. Usar para atacar terceiros é crime — modelo aberto não te dá escudo jurídico.

Quanto de GPU preciso para rodar DeepSeek-Coder localmente?
Versão 6.7B roda em 16GB de VRAM com quantização Q4. Versão 33B precisa de 48GB+. Se você tem uma RTX 4090 (24GB), fica entre os dois. Llama 3.1 8B Instruct também é excelente para essa tarefa e roda em hardware mais modesto.

Como diferenciar IA sendo usada para defesa de IA sendo usada para ataque?
Pelo output e pelo contexto. Defesa gera relatórios com mitigação, PoC em ambiente controlado, disclosure responsável. Ataque gera weaponized exploits distribuídos, vazamentos em fóruns, monetização via ransomware. A ferramenta é a mesma — o uso é que define.

Vale a pena aprender SAST manual se IA já faz isso?
Vale, e muito. Você precisa entender o que o modelo está dizendo para validar se está certo. Quem não entende de segurança vai aceitar alucinações como verdade — e isso quebra mais sistema do que qualquer CVE.

Checklist prático para começar hoje

• Suba um modelo local (Ollama + DeepSeek-Coder-V2 ou Llama 3.1 8B).
• Rode scan nas suas dependências com npm audit / pip-audit.
• Cole 3-5 trechos críticos do seu código no modelo local e peça análise de vulnerabilidades.
• Valide cada sugestão contra documentação oficial da biblioteca.
• Documente o que mudou e por quê.
• Configure Semgrep ou CodeQL no CI para detectar regressões.

Essa matéria do Olhardigital é só a ponta do iceberg. A corrida armamentista entre IA ofensiva e defensiva já começou, e devs que ficarem parados vão ser os primeiros a serem pegos desprevenidos. A ferramenta está aí. O conhecimento para usar bem também. O que falta é parar de tratar segurança como coisa de “outro time” e incorporar no fluxo diário.

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