Política de Estratégia de Testes de Segurança
1. Objetivo
Esta política define os requisitos para a estratégia de testes de segurança ao longo do ciclo de vida de aplicações classificadas como L1, L2 ou L3.
Testes de segurança não são uma fase - são um conjunto de práticas complementares que devem ser integradas em cada etapa do SDLC, desde a revisão de código até à validação em produção. Cada técnica tem âmbito e limitações distintas: o SAST encontra padrões no código estático mas não vê comportamento em runtime; o DAST valida a aplicação em execução mas não cobre todos os caminhos de código; o fuzzing descobre condições inesperadas que nenhuma das anteriores encontra de forma sistemática. A cobertura eficaz requer uma estratégia composta e proporcional ao risco.
O objetivo desta política é garantir que:
- A cobertura de testes de segurança é proporcional ao nível de criticidade da aplicação
- Os gates automáticos bloqueiam regressões graves antes da promoção a produção
- Os findings são geridos de forma centralizada, com triagem formal e SLA definido
- Os relatórios de testes são arquivados como evidência auditável por release
2. Técnicas de teste e obrigatoriedade
2.1 Matriz de obrigatoriedade por nível
| Técnica | L1 | L2 | L3 |
|---|---|---|---|
| SAST (análise estática) | Obrigatório | Obrigatório | Obrigatório |
| Secret detection | Obrigatório | Obrigatório | Obrigatório |
| SCA (composição de software) | Obrigatório (gate) | Obrigatório (gate) | Obrigatório (gate) |
| DAST (análise dinâmica) | Recomendado | Obrigatório em staging | Obrigatório em staging + critérios de cobertura |
| IAST (instrumentação em runtime) | Opcional | Recomendado | Obrigatório em staging |
| Fuzzing | Opcional | Recomendado (endpoints críticos) | Obrigatório (endpoints públicos + parsing) |
| Testes manuais de segurança | Não obrigatório | Recomendado por release | Obrigatório por release major |
| PenTesting | Não obrigatório | Obrigatório anual (ver Política de PenTesting) | Obrigatório (ver Política de PenTesting) |
2.2 SAST
- Executado em cada PR e em cada build de integração
- Configurado com rulesets derivados das guidelines de desenvolvimento por stack
- Findings classificados por severidade (Critical, High, Medium, Low, Informational)
- Supressões inline requerem comentário de justificação e são reportadas como métrica
2.3 DAST
- Executado em ambiente de staging após cada promoção bem-sucedida
- Requer ambiente com autenticação configurada para cobertura de endpoints protegidos
- Âmbito definido para evitar teste em sistemas externos reais (mocks ou sandbox para integrações)
- Cobertura mínima de endpoints por release documentada e medida
2.4 Fuzzing
- Focado em parsers de input, endpoints de upload, APIs que aceitem estruturas complexas
- Executado como job noturno ou por release, não necessariamente em cada PR
- Findings classificados e integrados no sistema centralizado de gestão
3. Gates de segurança por nível
Os thresholds de bloqueio devem ser documentados e versionados em gates-config.yaml ou equivalente:
| Gate | L1 | L2 | L3 |
|---|---|---|---|
| SAST Critical/High | Bloqueia merge | Bloqueia merge | Bloqueia merge |
| SAST Medium | Não aplicável | Alerta | Bloqueia merge |
| Secret detection (qualquer finding) | Bloqueia | Bloqueia | Bloqueia |
| SCA High/Critical CVE sem exceção | Bloqueia promoção | Bloqueia promoção | Bloqueia promoção |
| DAST High/Critical em staging | Não aplicável | Bloqueia promoção a produção | Bloqueia promoção a produção |
| Cobertura DAST abaixo de threshold | Não aplicável | Alerta | Bloqueia (threshold: 80% de endpoints) |
| Fuzzing com crash confirmado | Não aplicável | Bloqueia release | Bloqueia release |
Um gate configurado em modo apenas-alerta em L2/L3 deve ser registado como exceção formal com data de expiração. Exceções a gates de segurança expiradas sem reavaliação são tratadas como não-conformidade.
4. Gestão centralizada de findings
4.1 Plataforma unificada
Todos os findings de SAST, DAST, IAST, SCA e fuzzing devem ser consolidados numa plataforma centralizada (ex: DefectDojo, SonarQube Security Dashboard, GitHub Security, GitLab Security Dashboard), com:
- Deduplicação de findings com a mesma origem em múltiplas ferramentas
- Metadados unificados: CVE/CWE, severidade, ferramenta, commit, módulo, estado
- Histórico de estado (aberto, em progresso, resolvido, aceite, suprimido)
- Rastreabilidade entre finding e PR/commit de resolução
4.2 Triagem formal
Cada finding bloqueante deve ser triado com decisão documentada:
| Decisão | Condição | Requisito |
|---|---|---|
| CORRIGIR | Finding válido e exploitável | Estimativa de resolução; ticket criado |
| ACEITAR | Risco avaliado e aceite explicitamente | Exceção formal conforme Política de Exceções |
| SUPRIMIR (FP) | Falso positivo demonstrado | Evidência técnica; aprovação de AppSec |
| DIFERIR | Resolução adiada com justificação | Prazo definido; aceitação de risco temporária |
4.3 SLAs de triagem e resolução
| Severidade | SLA de triagem (todos os níveis) | SLA de resolução (L1) | SLA de resolução (L2) | SLA de resolução (L3) |
|---|---|---|---|---|
| Critical (CVSS ≥ 9.0) | 24 horas | 30 dias | 7 dias | 3 dias |
| High (CVSS 7.0–8.9) | 48 horas | 90 dias | 30 dias | 15 dias |
| Medium (CVSS 4.0–6.9) | 5 dias úteis | 180 dias | 90 dias | 45 dias |
| Low (CVSS < 4.0) | 10 dias úteis | 365 dias (ou o próximo ciclo de manutenção, se for anterior) | 180 dias | 90 dias |
Esta é a escada única de remediação do Manual, para todos os findings (testes, SCA, imagens, pipeline, pentest), e os KPI medem o seu cumprimento. Os prazos são o mínimo recomendado pelo Manual (escolha do Manual), não prazos regulamentares: o CRA pede que as vulnerabilidades sejam resolvidas e corrigidas «sem demora» (anexo I, parte II, ponto 2), e a NIS2 (art. 21.º, n.º 2, al. e)) e o DORA (art. 24.º, n.º 5) pedem processos de tratamento e correção, sem fixar dias. Com indício de exploração ativa (por exemplo, KEV) ou em produtos no âmbito do CRA, o prazo do nível é um tecto: estes sinais só antecipam. Prevalece o mais exigente de entre a lei, os supervisores, o sector e os contratos — ver a cláusula de precedência da Política 29 §7.
5. Rastreabilidade e evidência por release
Para cada release, deve existir evidência dos testes realizados:
- Relatórios de SAST, DAST, SCA e fuzzing (quando aplicável) arquivados como artefactos do pipeline
- Checklist de release preenchida com estado de cada gate
- Findings críticos com estado documentado (corrigidos, exceções aprovadas)
- Cobertura de DAST medida e registada
- Aprovação formal de release com referência aos relatórios (ver Política de Release Seguro)
6. Tratamento de falsos positivos
Falsos positivos (FP) são inevitáveis em qualquer ferramenta de análise estática ou dinâmica. O processo para suprimir um finding como FP deve ser formal:
- Evidência técnica da não-exploitabilidade documentada (code path analysis, prova de conceito falhada)
- Aprovação por AppSec Engineer para findings High/Critical
- Registo da supressão na plataforma centralizada com motivo, responsável e data
- Supressões inline no código (ex:
# nosec,// noqa) associadas ao identificador do finding suprimido e sujeitas a revisão periódica
Métricas de FP por ferramenta devem ser acompanhadas para calibrar as configurações dos scanners.
7. Eval suites para agentes AI
Quando o sistema inclui um agente AI em operação (ou quando um agente é parte do processo de teste — e.g. auditor de PR automatizado), incluímos eval suites entre as técnicas de teste obrigatórias. Não substituem SAST/DAST/SCA — cobrem a fatia agentic, que essas ferramentas não vêem.
7.1 Composição mínima
Por cada agente AI em nível A1+ no projecto:
| Componente | A1 | A2 | A3 | A4 |
|---|---|---|---|---|
| Regression tests de prompt / skill | Recomendado | Obrigatório | Obrigatório | Obrigatório |
| Abuse / red-team corpus (prompt injection, jailbreak) | — | Recomendado | Obrigatório | Obrigatório |
| Drift detection entre versões de modelo / prompt | — | Recomendado | Obrigatório | Obrigatório (janela curta) |
| A/B testing antes de promover skill / system prompt | — | Recomendado | Obrigatório | Obrigatório |
| Test telemetry correlacionada com sinais reais em produção (Cap. 12) | — | — | Recomendado | Obrigatório |
7.2 Operação
- Eval suite versionada em VCS, com
eval_run_idarquivado em cada release e ligado amandate_ref(Policy 38). - Corre em CI antes do merge de mudanças a system prompts / skill files / agent files, e após bump da versão do modelo (cross-link Cap. 07 US-19 e Cap. 06 §prompts-como-codigo).
- Eval failure bloqueia merge ou força descida de nível de autonomia até estar resolvido.
- Cobertura tem de ser proporcional ao nível de autonomia declarado — subir nível sem suite à medida é proibido.
7.3 Anti-padrões
- ❌ "Vibe checks" como única validação.
- ❌ Suite que nunca falha — falta cobertura adversarial.
- ❌ Métricas agregadas sem inspecção dos casos críticos.
- ❌ Suite num repositório separado da skill/prompt — drift silencioso.
📌 Detalhe operacional em Cap. 10 — IA nos testes §C5.
8. Responsabilidades
| Role | Responsabilidade |
|---|---|
| Developer | Executar análise local antes de submeter PR; triar findings de SAST em PRs; não suprimir sem registo |
| AppSec Engineer | Definir e calibrar thresholds; gerir plataforma centralizada de findings; aprovar supressões de FP High/Critical; definir estratégia de DAST |
| DevOps / SRE | Integrar ferramentas no pipeline; configurar jobs de DAST em staging; arquivar relatórios |
| Tech Lead | Garantir resolução de findings dentro de SLA; escalar conflitos entre timeline e gates |
| Product Manager | Aprovar aceitação de risco em findings que não podem ser resolvidos antes da release |
9. Revisão e auditoria desta política
Esta política deve ser revista anualmente ou após qualquer um dos seguintes eventos:
- Vulnerabilidade introduzida em produção que deveria ter sido detetada por uma das técnicas cobertas
- Adoção de nova técnica de teste ou ferramenta com impacto na estratégia
- Alteração de thresholds com impacto material na taxa de bloqueio de builds
10. Referências normativas e técnicas
| Referência | Relevância |
|---|---|
| SbD-ToE Cap. 10 - Testes de Segurança | Estratégia, gates, findings, triagem, SLA; C5 — eval suites para agentes |
| SbD-ToE Cap. 07 - CI/CD Seguro | SAST, DAST e SCA integrados no pipeline; US-19 eval gates |
SbD-ToE Cap. 02 — Requisitos (REQ-AGN-002) | Justificação do nível de autonomia evidenciada por eval suite |
Política de DAST e Fuzzing (01_policy-dast-fuzzing.md) | Requisitos específicos de DAST e Fuzzing |
Política de Release Seguro (20_policy-release-seguro.md) | Checklist de release e aprovação com base nos testes |
| Policy 38 — Mandates de Agentes AI | Eval suite ligada a mandate_ref |
| OWASP Testing Guide (v4.2) | Metodologia de referência para testes de segurança |
| OWASP DAST Guide | Boas práticas de análise dinâmica |
| OWASP Top 10 for LLM Applications (2025) | LLM01 prompt injection; LLM06 excessive agency — corpus de red-team |
| NIST SP 800-115 | Technical Guide to Information Security Testing |
| NIST AI RMF 1.0 (MEASURE-2.x) | Avaliação contínua de sistemas AI em produção |
| SSDF PW.8.2 | Test, evaluate, and remediate the software |
| DefectDojo | Plataforma de referência para gestão centralizada de findings |