📚 Addon-12 — Formação em Uso Seguro de IA e Tooling Pervasivo

🎯 Objetivo

Com a adoção pervasiva de ferramentas automatizadas (SAST, DAST, SCA, GitHub Copilot, code generators, LLMs, SOAR, monitoring), é crítico que a formação cubra quando confiar vs. quando validar.

Este addon define conteúdos formativos essenciais para cada capítulo técnico do SbD-ToE, assegurando que colaboradores compreendem:

Quando automação é determinística (pode confiar)
Quando é não-determinística (validar sempre)
Limites de automação (guardrails)
Antipadrões comuns (práticas inseguras)

🧠 Princípio Fundamental

Ferramentas são instrumentos técnicos, não decisores autónomos.

✅ Automação assiste humanos em tarefas repetitivas e objetivas
❌ Automação não decide em contextos que exigem julgamento, contexto ou trade-offs
⚠️ Outputs de IA sempre requerem validação antes de produção

📖 Conteúdos Formativos por Capítulo Técnico

Cap 01 — Classificação de Aplicações

Ferramentas: Assistentes de classificação de risco, templates automatizados

O que formar:

❌ Antipadrão: Aceitar classificação gerada automaticamente sem revisão
✅ Boa prática: Classificação é decisão de governação, não automática
✅ Validar: Critérios de criticidade (dados, exposição, impacto) contra contexto real
✅ Escalar: Classificação L3 sempre requer AppSec + Gestão

Exemplo prático:

# ❌ MAU: Aceitar classificação gerada
risk_level: L2  # Gerado por ferramenta

# ✅ BOM: Validar e justificar
risk_level: L3
justification: "Aplicação processa dados GDPR + exposição pública + regulação NIS2"
approved_by: "AppSec Lead + CTO"
validation_date: "2026-01-04"

Cap 02 — Requisitos de Segurança

Ferramentas: Geradores de requisitos (LLMs, templates automatizados)

O que formar:

❌ Antipadrão: Copiar requisitos gerados sem adaptar ao contexto
✅ Boa prática: Requisitos devem ser específicos, mensuráveis, rastreáveis
✅ Validar: Completude (todos os domínios críticos cobertos?)
✅ Validar: Aplicabilidade (requisito faz sentido para esta aplicação?)

Exemplo prático:

❌ MAU: Requisito genérico gerado
REQ-AUTH-001: "A aplicação deve implementar autenticação segura"

✅ BOM: Requisito específico e validado
REQ-AUTH-001: "Autenticação via OAuth 2.0 + PKCE com MFA obrigatório para roles admin"
- Aplicável: ✓ (aplicação web com dados GDPR)
- Mensurável: ✓ (teste automatizado valida PKCE + MFA)
- Rastreável: ✓ (ligado a THR-001 threat model)

Cap 03 — Threat Modeling

Ferramentas: LLMs para threat analysis (ChatGPT, GitHub Copilot para threat lists)

O que formar:

❌ Antipadrão: Aceitar threat model gerado sem validação de AppSec
✅ Boa prática: Threat models são contextuais, exigem conhecimento do sistema
✅ Validar: Ameaças são realistas para esta arquitetura?
✅ Validar: Controlos propostos são adequados?

Exemplo prático:

❌ MAU: Ameaça genérica de LLM
THR-001: "SQL Injection"
Controlo: "Use prepared statements"

✅ BOM: Ameaça contextualizada
THR-001: "SQL Injection em endpoint /api/users/search (aceita query param não-validado)"
Arquitetura: Node.js + PostgreSQL
Controlo: "Parametrized queries via node-postgres + input validation com Joi schema"
Validação: "Teste SAST (Semgrep rule sql-injection) + DAST (OWASP ZAP payload)"
Aprovação: "AppSec Lead validou arquitetura e controlo"

Cap 04 — Arquitetura Segura

Ferramentas: Geradores de diagramas (Mermaid, PlantUML), assistentes de ADR

O que formar:

❌ Antipadrão: Aceitar diagramas de arquitetura gerados sem validação
✅ Boa prática: Arquitetura exige trade-offs (segurança vs. performance, custo, complexidade)
✅ Validar: Diagrama reflete implementação real?
✅ Validar: ADRs têm análise de segurança e aprovação formal?

