Copilot, Cursor, Claude Code, ChatGPT — em 2026, cerca de 70% dos commits em SaaS brasileiros passam por sugestão de IA em algum momento (dados internos Varredura, base 500+ apps). Nenhum framework de segurança tradicional prevê isso. SOC 2 fala de code review, mas não de prompt review. OWASP fala de input validation, mas não de retrieval poisoning. ISO 27001 A.8.28 (secure coding) foi escrita antes de LLMs virarem parte do pipeline.

Aqui apresentamos o GIA-Safe (Governança de IA em Software), um framework operacional de 5 camadas desenhado para times que já usam código gerado por IA e precisam de segurança sem parar a produção. Ele não substitui SOC 2, ISO ou LGPD — se encaixa neles.

Visão geral

   ┌───────────────────────────────────────────────────┐
   │                    GIA-Safe                       │
   ├───────────────────────────────────────────────────┤
   │                                                   │
   │  Camada 1  ┌────────────────────────────────┐     │
   │            │  Prompt hygiene                │     │
   │            │  (dev-side, IDE)               │     │
   │            └───────────────┬────────────────┘     │
   │                            │                      │
   │  Camada 2  ┌───────────────▼────────────────┐     │
   │            │  Deterministic guardrails      │     │
   │            │  (linters, policies, gates)    │     │
   │            └───────────────┬────────────────┘     │
   │                            │                      │
   │  Camada 3  ┌───────────────▼────────────────┐     │
   │            │  SAST-in-CI                    │     │
   │            │  (semgrep, codeql, snyk)       │     │
   │            └───────────────┬────────────────┘     │
   │                            │                      │
   │  Camada 4  ┌───────────────▼────────────────┐     │
   │            │  Runtime varredura (DAST)      │     │
   │            │  (owasp/business logic)        │     │
   │            └───────────────┬────────────────┘     │
   │                            │                      │
   │  Camada 5  ┌───────────────▼────────────────┐     │
   │            │  Incident review loop          │     │
   │            │  (post-mortem → prompt tuning) │     │
   │            └────────────────────────────────┘     │
   │                                                   │
   └───────────────────────────────────────────────────┘

Cada camada tem um dono, uma frequência e um SLA. Sem isso, vira poster de parede.

Camada 1: Prompt hygiene

Objetivo: reduzir a probabilidade de sugestão insegura antes de ela existir.

Dono: Tech lead ou staff engineer, versionado como código.

Frequência: revisão mensal do prompt-base + a cada release do provedor.

Controles:

• Prompt base do time versionado em .cursor-rules, .copilot-instructions.md, ou equivalente. Explicita: linguagem, framework, padrão de erro, política de log, política de segredos, biblioteca de sanitização preferida.
• Contexto de repositório curado: um arquivo SECURITY.md que descreve threat model do serviço e é lido pelo assistente de IA em cada contexto.
• Templates de prompt para tarefas sensíveis: autenticação, autorização, upload, deserialização, integração externa. O time NÃO escreve estes prompts do zero.
• Vetos explícitos por regra: nunca dangerouslySetInnerHTML, nunca eval, nunca child_process.exec com variável, nunca segredo em código, etc.

Métrica: % de PRs com origem AI-assisted que precisam de mudança de segurança em code review. Meta: <20%.

Camada 2: Deterministic guardrails

Objetivo: bloquear padrões inseguros por regra automatizada, sem depender de IA revisora.

Dono: DevOps + segurança.

Frequência: contínua, em cada commit e cada PR.

Controles:

• Pre-commit hooks com git-secrets, detect-secrets, gitleaks.
• ESLint / Ruff / equivalents com plugins de segurança ativos: eslint-plugin-security, bandit para Python, brakeman para Rails.
• Policy-as-code: OPA/Rego para regras de infra (buckets, IAM, security groups).
• Branch protection: nada merge em main sem 1 revisor humano e todos os checks verdes.
• Dependency review: bloqueio automático de dependência com CVE crítica aberta.
• Regras Semgrep customizadas para padrões que aparecem em código gerado por IA (ex: useEffect sem cleanup, JWT em localStorage, CORS * com credentials).

Exemplo de regra Semgrep para JWT no localStorage:

