Orquestrei 8 scanners de segurança num pipeline local pra quem coda com IA generativa

«Pipeline local que roda 8 scanners de segurança em paralelo sobre repo, imagem Docker ou filesystem, e agrupa findings por estratégia de correção — não por severidade.»

Repo: https://github.com/dtornieri/security_pipeline
Stack: FastAPI + Next.js + SQLite
Execução: "docker compose up"
Licença: PolyForm Noncommercial

A ideia surgiu depois de perceber um padrão recorrente no uso de IA generativa para desenvolvimento: a velocidade aumentou muito, mas a visibilidade sobre o que está entrando no projeto caiu na mesma proporção.

O contexto

Karpathy definiu “vibe coding” em 2025:

«“Give in to the vibes, embrace exponentials, and forget that the code even exists.”»

Na prática:

pede componente pro Claude/Cursor/Copilot
aceita código e dependências sugeridas
tudo funciona
próximo prompt

Depois de algumas semanas:

dezenas de dependências diretas
centenas de transitivas
imagens Docker herdadas de exemplos
pouca noção real da superfície de ataque

O problema não é só “código inseguro”.

É que IA generativa normalmente:

sugere libs antigas com CVEs públicos
não considera vulnerabilidades da imagem base
ignora problemas operacionais do Dockerfile
não detecta secrets hardcoded
não avalia configuração insegura

Em desenvolvimento tradicional isso já passava. Em fluxo acelerado por IA, passa ainda mais.

O problema das ferramentas atuais

Ferramentas como Snyk, Wiz e Aqua resolvem muita coisa, mas normalmente entram melhor em ambientes corporativos maiores.

No cenário local/individual, o fluxo costuma virar algo assim:

trivy ...
grype ...
semgrep ...
gitleaks ...

Depois:

vários JSONs
formatos diferentes
findings duplicados
sem priorização prática

Na maioria das vezes, ninguém consolida isso manualmente.

O que o projeto faz

Você sobe tudo localmente:

docker compose up -d

Depois acessa:

localhost:3000

E consegue escanear:

repositório Git
filesystem
imagem Docker

Os scanners atuais:

Trivy
Grype
OSV-Scanner
Docker Scout
Semgrep
Gitleaks
Hadolint
Syft

A ideia não foi evitar sobreposição.

Foi justamente permitir confirmação cruzada entre scanners diferentes.

O ponto principal: bucketing por estratégia de correção

A maioria das ferramentas organiza findings por severidade.

O problema é que isso frequentemente gera algo assim:

486 HIGH/CRITICAL

Na prática, vira ruído.

O pipeline tenta reorganizar isso por ação necessária.

Buckets atuais

"fixable"

Existe versão corrigida disponível.

Normalmente resolve com upgrade de pacote.

"patch_gap"

Existe fix upstream, mas a distro/base image ainda não publicou pacote.

Normalmente envolve:

trocar imagem base
esperar backport
avaliar outra distro

"no_fix"

Não existe correção disponível ainda.

Então a decisão muda:

mitigação
hardening
feature flag
monitoramento
compensação operacional

"code"

Problema diretamente no código/configuração:

secrets
SAST
Dockerfile
IaC

Exemplo real

Imagem Python escaneada:

486 HIGH/CRITICAL

Depois do bucketing:

fixable: 28
patch_gap: 0
no_fix: 458
code: 0

Os 486 continuam existindo.

Mas agora fica mais claro o que é acionável imediatamente e o que depende do ecossistema upstream.

Integração com IA

O pipeline gera prompts separados por bucket.

Exemplo:

fixable_app (28)
→ sugira upgrades exatos

patch_gap
→ vale trocar a base image?

no_fix
→ proponha mitigação

code
→ mostre snippets corrigidos

A resposta da IA melhora bastante quando o contexto já vem segmentado.

Segurança do próprio pipeline

O backend precisa acessar o Docker daemon para escanear imagens locais.

E aí entra um ponto delicado:

Docker socket praticamente equivale a root no host

Ao invés de montar "/var/run/docker.sock" direto no backend, coloquei um "docker-socket-proxy" na frente.

Fluxo:

backend → docker-proxy → docker.sock

Endpoints liberados:

"/images"
"/info"
"/version"
"/_ping"

Bloqueados:

criação de containers
exec
build
volumes
networks

A ideia foi reduzir o impacto caso algum scanner ou subprocess seja comprometido.

Trade-off: imagens remotas precisam ser "docker pull" antes do scan, porque "POST /images/create" fica bloqueado.

Stack

Backend

Python 3.12
FastAPI
SQLModel
SQLite

Frontend

Next.js 14
Tailwind
TypeScript

Outros

MCP server compatível com Claude Desktop
execução paralela via "asyncio + subprocess"

Algumas decisões foram intencionais:

SQLite porque o foco é local-first/single-user
sem auth porque não foi pensado para exposição pública
sem Postgres para evitar complexidade desnecessária

O que ele não tenta resolver

não substitui plataforma enterprise
não faz runtime detection
não substitui pentest
não substitui revisão humana
não resolve lógica de autorização/regra de negócio

O foco é reduzir cegueira operacional em fluxo acelerado por IA generativa.

Licença

Usei:

PolyForm Noncommercial 1.0.0

Porque a maior parte do valor do projeto vem da orquestração e consolidação sobre scanners open-source já existentes.

Não queria cair imediatamente no padrão:

wrapper + landing page + SaaS

sem retorno para o ecossistema original.

O que ainda quero melhorar

Principalmente:

reduzir falsos positivos duplicados
melhorar correlação entre scanners
adicionar cache incremental
melhorar análise de Docker layers
discutir melhor o modelo de isolamento do Docker socket

Esse último é o ponto que mais gostaria de ouvir opinião de quem trabalha mais próximo de AppSec/Container Security.

PRs, issues e críticas são bem-vindos.

Construído com IA. Revisado manualmente. E provavelmente ainda cheio de pontos cegos.