Exemplo prático:

❌ MAU: ADR gerado sem contexto
ADR-001: "Use microservices"
Razão: "Better scalability"

✅ BOM: ADR com análise de segurança
ADR-001: "Adotar API Gateway (Kong) para autenticação centralizada"
Contexto: "Aplicação L3 com 5 microservices, cada um com autenticação própria (inconsistente)"
Decisão: "Kong API Gateway + OAuth 2.0 + rate limiting"
Trade-offs:
  - ✅ Segurança: Autenticação centralizada, rate limiting, auditoria
  - ❌ Complexidade: Novo componente a manter
  - ❌ Custo: Licença Kong Enterprise
Ameaças mitigadas: THR-001 (credential stuffing), THR-002 (DoS)
Aprovação: "Arch Lead + AppSec + CTO"

Cap 05 — Dependências, SBOM, SCA

Ferramentas: SCA (Snyk, Dependabot, npm audit, safety)

O que formar:

❌ Antipadrão: Aceitar todas as sugestões de atualização sem análise
❌ Antipadrão: Ignorar todos os alertas (alert fatigue)
✅ Boa prática: Entender falsos positivos vs. verdadeiros riscos
✅ Validar: CVE é aplicável ao nosso uso da biblioteca?
✅ Validar: Atualização quebra compatibilidade?

Exemplo prático:

❌ MAU: Ignorar CVE sem análise
CVE-2024-12345 (lodash): ALTA
Ação: ❌ Ignorado (muitos alertas)

✅ BOM: Analisar e decidir formalmente
CVE-2024-12345 (lodash): ALTA - Prototype pollution
Análise:
  - Aplicável? ✓ (usamos lodash.set com input do utilizador)
  - Exploitável? ✓ (endpoint público /api/config)
  - Mitigação disponível? ✓ (atualizar para 4.17.22)
Decisão: "Atualizar para 4.17.22 + teste de regressão"
Aprovação: "Tech Lead + AppSec"
Evidência: "PR-123 com testes + validação staging"

Cap 06 — Desenvolvimento Seguro

Ferramentas: GitHub Copilot, ChatGPT, code generators, Cursor, Tabnine

O que formar:

❌ Antipadrão: Aceitar código gerado sem ler/testar
❌ Antipadrão: Aceitar batch de sugestões (commit tudo de uma vez)
✅ Boa prática: Sempre ler código sugerido linha a linha
✅ Boa prática: Sempre testar com unit tests antes de commit
✅ Boa prática: Sempre validar contra requisitos de segurança

Exemplo prático:

# ❌ MAU: Código gerado por Copilot aceito sem revisão
def authenticate_user(username, password):
    # Copilot gerou isto:
    query = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
    # ❌ SQL Injection! Mas dev não leu, só aceitou

# ✅ BOM: Código revisado e corrigido
def authenticate_user(username, password):
    # Dev leu sugestão, identificou problema, corrigiu:
    query = "SELECT * FROM users WHERE username=%s AND password=%s"
    cursor.execute(query, (username, hash_password(password)))
    # ✅ Parametrized query + password hashing
    # ✅ Teste unitário criado: test_sql_injection_blocked()
    # ✅ Validado contra REQ-AUTH-001

Práticas de prompt engineering seguro:

❌ MAU: Prompt vago
"Generate authentication code"

✅ BOM: Prompt com requisitos de segurança
"Generate authentication code using bcrypt for password hashing, 
parametrized SQL queries to prevent injection, and session tokens 
with 15-minute expiry. Include unit tests for SQL injection and 
password strength validation."

Cap 07 — CI/CD Seguro

Ferramentas: Pipeline automation (GitHub Actions, GitLab CI, Jenkins)

O que formar:

❌ Antipadrão: Confiar cegamente em gates automáticos sem entender critérios
✅ Boa prática: Entender quando gates são determinísticos vs. não-determinísticos
✅ Validar: Porque o gate bloqueou? É falso positivo?
✅ Escalar: Quando solicitar exceção formal?

Exemplo prático:

# Gate automático bloqueou deploy
❌ MAU: Dev ignora gate (cria PR para remover gate)

