7 min leitura • Guide 512 of 877
Como Gerenciar Projetos de Segurança com Sprints de Desenvolvimento
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
| Categoria | Prioridade | Tratamento na Sprint |
|---|---|---|
| Vulnerabilidade crítica | P0 - Imediato | Largar tudo |
| Issue de alto risco | P1 - Esta sprint | Capacidade reservada |
| Melhoria proativa | P2 - Planejado | Priorização normal |
| Débito de segurança | P3 - Backlog | Quando capacidade permite |
| Requisito de compliance | Driven por deadline | Milestone 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 │
└─────────────────────────────────────────────────┘