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.
| 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 | |
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.
Há dois canais privados equivalentes. Escolha o que for mais confortável:
Cada repositório da organização CerneBR tem o Private Vulnerability Reporting habilitado:
- Acesse a aba Security do repositório afetado.
- Clique em Report a vulnerability.
- 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.
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).
Um relatório de qualidade acelera o triage e o patch. Quanto mais informação, melhor:
- Resumo executivo — descrição em 1-2 linhas.
- Componente afetado — repositório, arquivo, função, endpoint, versão.
- Impacto — qual o pior cenário (RCE, leak de dados, bypass de autenticação, DoS, etc.).
- Prova de conceito — passos reproduzíveis, comandos, payloads, screenshots. Quando possível, ambiente isolado (Docker reproducer).
- Vetor de ataque — pré-condições (autenticação? rede? configuração específica?).
- Sugestão de mitigação, se houver.
- Sua identidade para crédito público após o patch, se desejar (opcional).
| 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.
- Recebimento e confirmação do relatório.
- Validação reprodutível em ambiente isolado.
- Atribuição de CVE quando aplicável (via GitHub Security Advisories).
- Desenvolvimento e revisão privada do patch.
- Coordenação de janela de divulgação com o repórter.
- Publicação de Security Advisory com detalhes, mitigação e crédito.
- Release pública contendo a correção.
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.
- 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.
- 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.
Comprometemo-nos a não tomar ações legais contra pesquisadores que:
- Reportem vulnerabilidades de boa fé seguindo este processo.
- Não acessem, modifiquem ou destruam dados além do mínimo necessário para demonstrar o problema.
- Não exfiltrem informações de usuários da CerneBR ou de terceiros.
- Concedam tempo razoável para correção antes de divulgação pública.
- Cumpram todas as leis aplicáveis.
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.