✅ BOM: Dev analisa e decide
Gate bloqueado: "SAST encontrou SQL injection em user_controller.py linha 45"
Análise:
  - É verdadeiro? ✓ (query concatena string de user input)
  - É crítico? ✓ (endpoint público, dados sensíveis)
Ação: "Corrigir código (parametrized query) + teste unitário"
Resultado: "Gate passa após correção"

# Caso de falso positivo
Gate bloqueado: "SAST: Uso de MD5 (inseguro)"
Análise:
  - Contexto: Usado para checksum de ficheiro, não criptografia
  - É falso positivo? ✓
Ação: "Solicitar exceção formal com justificação"
Aprovação: "AppSec valida contexto, aprova exceção com validade 6 meses"

Cap 08 — IaC e Infraestrutura

Ferramentas: Geradores de Terraform/CloudFormation, assistentes de IaC

O que formar:

❌ Antipadrão: Copiar templates sem validar configurações de segurança
✅ Boa prática: IaC é código, requer mesma validação que aplicação
✅ Validar: Permissões IAM/RBAC são mínimo privilégio?
✅ Validar: Recursos críticos têm encryption at rest/in transit?

Exemplo prático:

# ❌ MAU: Template gerado com permissões excessivas
resource "aws_iam_role" "app_role" {
  # Copilot gerou isto:
  policy = "*"  # ❌ Wildcard! Permite tudo
}

# ✅ BOM: Revisado e corrigido para mínimo privilégio
resource "aws_iam_role" "app_role" {
  policy = jsonencode({
    Statement = [{
      Effect = "Allow"
      Action = [
        "s3:GetObject",
        "s3:PutObject"
      ]
      Resource = "arn:aws:s3:::my-app-bucket/*"  # ✅ Scope específico
    }]
  })
  # ✅ Validado contra REQ-IAM-001 (mínimo privilégio)
  # ✅ Teste: terraform plan + checkov scan
}

Cap 09 — Containers e Imagens

Ferramentas: Geradores de Dockerfile, assistentes de Kubernetes manifests

O que formar:

❌ Antipadrão: Usar imagens base sem validar origem/vulnerabilidades
✅ Boa prática: Imagens base devem ser oficiais, atualizadas, scaneadas
✅ Validar: Dockerfile não tem secrets embebidos?
✅ Validar: Container roda como non-root?

Exemplo prático:

# ❌ MAU: Dockerfile gerado com práticas inseguras
FROM ubuntu:latest  # ❌ Tag "latest" não é reproduzível
RUN apt-get install -y curl git  # ❌ Pacotes desnecessários
ENV API_KEY="sk-abc123..."  # ❌ Secret embebido!
USER root  # ❌ Roda como root

