Política de divulgação de vulnerabilidades

Visão geral

Esta página define a política de divulgação coordenada de vulnerabilidades do NextPDF. Ela explica como entrar em contato com os mantenedores em privado, qual cronograma de resposta você pode esperar e como funcionam os embargos.

Limite. Uma política de divulgação é um compromisso de processo, não uma garantia de prazo nem de resultado. As metas abaixo são compromissos de boa-fé dos mantenedores com você, como pessoa que relata uma vulnerabilidade; elas descrevem o processo que o projeto segue, não uma promessa contratual de que qualquer relato específico será confirmado, triado, corrigido ou divulgado em uma data específica. O momento da divulgação coordenada é negociado, não garantido unilateralmente.

Instalação

Não se aplica. Você não precisa instalar nada para relatar uma vulnerabilidade. A superfície de contato legível por máquina é publicada em /.well-known/security.txt (Request for Comments (RFC) 9116). O SECURITY.md do repositório é a política legível por humanos que serve como referência.

Visão conceitual

A política implementa a divulgação coordenada de vulnerabilidades conforme definida pela ISO/IEC 29147 e o processo de tratamento da ISO/IEC 30111 (iso_iec_30111#x9.x43.p2): recebimento privado, triagem e avaliação de severidade, correção sob embargo e publicação pública conjunta. Se uma vulnerabilidade afetar vários fornecedores, as partes afetadas coordenam a data do comunicado em vez de defini-la unilateralmente (iso_iec_29147#x3.x110.p13).

O processo também está alinhado com as obrigações de tratamento de vulnerabilidades do fabricante previstas no Cyber Resilience Act (CRA) da União Europeia (EU) (eu_cra#x1.p191) e com a prática “responder a vulnerabilidades” do Secure Software Development Framework (SSDF) do National Institute of Standards and Technology (NIST) (nist_sp_800_218#x15). Ambos tratam isso como deveres de processo repetíveis, não como garantia de que qualquer resultado individual será assegurado.

Superfície de API

Não se aplica. A divulgação é um processo, não uma interface de programação de aplicações (API). A superfície de descoberta legível por máquina é o arquivo RFC 9116 security.txt; as ferramentas leem os campos Contact: e Expires: dele. Esta página não duplica o conteúdo desse arquivo, exceto pelos canais abaixo.

Exemplo de código — Início rápido

Não se aplica. Não há código a executar quando você relata uma vulnerabilidade. Use um canal privado:

GitHub Security Advisories (preferencial — criptografia em repouso, log de auditoria): abra um comunicado em rascunho na aba GitHub Security do projeto.
E-mail: [email protected] com [SECURITY] no assunto. Se você precisar de criptografia de ponta a ponta e ainda não houver uma chave OpenPGP publicada em security.txt, use o canal GitHub Security Advisory.

Você não deve relatar vulnerabilidades por meio de issues públicas, listas de e-mail públicas, redes sociais ou chat. A divulgação pública antes de uma correção coloca em risco os usuários de versões sem patch.

Exemplo de código — Produção

Não se aplica.

Casos extremos e pegadinhas

As metas são compromissos, não acordos de nível de serviço (SLAs). O cronograma abaixo indica o que o projeto pretende fazer. Um problema complexo, com vários componentes ou que exija coordenação upstream, pode levar mais tempo; o projeto mantém quem relatou informado.
A duração do embargo é negociável, com um teto. O embargo padrão vai da triagem até a publicação da correção. Se você precisar de mais tempo, solicite explicitamente ao abrir o comunicado. Depois desse limite máximo, o projeto publicará o comunicado independentemente de haver ou não uma correção disponível, em conformidade com as normas de divulgação coordenada do setor. Isso protege os usuários contra um comunicado retido por tempo indefinido.
A severidade determina o cronograma. Um problema crítico, ativamente explorado, é tratado em um cronograma reduzido; uma sugestão de proteção de severidade baixa, não. A severidade é avaliada durante a triagem e pode ser revisada.
A emissão de Common Vulnerabilities and Exposures (CVE) faz parte da triagem. O mantenedor solicita um CVE por meio da inscrição do projeto como CVE Numbering Authority (CNA) no GitHub Security Advisory como parte da etapa de triagem; quem relatou não precisa solicitar outro separadamente.

Desempenho

Não se aplica.

Notas de segurança

As metas do cronograma de resposta são compromissos com quem relata e formam a linha de base do tratamento de vulnerabilidades do projeto. Elas são metas, não garantias:

Etapa	Meta
Confirmar o recebimento	em 1 a 2 dias úteis
Triagem inicial + avaliação de severidade	em ~5 dias úteis / 7 dias corridos
Desenvolvimento do patch + revisão privada	tipicamente 14 dias úteis; 30 a 90 dias para CVEs confirmados complexos, dependendo da severidade
Atribuição de CVE (se aceito)	simultânea ao patch, pelo canal GitHub CNA
Divulgação pública coordenada	na publicação do patch, em uma data definida em conjunto com quem relatou
Embargo (da triagem até a publicação)	padrão de ~90 dias, reduzido sob exploração ativa, prorrogável mediante solicitação explícita até um máximo fixo

Os revisores podem verificar estas regras de processo:

Privado em primeiro lugar. Nenhum canal público é aceito para recebimento. Os únicos canais aceitos são o GitHub Security Advisory e o e-mail de segurança.
Coordenada, não unilateral. O momento da divulgação é negociado com quem relata e com quaisquer fornecedores também afetados (iso_iec_29147#x3.x110.p13).
Embargo limitado. O embargo tem um padrão e um teto rígido; o projeto não retém um comunicado por tempo indefinido.
Crédito mediante solicitação. Os pesquisadores recebem crédito após o fim do embargo, a menos que solicitem anonimato.

Estas declarações descrevem o processo que o projeto se compromete a seguir. Elas não garantem que um determinado relato resultará em uma correção, em um CVE ou em uma divulgação em uma data específica.

Conformidade

Esta página não é um perfil de conformidade. A política está alinhada com a ISO/IEC 29147, a ISO/IEC 30111 e os deveres de processo do CRA e do SSDF citados acima; “alinhada com” é uma escolha deliberada de palavras. O projeto não afirma ter certificação em nenhum desses esquemas. Eles definem um processo sólido; esta página documenta o compromisso do projeto de operar esse processo.

Veja também

Central de confiança
Modelo de ameaças do mecanismo
Modelo de segurança de assinatura e criptografia
Arquivo SECURITY.md do repositório e /.well-known/security.txt (RFC 9116)