Responsible disclosure: políticas para pesquisadores de segurança

1. O que é Responsible Disclosure e por que sua equipe precisa de uma política

Responsible disclosure (divulgação responsável) é um processo estruturado onde pesquisadores de segurança reportam vulnerabilidades descobertas a uma organização, permitindo que ela corrija o problema antes de qualquer divulgação pública. Diferencia-se de:

  • Disclosure público imediato: o pesquisador publica a vulnerabilidade sem aviso prévio, expondo usuários a riscos
  • Disclosure privado: o pesquisador reporta apenas internamente, sem garantias de correção ou transparência

Para times de desenvolvimento, uma política de responsible disclosure oferece:

  • Correção de bugs antes da exploração em massa
  • Redução de incidentes de segurança emergenciais
  • Construção de confiança com a comunidade de segurança
  • Proteção legal para ambos os lados

Sem uma política clara, pesquisadores podem se sentir ignorados e optar por divulgação pública completa, expondo sua aplicação e usuários.

Exemplo de cenário sem política:
- Pesquisador encontra XSS em /api/users
- Envia e-mail para contato@empresa.com (sem resposta por 90 dias)
- Publica vulnerabilidade no Twitter com PoC funcional
- Empresa descobre pelo monitoramento de redes sociais
- Correção emergencial às pressas, expondo dados de usuários

Cenário com política:
- Pesquisador segue processo documentado
- Reporte é triado em 24h
- Correção ocorre em 7 dias (severidade crítica)
- CVE é publicado de forma coordenada
- Pesquisador entra no Hall da Fama

2. Elementos essenciais de uma política de Responsible Disclosure

Escopo claro

Defina exatamente quais sistemas, endpoints e versões estão cobertos:

ESCOPO COBERTO:
- api.exemplo.com (v2+)
- app.exemplo.com (produção)
- mobile.exemplo.com (Android e iOS)

FORA DE ESCOPO:
- Sistemas de terceiros (AWS, Cloudflare)
- Versões antigas (v1.x, legado)
- Subdomínios de desenvolvimento (dev.*)
- Testes de engenharia social
- Ataques de negação de serviço (DoS/DDoS)
- Acesso físico a equipamentos

Canais oficiais de reporte

Disponibilize canais seguros e documentados:

Canais oficiais:
- security@exemplo.com (PGP key disponível em exemplo.com/pgp)
- Formulário seguro em exemplo.com/report
- Plataforma HackerOne: https://hackerone.com/exemplo

Formato esperado do reporte:
- Título: [Tipo] - Sistema afetado
- Descrição: Passos para reproduzir
- Impacto: O que um atacante pode fazer
- Evidência: Screenshots, vídeos ou PoC
- Ambiente: Versão do sistema, navegador, SO

Regras claras para pesquisadores

PERMITIDO:
- Testes em contas próprias
- Uso de ferramentas automatizadas sem impacto
- Análise estática de código público (se aplicável)

PROIBIDO:
- Acessar, modificar ou excluir dados de terceiros
- Testes destrutivos (deletar dados, derrubar servidores)
- Engenharia social contra funcionários
- Extorsão ou ameaças
- Divulgação pública antes da autorização

3. Definindo prazos e expectativas de resposta

Estabeleça SLAs claros por severidade:

CLASSIFICAÇÃO DE SEVERIDADE:

CRÍTICA (RCE, SQL Injection, Acesso não autorizado):
- Confirmação de recebimento: 24h úteis
- Primeira análise: 48h úteis
- Correção: até 7 dias corridos

ALTA (XSS persistente, IDOR, LFI):
- Confirmação de recebimento: 48h úteis
- Primeira análise: 72h úteis
- Correção: até 14 dias corridos

MÉDIA (XSS refletido, CSRF, Clickjacking):
- Confirmação de recebimento: 72h úteis
- Primeira análise: 5 dias úteis
- Correção: até 30 dias corridos

BAIXA (Missing headers, informações não sensíveis):
- Confirmação de recebimento: 5 dias úteis
- Primeira análise: 10 dias úteis
- Correção: até 90 dias corridos

Política de extensão

Se a correção exigir mais tempo:
- Comunique o pesquisador com justificativa
- Proponha novo prazo realista
- Mantenha atualizações semanais
- Ofereça divulgação parcial se necessário

4. Processo interno de triagem e validação

Fluxo de recebimento

1. RECEBIMENTO
   - Equipe de segurança recebe reporte
   - Confirma recebimento com número de ticket
   - Classifica severidade inicial

