Práticas de Desenvolvimento de Segurança

Segurança é responsabilidade de todos, não apenas do time de segurança. Boas práticas de segurança são construídas nos workflows de desenvolvimento, não adicionadas no final. Este guia cobre práticas de segurança práticas para times de desenvolvimento.

Segurança no SDLC

Codificação Segura

Práticas de Desenvolvimento

CODIFICAÇÃO SEGURA
══════════════════

VALIDAÇÃO DE INPUT:
─────────────────────────────────────
Sempre valide:
├── Input de usuário
├── Parâmetros de API
├── Uploads de arquivo
├── Headers
├── Nunca confie no input
└── Whitelist sobre blacklist

Exemplo:
// Ruim
const userId = req.params.id;
db.query(`SELECT * FROM users WHERE id = ${userId}`);

// Bom
const userId = parseInt(req.params.id, 10);
if (isNaN(userId)) throw new Error('ID Inválido');
db.query('SELECT * FROM users WHERE id = ?', [userId]);

ENCODING DE OUTPUT:
─────────────────────────────────────
├── HTML encode para contexto HTML
├── URL encode para URLs
├── SQL parametrize para queries
├── Encoding consciente do contexto
└── Prevenir injeção

AUTENTICAÇÃO:
─────────────────────────────────────
├── Use bibliotecas comprovadas
├── Requisitos fortes de senha
├── Rate limiting no login
├── Gestão segura de sessão
├── MFA onde apropriado
└── Não crie sua própria

AUTORIZAÇÃO:
─────────────────────────────────────
├── Verifique em cada request
├── Enforcement server-side
├── Princípio do menor privilégio
├── Não confie no cliente
└── Controle de acesso explícito

GESTÃO DE SECRETS:
─────────────────────────────────────
├── Nunca no código
├── Variáveis de ambiente
├── Gerenciadores de secrets (Vault, AWS Secrets)
├── Rotacione regularmente
├── Diferente por ambiente
└── Secrets protegidos

Code Review

Foco em Segurança

CODE REVIEW DE SEGURANÇA
════════════════════════

CHECKLIST DE REVIEW:
─────────────────────────────────────
Para todo PR:
├── ☐ Validação de input presente
├── ☐ Sem secrets hardcoded
├── ☐ SQL parametrizado
├── ☐ Checks de auth em place
├── ☐ Dados sensíveis protegidos
├── ☐ Error handling seguro
├── ☐ Logging sanitizado
└── Review consciente de segurança

RED FLAGS:
─────────────────────────────────────
Fique atento a:
├── Concatenação de string em queries
├── eval() ou similar
├── Senhas/chaves hardcoded
├── Checks de auth faltando
├── Controles de segurança desabilitados
├── CORS muito permissivo
├── Dados sensíveis em logs
└── Padrões ruins conhecidos

CHECKS AUTOMATIZADOS:
─────────────────────────────────────
Gates de CI/CD:
├── SAST scan
├── Scan de dependências
├── Detecção de secrets
├── Lint de segurança
└── Falhe build se crítico

Gestão de Vulnerabilidades

SLAs e Priorização

TRIAGEM DE VULNERABILIDADES
═══════════════════════════

SEVERIDADE E SLAs:
─────────────────────────────────────
CRÍTICO (CVSS 9.0+):
├── SLA: 24 horas
├── Exploração ativa possível
├── Drop everything
└── Exemplo: RCE, SQL injection

ALTO (CVSS 7.0-8.9):
├── SLA: 7 dias
├── Impacto significativo
├── Prioridade alta
└── Exemplo: Auth bypass

MÉDIO (CVSS 4.0-6.9):
├── SLA: 30 dias
├── Impacto limitado
├── Sprint normal
└── Exemplo: XSS stored

BAIXO (CVSS 0.1-3.9):
├── SLA: 90 dias
├── Impacto mínimo
├── Quando possível
└── Exemplo: Info disclosure

WORKFLOW:
─────────────────────────────────────
1. Descobrir → Triagem
2. Classificar severidade
3. Atribuir owner
4. Rastrear no backlog
5. Corrigir e verificar
6. Documentar

Melhores Práticas

Para Segurança de Desenvolvimento

1. Shift-left — Cedo é melhor
2. Automatize — CI/CD com security gates
3. Treine — Codificação segura
4. Revise — Segurança em todo PR
5. Responda — SLAs para vulns

Anti-Padrões

ERROS DE SEGURANÇA:
✗ Segurança como afterthought
✗ Sem automação
✗ Secrets em código
✗ Ignorar scan results
✗ Sem SLAs para vulns
✗ Não treinar devs
✗ Confiar em input
✗ Rolar própria crypto

Soluções Relacionadas

• Melhores práticas de segurança para times
• Práticas de desenvolvimento focado em segurança
• Testes de segurança em ágil