Skip to content

Security: CerneBR/.github

SECURITY.md

Política de Segurança — CerneBR

A segurança dos consumidores da infraestrutura CerneBR é prioridade máxima. Este documento descreve como reportar vulnerabilidades de forma privada, qual o escopo da nossa política e o que esperar do processo de divulgação responsável.

⚠️ Não abra Issues públicas para reportar vulnerabilidades. Issues públicas expõem o vetor antes que o patch esteja disponível e colocam toda a base de usuários sob risco desnecessário.


Versões suportadas

Repositório Versão Suporte de segurança
gateway-nacional main (em desenvolvimento ativo) ✅ Patches imediatos
gateway-nacional Última release estável ✅ Patches imediatos
gateway-nacional Releases anteriores ⚠️ Avaliação caso a caso
gateway-nacional-web main (em desenvolvimento ativo) ✅ Patches imediatos
gateway-nacional-web Última release estável ✅ Patches imediatos

Versões fora desta lista podem não receber correções. Recomenda-se manter sua instância self-hosted sempre atualizada com a release estável mais recente.


Como reportar uma vulnerabilidade

dois canais privados equivalentes. Escolha o que for mais confortável:

Canal 1 — GitHub Private Vulnerability Reporting (preferencial)

Cada repositório da organização CerneBR tem o Private Vulnerability Reporting habilitado:

  1. Acesse a aba Security do repositório afetado.
  2. Clique em Report a vulnerability.
  3. Preencha o formulário com o máximo de detalhes possível.

A vantagem desse canal é o rastreamento nativo do GitHub e o histórico privado preservado mesmo após a divulgação pública.

Canal 2 — E-mail

Envie um relatório para seguranca@cernebr.dev.br.

Para garantir confidencialidade ponta-a-ponta, recomendamos cifrar o conteúdo com a chave PGP pública listada no portal: https://cernebr.dev.br/security/pgp (fingerprint publicada também no README do portal).


O que incluir no relatório

Um relatório de qualidade acelera o triage e o patch. Quanto mais informação, melhor:

  1. Resumo executivo — descrição em 1-2 linhas.
  2. Componente afetado — repositório, arquivo, função, endpoint, versão.
  3. Impacto — qual o pior cenário (RCE, leak de dados, bypass de autenticação, DoS, etc.).
  4. Prova de conceito — passos reproduzíveis, comandos, payloads, screenshots. Quando possível, ambiente isolado (Docker reproducer).
  5. Vetor de ataque — pré-condições (autenticação? rede? configuração específica?).
  6. Sugestão de mitigação, se houver.
  7. Sua identidade para crédito público após o patch, se desejar (opcional).

Nosso compromisso de resposta (SLA)

Etapa Prazo alvo
Confirmação de recebimento 48 horas úteis
Triagem inicial e classificação de severidade 5 dias úteis
Correção de severidade Crítica 7 dias corridos
Correção de severidade Alta 30 dias corridos
Correção de severidade Média/Baixa 90 dias corridos
Divulgação coordenada Após patch publicado em release estável

A severidade é classificada conforme CVSS v3.1. Mantenedores e o repórter podem negociar o prazo em casos de complexidade técnica não usual.


Processo de divulgação

  1. Recebimento e confirmação do relatório.
  2. Validação reprodutível em ambiente isolado.
  3. Atribuição de CVE quando aplicável (via GitHub Security Advisories).
  4. Desenvolvimento e revisão privada do patch.
  5. Coordenação de janela de divulgação com o repórter.
  6. Publicação de Security Advisory com detalhes, mitigação e crédito.
  7. Release pública contendo a correção.

Crédito público (Hall of Fame)

Mantemos uma página de Hall of Fame para pesquisadores de segurança que reportaram vulnerabilidades válidas: https://cernebr.dev.br/security/hall-of-fame. A inclusão é opcional e ocorre apenas com consentimento explícito.


Escopo

Em escopo

  • Vulnerabilidades nos códigos sob github.com/CerneBR/*.
  • Vulnerabilidades em dependências diretas críticas quando a CerneBR puder mitigar via configuração ou pinning de versão.
  • Falhas de configuração padrão dos artefatos publicados (Docker images, jars, builds de produção).
  • Vetores que afetem a confidencialidade, integridade ou disponibilidade de instâncias self-hosted padrão.

Fora de escopo

  • Vulnerabilidades em provedores externos (ViaCEP, ReceitaWS, BrasilAPI, IBGE, FIPE oficial, etc.) — reporte diretamente ao provedor responsável.
  • Ataques que exigem acesso físico, engenharia social ou comprometimento prévio da máquina hospedeira.
  • DoS via volume de requisições puro — o gateway oferece rate limiting via Bucket4j; deploy sem essa proteção é responsabilidade do operador.
  • Vulnerabilidades em versões não suportadas (vide tabela acima).
  • Issues de configuração específicas de um deploy customizado que não refletem o estado padrão dos repositórios.

Safe Harbor

Comprometemo-nos a não tomar ações legais contra pesquisadores que:

  1. Reportem vulnerabilidades de boa fé seguindo este processo.
  2. Não acessem, modifiquem ou destruam dados além do mínimo necessário para demonstrar o problema.
  3. Não exfiltrem informações de usuários da CerneBR ou de terceiros.
  4. Concedam tempo razoável para correção antes de divulgação pública.
  5. Cumpram todas as leis aplicáveis.

Dúvidas

Para perguntas não relacionadas a uma vulnerabilidade específica (políticas, processos, integrações de segurança corporativa), use seguranca@cernebr.dev.br. Para suporte técnico geral, consulte SUPPORT.md.

Obrigado por ajudar a manter a infraestrutura de dados públicos brasileiros confiável e segura.

There aren't any published security advisories