# ✅ BOM: Revisado e corrigido
FROM ubuntu:22.04  # ✅ Tag específica, reproduzível
RUN apt-get update && apt-get install -y curl \
    && rm -rf /var/lib/apt/lists/*  # ✅ Apenas o necessário + cleanup
# ✅ Secret via environment variable (injetado em runtime)
USER nonroot:nonroot  # ✅ Non-root user
# ✅ Validado: docker scan, trivy scan
# ✅ Teste: container inicia com user nonroot

Cap 10 — Testes de Segurança

Ferramentas: Test generators (Copilot for tests, ChatGPT, test automation)

O que formar:

❌ Antipadrão crítico: Testes gerados que apenas "provam" o código implementado (tautologia)
✅ Boa prática: Testes devem validar requisitos, não implementação
✅ Validar: Testes cobrem casos negativos (falhas, entradas inválidas)?
✅ Validar: Testes são independentes da implementação?

Exemplo prático - O PROBLEMA DA TAUTOLOGIA:

# ❌ MAU: Teste gerado por IA que apenas "prova" o código implementado
# Código implementado (com bug!)
def calculate_discount(price, user_role):
    if user_role == "admin":
        return price * 0.5  # ❌ BUG: Admin não deveria ter 50% desconto!
    elif user_role == "premium":
        return price * 0.8
    else:
        return price

# Teste gerado por Copilot (aceitou o bug!)
def test_calculate_discount():
    # ❌ Teste apenas "prova" que código funciona como implementado
    assert calculate_discount(100, "admin") == 50  # ✓ passa, mas valida BUG!
    assert calculate_discount(100, "premium") == 80
    assert calculate_discount(100, "guest") == 100

# ✅ BOM: Teste baseado em REQUISITOS, não implementação
# REQ-DISC-001: "Descontos: premium=20%, guest=0%. Admin não tem desconto especial"

def test_calculate_discount_against_requirements():
    # ✅ Testa contra requisito REQ-DISC-001
    assert calculate_discount(100, "admin") == 100  # ❌ FALHA! Bug detectado
    assert calculate_discount(100, "premium") == 80  # ✓
    assert calculate_discount(100, "guest") == 100   # ✓
    
    # ✅ Testa casos negativos (não gerados por IA!)
    assert calculate_discount(100, None) raises ValueError
    assert calculate_discount(-10, "premium") raises ValueError
    assert calculate_discount(100, "unknown_role") == 100  # default behavior

Checklist de validação de testes gerados:

Teste valida requisito (REQ-XXX), não implementação?
Teste cobre casos negativos (inputs inválidos, falhas)?
Teste é independente de detalhes de implementação?
Teste falharia se implementação violar requisito?
Teste tem assertions claras (não apenas "não crash")?

Outro exemplo - Testes de segurança:

# ❌ MAU: Teste gerado que não testa segurança real
def test_authentication():
    # Copilot gerou:
    response = login("user", "password")
    assert response.status_code == 200  # ❌ Só testa se funciona, não se é seguro!

# ✅ BOM: Teste valida requisito de segurança REQ-AUTH-001
def test_authentication_security():
    # ✅ Testa SQL injection
    response = login("admin' OR '1'='1", "anything")
    assert response.status_code == 401  # Deve bloquear
    
    # ✅ Testa brute force protection
    for i in range(10):
        login("user", "wrong_password")
    response = login("user", "correct_password")
    assert response.status_code == 429  # Rate limited
    
    # ✅ Testa password strength
    response = register("user", "123")  # Weak password
    assert response.status_code == 400
    assert "password too weak" in response.json()["error"]

Cap 11 — Deploy Seguro

Ferramentas: Automação de deploy (Terraform, Helm, Spinnaker, Argo)

O que formar:

❌ Antipadrão: Confiar cegamente em rollback automático
✅ Boa prática: Entender quando rollback automático é seguro vs. quando exige decisão humana
✅ Validar: Rollback de BD pode causar perda de dados?
✅ Escalar: Quando acionar rollback manual vs. automático?

Exemplo prático:

# Deploy automation com guardrails
❌ MAU: Rollback automático sem validação
on_error: rollback  # ❌ Pode causar perda de dados se BD mudou!

✅ BOM: Rollback com validação de contexto
on_error:
  if: deployment_type == "binary"
    then: rollback_automatic  # ✅ Seguro: apenas binário
  elif: deployment_type == "database"
    then: rollback_manual_approval  # ⚠️ Exige decisão humana (perda de dados?)
    notify: ["DevOps", "DBA", "AppSec"]
  elif: deployment_type == "config"
    then: rollback_automatic  # ✅ Seguro: apenas config

Cap 12 — Monitorização e Operações

Ferramentas: SOAR, alertas automáticos, correlação comportamental

O que formar:

❌ Antipadrão: Confiar cegamente em alertas automáticos sem validação
❌ Antipadrão: Deixar SOAR executar ações críticas sem validação humana
✅ Boa prática: Entender quando alertas são determinísticos vs. heurísticos
✅ Validar: Alerta de correlação comportamental pode ser falso positivo?
✅ Escalar: Quando acionar resposta automática vs. manual?

Exemplo prático:

# Alerta determinístico (pode confiar)
alert: "CPU >90% por 5 minutos"
action: auto_scale  # ✅ Determinístico, ação segura

# Alerta não-determinístico (validar sempre)
alert: "Padrão de comportamento suspeito: User X downloads 10GB em 1h"
❌ MAU: SOAR bloqueia user automaticamente
✅ BOM: SOAR notifica IR para validação humana
  - IR valida: Processo legítimo de backup? Exfiltração?
  - Decisão humana: Bloquear ou exceção formal
  - Rastreabilidade: Decisão registada com justificação

🚨 Limites de Automação (Guardrails) - Síntese

O que ferramentas NÃO PODEM fazer sozinhas:

Ação	Automação Permitida?	Razão
Classificar aplicação em L1/L2/L3	❌ NÃO	Decisão de governação, contexto organizacional
Gerar requisitos de segurança	⚠️ Assistir	Humano valida completude e aplicabilidade
Criar threat models	⚠️ Assistir	AppSec valida ameaças são realistas para arquitetura
Aceitar CVEs sem análise	❌ NÃO	Pode ser falso positivo ou não-aplicável
Gerar código sem revisão	❌ NÃO	Pode ter vulnerabilidades ou bugs lógicos
Gerar testes que "provam" código	❌ NÃO	Testes devem validar requisitos, não implementação
Aprovar exceções a findings	❌ NÃO	Exige justificação formal + aprovação humana
Purgar logs automaticamente	❌ NÃO	Evidência é irreversível
Rollback de BD automaticamente	❌ NÃO	Pode causar perda de dados
Bloquear users por correlação	❌ NÃO	Correlação comportamental é heurística (falso positivo)

✅ Práticas de Validação de Outputs de IA

Checklist Universal (Todos os Capítulos)

Ao usar ferramentas de geração/assistência:

Ler código/output linha a linha (não aceitar em batch)
Testar contra requisitos (não apenas "funciona")
Validar contexto (output faz sentido para esta aplicação?)
Cobrir casos negativos (falhas, entradas inválidas)
Documentar origem (código gerado por IA? marcar claramente)
Rastrear decisões (por que aceitar/rejeitar sugestão?)
Escalar dúvidas (não assumir correção se não compreender)

Prompt Engineering Seguro

❌ MAU: Prompt vago
"Generate code for user authentication"

✅ BOM: Prompt com requisitos de segurança explícitos
"Generate user authentication code that:
- Uses bcrypt for password hashing (work factor 12)
- Implements rate limiting (5 attempts per 15 min)
- Validates input with Joi schema (email format, password min 12 chars)
- Uses parametrized SQL queries (prevent injection)
- Returns generic error messages (no user enumeration)
- Logs failed attempts with IP and timestamp
- Includes unit tests for SQL injection and brute force
- References REQ-AUTH-001 and REQ-AUTH-002"

📊 Métricas de Eficácia da Formação

A formação em uso seguro de IA é eficaz quando:

Métrica	Meta	Medição
PRs com código gerado não-testado	0	Code review bloqueia
Testes gerados que apenas "provam" código	0	QA valida contra requisitos
Exceções a CVEs sem justificação	0	Gates CI/CD bloqueiam
Incidentes por confiança cega em alertas	0	Auditoria de resposta a incidentes
Classificações L3 sem AppSec approval	0	Auditoria de governação
Rollbacks de BD sem validação humana	0	Logs de deployment
SOAR actions críticas sem IR validation	0	Logs de SOAR

🎓 Integração na Formação por Perfil

Developer

Módulos obrigatórios:

✅ Uso seguro de GitHub Copilot e code assistants
✅ Prompt engineering seguro (requisitos explícitos)
✅ Validação de código gerado (ler + testar + requisitos)
✅ Testes contra requisitos (não tautologia!)
✅ Quando escalar (dúvidas de segurança)

Labs práticos:

Lab 1: Identificar vulnerabilidades em código gerado por IA
Lab 2: Criar testes baseados em requisitos (não implementação)
Lab 3: Prompt engineering para gerar código seguro

QA/Testes

Módulos obrigatórios:

✅ Limitações de test generators
✅ Validação de testes gerados (cobrem requisitos?)
✅ Casos negativos (falhas, entradas inválidas)
✅ Independência de implementação

Labs práticos:

Lab 1: Identificar testes "tautológicos" (provam código, não requisitos)
Lab 2: Expandir testes gerados com casos negativos
Lab 3: Validação de cobertura (requisitos vs. linhas de código)

DevOps/SRE

Módulos obrigatórios:

✅ Quando confiar em automação de deploy/rollback
✅ Guardrails de rollback (BD, binário, config)
✅ Quando escalar para validação manual
✅ Monitorização de ações automáticas (auditoria)

Labs práticos:

Lab 1: Simular rollback de BD com perda de dados
Lab 2: Configurar guardrails em pipeline de deploy
Lab 3: Auditoria de ações automáticas (SOAR logs)

AppSec

Módulos obrigatórios:

✅ Falsos positivos/negativos de SAST/DAST
✅ Validação de threat models gerados
✅ Gestão de exceções a findings
✅ Limites de automação (guardrails)

Labs práticos:

Lab 1: Análise de falso positivo (contexto determina risco)
Lab 2: Validação de threat model gerado por LLM
Lab 3: Criação de template de exceção formal

IR/Ops

Módulos obrigatórios:

✅ Limitações de SOAR
✅ Quando alertas exigem validação humana
✅ Correlação comportamental (falsos positivos)
✅ Quando acionar resposta automática vs. manual

Labs práticos:

Lab 1: Identificar falso positivo em correlação comportamental
Lab 2: Configurar guardrails em SOAR
Lab 3: Simulação de incidente com decisão humana obrigatória

Gestão

Módulos obrigatórios:

✅ Quando aceitar risco de automação
✅ Quando exigir governação explícita
✅ Trade-offs (velocidade vs. segurança)
✅ Responsabilidade por decisões automatizadas

Casos de estudo:

Caso 1: Deploy automático causou perda de dados (falta de guardrails)
Caso 2: SOAR bloqueou utilizador legítimo (falso positivo não-validado)
Caso 3: Código gerado introduziu vulnerabilidade (falta de revisão)

🏁 Conclusão

Formação em uso seguro de IA não é opcional: é crítica para prevenir:

❌ Vulnerabilidades introduzidas por código gerado não-revisado
❌ Testes que "provam" bugs em vez de validar requisitos
❌ Decisões automatizadas sem governação em contextos críticos
❌ Confiança cega em alertas/correlações heurísticas

Princípio fundamental: Ferramentas assistem, humanos decidem. Automação é instrumento, não substituto de julgamento humano em contextos não-determinísticos.

Versão: 1.0
Última Atualização: Jan 2026
Mantido por: AppSec + RH Team
Revisão: Anual ou por trigger de novo risco

🎯 Objetivo​

🧠 Princípio Fundamental​

📖 Conteúdos Formativos por Capítulo Técnico​

Cap 01 — Classificação de Aplicações​

Cap 02 — Requisitos de Segurança​

Cap 03 — Threat Modeling​

Cap 04 — Arquitetura Segura​

Cap 05 — Dependências, SBOM, SCA​

Cap 06 — Desenvolvimento Seguro​

Cap 07 — CI/CD Seguro​

Cap 08 — IaC e Infraestrutura​

Cap 09 — Containers e Imagens​

Cap 10 — Testes de Segurança​

Cap 11 — Deploy Seguro​

Cap 12 — Monitorização e Operações​

🚨 Limites de Automação (Guardrails) - Síntese​

✅ Práticas de Validação de Outputs de IA​

Checklist Universal (Todos os Capítulos)​

Prompt Engineering Seguro​

📊 Métricas de Eficácia da Formação​

🎓 Integração na Formação por Perfil​

Developer​

QA/Testes​

DevOps/SRE​

AppSec​

IR/Ops​

Gestão​

🏁 Conclusão​

🎯 Objetivo

🧠 Princípio Fundamental

📖 Conteúdos Formativos por Capítulo Técnico

Cap 01 — Classificação de Aplicações

Cap 02 — Requisitos de Segurança

Cap 03 — Threat Modeling

Cap 04 — Arquitetura Segura

Cap 05 — Dependências, SBOM, SCA

Cap 06 — Desenvolvimento Seguro

Cap 07 — CI/CD Seguro

Cap 08 — IaC e Infraestrutura

Cap 09 — Containers e Imagens

Cap 10 — Testes de Segurança

Cap 11 — Deploy Seguro

Cap 12 — Monitorização e Operações

🚨 Limites de Automação (Guardrails) - Síntese

✅ Práticas de Validação de Outputs de IA

Checklist Universal (Todos os Capítulos)

Prompt Engineering Seguro

📊 Métricas de Eficácia da Formação

🎓 Integração na Formação por Perfil

Developer

QA/Testes

DevOps/SRE

AppSec

IR/Ops

Gestão

🏁 Conclusão