Política de Gestão de Vulnerabilidades

1. Objetivo

Definir o processo de gestão de vulnerabilidades em sistemas, aplicações, infraestrutura, ambientes e integrações utilizadas pela plataforma Jogaê, incluindo identificação, classificação, tratamento, registro e comunicação.

2. Identificação de Vulnerabilidades

• Dependências backend: composer audit executado semanalmente e antes de cada deploy.
• Dependências frontend: npm audit executado semanalmente e antes de cada deploy.
• Monitoramento contínuo: Sentry captura exceções e anomalias em tempo real.
• Revisão de código: Revisão antes de merge para branch principal, com foco em OWASP Top 10.
• Documentação interna: Bugs conhecidos de transaction safety documentados para correção ao tocar o código.

3. Classificação (CVSS)

Severidade	CVSS	SLA de Correção	Responsável
Crítica	9.0 – 10.0	24 horas	Responsável técnico
Alta	7.0 – 8.9	72 horas	Responsável técnico
Média	4.0 – 6.9	15 dias	Equipe de desenvolvimento
Baixa	0.1 – 3.9	30 dias	Equipe de desenvolvimento

4. Tratamento

1. Triagem: Avaliar se a vulnerabilidade afeta o ambiente de produção.
2. Classificação: Atribuir severidade conforme tabela CVSS.
3. Correção: Aplicar patch, atualizar dependência ou corrigir código.
4. Controle compensatório: Se a correção não for possível imediatamente, implementar medida mitigatória (WAF rule, rate limit, desabilitar feature).
5. Validação: Executar testes automatizados para confirmar correção e ausência de regressão.
6. Deploy: Aplicar correção em produção seguindo o fluxo de deploy padrão.

5. Registro

Toda vulnerabilidade identificada é registrada com:

• Data de identificação
• Descrição e componente afetado
• Classificação de severidade (CVSS)
• Ações de tratamento adotadas
• Data de correção ou implementação de controle compensatório
• Responsável pelo tratamento

6. Comunicação

• Vulnerabilidades Críticas e Altas: comunicadas à direção imediatamente.
• Se dados de clientes estiverem em risco: seguir Plano de Gestão de Incidentes.
• Parceiros afetados (ex.: Asaas) são notificados quando a vulnerabilidade envolve integrações compartilhadas.

7. Controles Compensatórios

Quando a correção definitiva não é possível (ex.: dependência sem patch disponível), o controle compensatório deve:

• Mitigar o risco da exploração da vulnerabilidade.
• Ser documentado com justificativa e prazo de revisão.
• Ser revisado mensalmente até que a correção definitiva seja aplicada.

Versão: 1.0 | Aprovação: Agosto/2026 | Próxima revisão: Agosto/2027