rules:
  - id: jwt-in-localstorage
    pattern-either:
      - pattern: localStorage.setItem($KEY, $TOKEN)
      - pattern: localStorage.setItem("token", $X)
    message: JWT em localStorage é vulnerável a XSS. Use cookie HttpOnly.
    severity: ERROR
    languages: [javascript, typescript]

Métrica: taxa de bloqueio pré-merge / total de PRs. Meta: >5% (indica que o guardrail está pegando algo).

Camada 3: SAST-in-CI

Objetivo: análise estática profunda em cada PR e nightly.

Dono: engenharia de segurança.

Frequência: por PR + nightly full-repo scan.

Controles:

• SAST comercial ou open source: Semgrep Pro, Snyk Code, CodeQL, Checkmarx, SonarQube com plugin security. Um deles, com regra ativa, é melhor que três desligados.
• SBOM em cada build: syft + grype para conferir CVEs em dependências.
• License compliance: bloqueio de GPL/AGPL em produto proprietário.
• Baseline de dívida: falhas existentes viram issue, novas falhas bloqueiam merge.
• Explainer AI-friendly: quando SAST bloqueia, log deve ser compreensível pelo Copilot da próxima vez — se possível, alimentar prompt-base com o padrão bloqueado.

Métrica: MTTR de finding SAST crítico. Meta: <7 dias.

Camada 4: Runtime varredura (DAST)

Objetivo: pegar falhas que SAST não vê — configuração, runtime, comportamento, cadeia de chamadas reais.

Dono: engenharia de segurança + SRE.

Frequência: contínua em staging, semanal em produção (mínimo).

Controles:

• Varredura DAST autenticada contra staging e produção.
• Fuzzing de API contra especificação OpenAPI/GraphQL.
• Testes de business logic: IDOR, race condition, workflow abuse — coisas que exigem sessão e contexto, não regex.
• Testes específicos de LLM/RAG para endpoints de IA: prompt injection direta, extração de system prompt, function call abuse.
• Retesting automático após cada deploy que fecha uma issue.
• Dashboard de KPIs: MTTD, MTTR, densidade por 1000 LOC.

SAST vê o código; DAST vê o que o código faz. Ambos são necessários e nenhum substitui o outro. Isso é ainda mais crítico com código gerado por IA, que compila e passa em teste unitário mas quebra em runtime.

Métrica: MTTR de finding DAST crítico. Meta: <14 dias.

Camada 5: Incident review loop

Objetivo: cada incidente vira melhoria de prompt, guardrail ou teste — não apenas um post-mortem esquecido.

Dono: staff engineer + segurança.

Frequência: dentro de 5 dias úteis do incidente.

Controles:

• Post-mortem sem culpa com foco em "que camada falhou primeiro".
• Pergunta obrigatória: "IA sugeriu o código que causou o incidente?"
• Se sim: adicionar padrão à camada 1 (prompt base) + camada 2 (regra determinística).
• Se não: adicionar teste na camada 4.
• Backlog de melhorias com prazo de correção do controle.
• Comunicação pública de vulnerabilidades com CVE quando aplicável.

Métrica: % de incidentes com controle preventivo adicionado em 30 dias. Meta: 100%.

Sequência de adoção

Não implemente as 5 camadas de uma vez. Ordem sugerida:

1. Semana 1–2: Camada 2 (guardrails). Baixo custo, alto retorno.
2. Semana 3–6: Camada 3 (SAST-in-CI). Ferramenta + regras iniciais.
3. Semana 6–10: Camada 4 (DAST contínuo). Inicia em staging.
4. Semana 10–12: Camada 1 (prompt hygiene). Consolidar aprendizado das camadas 2-4.
5. Contínuo: Camada 5 (incident loop). Cada incidente alimenta as demais.

Ver também 12 vulnerabilidades de vibe coding para os padrões que a Camada 1 precisa vetar explicitamente.

Métricas de saúde do framework

Um GIA-Safe funcional exibe:

• >70% dos PRs AI-assisted passam sem intervenção de segurança.
• <7 dias MTTR SAST crítico.
• <14 dias MTTR DAST crítico.
• 100% de incidentes com controle preventivo derivado.
• 0 segredos em Git nos últimos 90 dias.
• 0 CVE crítica aberta há mais de 30 dias.

A Varredura opera a Camada 4 do GIA-Safe: varredura contínua de runtime, testes de business logic, testes específicos para LLM, retesting automatizado. Sem tocar em código-fonte. Rode agora.