GitScrum / Docs
Todas as Boas Práticas

Gerenciar Projetos de Segurança em Sprints | GitScrum

Integre trabalho de segurança em sprints ágeis. Equilibre melhorias de segurança com entrega de features mantendo momentum no GitScrum.

7 min de leitura

Trabalho de segurança frequentemente compete com entrega de features por capacidade de sprint, criando tensão entre proteção e progresso. O GitScrum ajuda times a integrar tarefas de segurança em sprints regulares, rastrear remediação de vulnerabilidades e manter visibilidade sobre postura de segurança sem descarrilar desenvolvimento de features.

Categorias de Trabalho de Segurança

CategoriaPrioridadeTratamento na Sprint
Vulnerabilidade críticaP0 - ImediatoLargar tudo
Issue de alto riscoP1 - Esta sprintCapacidade reservada
Melhoria proativaP2 - PlanejadoPriorização normal
Débito de segurançaP3 - BacklogQuando capacidade permite
Requisito de complianceDriven por deadlineMilestone planejado

Segurança no Sprint Planning

ALOCAÇÃO DE CAPACIDADE DA SPRINT

┌─────────────────────────────────────────────────┐
│  BREAKDOWN TÍPICO DA SPRINT                     │
│                                                 │
│  Desenvolvimento de Features:     60-70%        │
│  ├── Novas features                             │
│  └── Melhorias de features                      │
│                                                 │
│  Trabalho de Segurança:           15-25%        │
│  ├── Correções de vulnerabilidades              │
│  ├── Melhorias de segurança                     │
│  ├── Updates de dependências                    │
│  └── Testes de segurança                        │
│                                                 │
│  Outros:                          10-15%        │
│  ├── Bug fixes                                  │
│  ├── Débito técnico                             │
│  └── Melhorias de processo                      │
└─────────────────────────────────────────────────┘

BUFFER DE SEGURANÇA NA SPRINT:
┌─────────────────────────────────────────────────┐
│  Reserve 20% da capacidade de segurança para:   │
│  • Vulnerabilidades críticas descobertas no meio│
│  • Updates urgentes de dependências             │
│  • Incidentes de segurança                      │
│                                                 │
│  Se não usado: puxar do backlog de segurança    │
└─────────────────────────────────────────────────┘

Estrutura do Backlog de Segurança

ORGANIZAÇÃO DO BACKLOG DE SEGURANÇA

Labels:
├── [security-critical] - Explorável, correção imediata
├── [security-high] - Risco significativo
├── [security-medium] - Risco moderado
├── [security-low] - Issues menores
├── [security-proactive] - Melhorias
└── [security-compliance] - Regulatório

Categorias de Tarefas:
┌─────────────────────────────────────────────────┐
│  1. REMEDIAÇÃO DE VULNERABILIDADES              │
│     Tarefas de scans de segurança, pen tests    │
│     Severidade clara e deadline de remediação   │
│                                                 │
│  2. FEATURES DE SEGURANÇA                       │
│     Novas capacidades de segurança              │
│     MFA, criptografia, logs de auditoria        │
│                                                 │
│  3. HARDENING                                   │
│     Melhorias proativas de segurança            │
│     Configuração de headers, CSP, etc.          │
│                                                 │
│  4. UPDATES DE DEPENDÊNCIAS                     │
│     Patches de segurança em dependências        │
│     Ciclo regular de updates                    │
│                                                 │
│  5. COMPLIANCE                                  │
│     Requisitos regulatórios                     │
│     Trabalho driven por deadline                │
└─────────────────────────────────────────────────┘

Template de Tarefa de Vulnerabilidade

TAREFA DE VULNERABILIDADE DE SEGURANÇA

┌─────────────────────────────────────────────────┐
│  Título: [CVE-2024-XXXX] SQL Injection em Search│
│  Labels: [security-critical] [backend] [api]    │
│                                                 │
│  SEVERIDADE: Crítica (CVSS 9.8)                 │
│  FONTE: Finding de teste de penetração          │
│  DEADLINE: 48 horas a partir da descoberta      │
│                                                 │
│  DETALHES DA VULNERABILIDADE:                   │
│  Localização: /api/search endpoint              │
│  Tipo: SQL Injection                            │
│  Impacto: Exfiltração de dados, escalação privs │
│  Explorabilidade: Baixa complexidade, sem auth  │
│                                                 │
│  REMEDIAÇÃO:                                    │
│  1. Parametrizar query em search.service.ts     │
│  2. Adicionar validação de input                │
│  3. Implementar regra WAF (temporário)          │
│                                                 │
│  VERIFICAÇÃO:                                   │
│  ☐ Fix implementado e revisado                  │
│  ☐ Pen test revalidado                          │
│  ☐ Monitoramento de exploração ativo            │
│  ☐ Atualização de documentação                  │
└─────────────────────────────────────────────────┘

Priorização Baseada em Risco

