Conteúdo detalhado
🎯 O objetivo do scanner
Auditoria de segurança costuma ser um evento raro: alguém roda umas ferramentas antes de um deploy importante e esquece o resto do tempo. Com IA local ilimitada e sempre ligada, dá pra inverter isso — um worker varre seu repositório continuamente, atrás de segredos vazados, dependências vulneráveis e padrões inseguros, sem você gastar nada além de eletricidade.
🆕 Novo aqui?
"Segredo" é qualquer credencial que vaza pro código por engano: chave de API, token, senha de banco. "Scanner de segurança" é um programa que lê o código procurando esses segredos e outros riscos conhecidos. Aqui ele vira um worker 24/7: um processo que roda sozinho, em ciclo, sem precisar de você apertando o botão.
🔑 O que esse funcionário caça
- •Segredos vazados: chaves de API e senhas que entraram no commit por descuido.
- •Dependências vulneráveis: bibliotecas com CVEs conhecidos (npm, pip).
- •Padrões inseguros: coisas suspeitas que merecem o olho de um revisor.
- •O que é novo: alertar só quando aparece algo que ontem não existia.
📊 Por que isso só faz sentido em local
- Varredura contínua = muitas chamadas ao modelo. Na nuvem, cada chamada tem pedágio; 24/7 fica caro rápido.
- Seu código-fonte é sensível — mandar ele para um servidor de terceiro só pra "analisar" é exatamente o que você quer evitar.
- Local resolve os dois de uma vez: ilimitado e privado. O código nunca sai da máquina.
🗺️ Desenho da solução
Antes do código, o desenho. O segredo de um bom scanner não é jogar tudo no LLM — é uma esteira: ferramentas baratas e precisas detectam, o modelo local só triagem e explica, e o cron repete. Cada peça faz o que faz de melhor.
Leia da esquerda para a direita: o repositório alimenta as ferramentas determinísticas (passo 1), os achados vão para o modelo local que triagem o risco (passo 2), e sai um relatório datado. A seta ciano embaixo é o cron (passo 3) fechando o laço 24/7.
Esses três passos são exatamente as próximas três seções. Em resumo:
Varredura determinística primeiro
Ferramentas como gitleaks e npm audit acham segredos e CVEs com precisão — rápidas, baratas e sem alucinação. Elas fazem a detecção bruta.
O modelo local triagem os achados
O LLM entra depois: lê a lista de achados, classifica risco (alto/médio/baixo) e sugere a correção em linguagem clara. Ele explica, não inventa.
Cron agenda e mantém 24/7
Um agendador roda o script a cada poucas horas, grava relatorio-AAAA-MM-DD.md e só te avisa quando aparece algo novo. Sem ruído.
🔍 Passo 1 · varredura determinística
A tentação é pedir pro LLM "ache os problemas de segurança". Não faça isso primeiro. Um modelo pode esquecer um segredo óbvio ou inventar um que não existe. Ferramentas determinísticas — que sempre dão a mesma resposta pra mesma entrada — fazem a detecção com precisão cirúrgica. Rode-as antes. O LLM entra só no passo 2.
⌨️ Copy-run: as ferramentas que detectam
Objetivo: achar segredos vazados e dependências vulneráveis sem tocar no modelo. Rode na raiz do seu projeto.
Como verificar: se houver segredo, o gitleaks sai com código diferente de zero e lista arquivo + linha. O npm audit / pip-audit imprimem os CVEs com severidade. Repo limpo = saída vazia e exit 0.
💡 Dica prática
Combine os dois mundos de propósito: a ferramenta determinística é precisa mas burra (acha o padrão, não entende o contexto); o LLM é flexível mas falível (entende, mas pode errar). Deixe cada um no que é bom — ferramenta detecta, modelo explica. Nunca o contrário.
🤖 Passo 2 · o agente revisa
Agora o modelo local ganha utilidade real. Ele não procura nada — recebe a lista de achados das ferramentas e faz o que humano faria numa revisão: dá um nível de risco a cada item e explica a correção em uma linha. Você chama o modelo pela API local compatível com OpenAI (a do Ollama, da trilha 3.5).
⌨️ Copy-run: o modelo local triagem um achado
Objetivo: mandar um achado para o modelo e receber risco + correção. Endpoint localhost — nada sai da máquina.
Como verificar: a resposta JSON traz .choices[0].message.content com algo como "Risco: alto — revogue a chave na AWS, remova do histórico e use variável de ambiente." A temperature baixa mantém a triagem consistente.
O ponto-chave é a divisão de trabalho: o modelo é ótimo pra priorizar e explicar, péssimo pra ser a fonte da verdade. Veja onde confiar nele e onde não:
✓ Bom uso do modelo
- ✓Priorizar: o que é grave de verdade vs ruído
- ✓Explicar o risco em português claro
- ✓Sugerir a correção concreta
- ✓Resumir 50 achados num parágrafo
✗ Mau uso do modelo
- ✗Ser o único que "procura" segredos
- ✗Confiar nele pra dizer que está tudo limpo
- ✗Aplicar correções sozinho, sem você ver
- ✗Inventar CVEs que a ferramenta não achou
⏰ Passo 3 · agendar 24/7
Detecção + triagem viram um funcionário quando rodam sozinhas. É aqui que o cron (o agendador por tempo, da seção 4.2) entra: ele dispara o script a cada poucas horas, grava um relatório datado e — a parte que mantém você são — só te incomoda quando há algo novo desde a última rodada.
⌨️ Copy-run principal: o script da esteira
Objetivo: juntar tudo — gitleaks detecta, a API local triagem, e sai relatorio-AAAA-MM-DD.md. Salve como scan.sh.
Como verificar: rode bash scan.sh uma vez. Deve aparecer ok: relatorios/relatorio-2026-06-29.md e o arquivo conter a triagem do modelo. Tudo via localhost.
⏱️ Copy-run: deixar rodando 24/7
Objetivo: rodar a cada 6 horas, automático. Abra crontab -e e adicione:
Como verificar: depois de algumas horas, confira ~/scan.log e a pasta relatorios/ ganhando arquivos datados. Para "alertar só no novo", compare o relatório de hoje com o de ontem (diff) e só notifique se houver diferença.
💡 Dica prática
O inimigo de um worker 24/7 é a fadiga de alerta: se ele te avisa toda rodada, você para de ler. Por isso o "alertar só no que é novo" não é detalhe — é o que decide se você vai confiar no funcionário ou silenciá-lo na primeira semana.
🔒 Endurecendo o worker
Funciona — agora torne confiável. Um scanner que grita falso positivo o dia todo, ou que escapa do escopo, vira mais um barulho ignorado. E há uma linha que não se cruza: o código não vai pra lugar nenhum. Estas práticas separam um brinquedo de um funcionário em quem você confia.
✓ Faça
- ✓Manter o modelo 100% local (endpoint localhost)
- ✓Definir escopo: pastas e tipos de arquivo que importam
- ✓Manter uma allowlist de falsos positivos conhecidos
- ✓Tratar o relatório como sugestão — você decide e corrige
✗ Evite
- ✗Mandar trechos de código pra uma API de nuvem "só pra ajudar"
- ✗Deixar o agente aplicar correções sem revisão humana
- ✗Varrer tudo sem escopo (lento e cheio de ruído)
- ✗Confiar que "sem alerta" = "100% seguro"
⚠️ Box de alerta: a regra de ouro
Todo o sentido deste worker é varrer código sem expor código. Se em algum ponto você mandar os achados — ou pior, os trechos — para um serviço de terceiro, perdeu o jogo: criou um novo vazamento ao caçar vazamentos.
- •Tudo local: ferramentas e modelo rodam na sua máquina; o tráfego não sai de localhost (ou da sua tailnet privada).
- •Revisão humana: o scanner prioriza e sugere; quem revoga uma chave e abre um PR é você.
Auto-checagem (opcional): por que rodar gitleaks / npm audit ANTES de chamar o modelo local?
📌 Resumo do módulo
Próximo módulo:
4.4 — Vigia da web caçando oportunidades