2. TRIAGEM (24-48h)
   - Verifica se está no escopo
   - Descarta duplicatas (comunica pesquisador)
   - Valida se é falso positivo
   - Atribui severidade final

3. REPRODUÇÃO
   - Desenvolvedor responsável tenta reproduzir
   - Documenta passos e impacto real
   - Cria issue privada com tag [SECURITY]

4. CORREÇÃO
   - Desenvolvedor implementa patch
   - Revisão de código focada em segurança
   - Testes unitários e de regressão

5. VALIDAÇÃO
   - Equipe de segurança valida correção
   - Pesquisador é notificado para re-testar
   - Se aprovado, prepara divulgação

6. DIVULGAÇÃO
   - Publica CVE (se aplicável)
   - Atualiza changelog
   - Comunica pesquisador sobre lançamento

Critérios para aceitar ou rejeitar

ACEITAR:
- Vulnerabilidade reproduzível
- Impacto real na segurança
- Dentro do escopo definido
- Reporte bem documentado

REJEITAR (com justificativa):
- Duplicata de reporte anterior
- Falso positivo (explicar por quê)
- Fora de escopo (redirecionar se possível)
- Sem impacto real (baixo risco aceito)
- Teste destrutivo ou violação de regras

5. Recompensas e reconhecimento para pesquisadores

Programa de bug bounty

TABELA DE RECOMPENSAS (valores ilustrativos):

CRÍTICA (RCE, SQLi com exfiltração):
- Financeiro: R$ 5.000 - R$ 15.000
- Swag: Kit completo + convite para evento

ALTA (XSS persistente, IDOR crítico):
- Financeiro: R$ 1.000 - R$ 5.000
- Swag: Camiseta + adesivos + caneca

MÉDIA (XSS refletido, CSRF):
- Financeiro: R$ 300 - R$ 1.000
- Swag: Adesivos + carta de agradecimento

BAIXA (Missing headers, info menor):
- Financeiro: Não se aplica
- Swag: Menção no Hall da Fama

Pesquisadores que recusam recompensa

Alternativas:
- Carta de agradecimento personalizada do CTO
- Menção destacada no Hall da Fama
- Convite para programa beta de segurança
- Doação para instituição indicada pelo pesquisador
- Certificado de contribuição para segurança

6. Comunicação pós-correção e timeline de divulgação

Notificação ao pesquisador

Modelo de comunicação:

Assunto: [SECURITY] Correção implantada - [ID do Reporte]

Olá [Pesquisador],

A vulnerabilidade reportada em [data] foi corrigida na versão [vX.Y.Z] 
e implantada em produção em [data].

Detalhes da correção:
- Commit: [link para commit privado]
- CVE atribuído: [CVE-YYYY-NNNN] (se aplicável)
- Impacto: [descrição resumida]

Divulgação coordenada:
- Data sugerida para publicação conjunta: [data + 30 dias]
- Advisory draft: [link para draft]

Agradecemos sua contribuição. Você será creditado como:
[opção de como deseja ser mencionado]

Atenciosamente,
Equipe de Segurança

Timeline de divulgação coordenada

Dia 0: Correção implantada em produção
Dia 0-7: Período de embargo (usuários atualizam)
Dia 7: Publicação do advisory e CVE
Dia 7: Pesquisador pode publicar seu write-up
Dia 14: Divulgação pública completa (blog post)

7. Integração com a cultura de segurança do time

Conexão com Security Champions

Como usar reportes reais:

1. CTF interno baseado em vulnerabilidades reais
   - Anonimizar reporte
   - Criar desafio para desenvolvedores
   - Gamificar aprendizado

2. Workshop mensal de segurança
   - Analisar reporte recebido no mês
   - Discutir como evitar padrão similar
   - Revisar práticas de código seguro

3. Métricas de melhoria contínua
   - Número de reportes por trimestre
   - Tempo médio de correção
   - Taxa de reincidência de tipos de vulnerabilidade
   - Satisfação dos pesquisadores (NPS)

Revisão periódica da política

REVISÃO SEMESTRAL:

1. Escopo:
   - Novos sistemas foram adicionados?
   - Sistemas legados foram removidos?
   - APIs públicas novas?

2. Prazos:
   - SLAs estão sendo cumpridos?
   - Precisa ajustar por tipo de vulnerabilidade?
   - Time tem capacidade para prazos menores?

3. Recompensas:
   - Valores competitivos com mercado?
   - Pesquisadores estão satisfeitos?
   - Orçamento disponível para aumentar?

4. Processo:
   - Gargalos na triagem?
   - Ferramentas adequadas?
   - Comunicação eficiente?

Referências