FRAMEWORK DE PRIORIZAÇÃO DE SEGURANÇA

MATRIZ DE RISCO:
┌─────────────────────────────────────────────────┐
│                                                 │
│        Alto Impacto                             │
│              │                                  │
│   ┌──────────┼──────────┐                       │
│   │ URGENTE  │ CRÍTICO  │                       │
│   │ (planejar│ (imediato│                       │
│   │  sprint) │  agora)  │                       │
│   ├──────────┼──────────┤                       │
│   │ BACKLOG  │ AGENDAR  │                       │
│   │ (quando  │ (próximas│                       │
│   │possível) │ sprints) │                       │
│   └──────────┴──────────┘                       │
│   Baixa         │    Alta Explorabilidade       │
│   Explorab.                                     │
│                                                 │
└─────────────────────────────────────────────────┘

SLA POR SEVERIDADE:
┌─────────────────────────────────────────────────┐
│  Crítico (CVSS 9.0-10.0): 48 horas              │
│  Alto (CVSS 7.0-8.9): 7 dias                    │
│  Médio (CVSS 4.0-6.9): 30 dias                  │
│  Baixo (CVSS 0.1-3.9): 90 dias                  │
└─────────────────────────────────────────────────┘

Integrando com Features

SEGURANÇA NA DEFINITION OF DONE

PARA TODAS AS FEATURES:
┌─────────────────────────────────────────────────┐
│  ☐ Input validation implementada                │
│  ☐ Autenticação/autorização verificada          │
│  ☐ Sem secrets em código                        │
│  ☐ Logging de segurança adicionado              │
│  ☐ OWASP top 10 considerado                     │
└─────────────────────────────────────────────────┘

PARA FEATURES SENSÍVEIS:
┌─────────────────────────────────────────────────┐
│  ☐ Threat modeling realizado                    │
│  ☐ Review de segurança aprovado                 │
│  ☐ Teste de penetração (se aplicável)           │
│  ☐ Documentação de segurança atualizada         │
└─────────────────────────────────────────────────┘

CHECKLIST DE PR:
┌─────────────────────────────────────────────────┐
│  ☐ Sem vulnerabilidades conhecidas introduzidas │
│  ☐ Dependências com versões seguras             │
│  ☐ Secrets não expostos                         │
│  ☐ Security scan CI passando                    │
└─────────────────────────────────────────────────┘

Monitoramento de Postura de Segurança

DASHBOARD DE SEGURANÇA

MÉTRICAS DE VULNERABILIDADES:
┌─────────────────────────────────────────────────┐
│  Vulnerabilidades Abertas:                      │
│  ├── Críticas: 0  (SLA: 48h)                    │
│  ├── Altas: 3     (SLA: 7d, avg age: 4d)        │
│  ├── Médias: 12   (SLA: 30d, avg age: 15d)      │
│  └── Baixas: 28   (SLA: 90d, avg age: 45d)      │
│                                                 │
│  Trend: ↓ 15% vs mês passado                    │
└─────────────────────────────────────────────────┘

MÉTRICAS DE REMEDIAÇÃO:
┌─────────────────────────────────────────────────┐
│  MTTR (Tempo Médio para Remediar):              │
│  ├── Crítico: 18 horas (meta: <48h) ✓           │
│  ├── Alto: 5 dias (meta: <7d) ✓                 │
│  ├── Médio: 22 dias (meta: <30d) ✓              │
│  └── Baixo: 60 dias (meta: <90d) ✓              │
│                                                 │
│  Compliance com SLA: 95%                        │
└─────────────────────────────────────────────────┘

MÉTRICAS DE SPRINT:
┌─────────────────────────────────────────────────┐
│  Capacidade de segurança usada: 22% ✓           │
│  Issues de segurança completadas: 8             │
│  Débito de segurança adicionado: 3              │
│  Net security: -5 issues (melhoria!)            │
└─────────────────────────────────────────────────┘

Comunicação com Stakeholders

RELATÓRIO DE SEGURANÇA PARA EXECUTIVOS

RESUMO MENSAL:
┌─────────────────────────────────────────────────┐
│  Status de Segurança: 🟢 SAUDÁVEL               │
│                                                 │
│  Destaques:                                     │
│  • 0 vulnerabilidades críticas abertas          │
│  • 100% compliance com SLAs de remediação       │
│  • Pen test Q1 aprovado com findings menores    │
│                                                 │
│  Riscos:                                        │
│  • 3 dependências com EOL em 60 dias            │
│  • Backlog de hardening crescendo (atenção)     │
│                                                 │
│  Próximos Passos:                               │
│  • Projeto de upgrade de dependências (Sprint 5)│
│  • Security training para novos devs (Janeiro)  │
│                                                 │
│  Investimento vs Risco:                         │
│  • 20% de capacidade → 0 incidentes no quarter  │
└─────────────────────────────────────────────────┘

Soluções Relacionadas