Divulgação coordenada de vulnerabilidades: como gerir um programa de divulgação

O que é a divulgação coordenada de vulnerabilidades?

A divulgação coordenada de vulnerabilidades (CVD) é a prática de tratar uma vulnerabilidade recém-encontrada em privado entre quem a encontrou e o fornecedor até estar disponível uma correção ou mitigação, publicando-a depois. O CERT Guide to Coordinated Vulnerability Disclosure descreve-a como recolher informação de quem encontra vulnerabilidades, coordenar a partilha dessa informação entre as partes interessadas relevantes e divulgar a vulnerabilidade e as suas mitigações, incluindo ao público.

Para um fornecedor de produtos, a CVD tem duas metades. A metade externa, receber relatórios e publicar avisos de segurança, é o que esta página cobre. A metade interna, verificar, corrigir e lançar, é o ciclo de vida da gestão de vulnerabilidades. Ambas são normalmente conduzidas por um PSIRT.

CVD vs divulgação total vs bug bounty

	Divulgação coordenada	Divulgação total	Bug bounty
O que é	Relatório privado, correção e depois publicação num momento acordado	Quem encontra publica os pormenores de imediato, informando ou não o fornecedor	Um programa que paga por conclusões válidas
Quem controla o calendário	O fornecedor e quem encontrou, em conjunto, por vezes com um coordenador	Quem encontrou	Os termos do programa, normalmente seguindo a CVD
Risco para os utilizadores	O mais baixo: os pormenores tornam-se públicos quando existe uma correção ou quando passa um prazo	O mais alto: os atacantes sabem ao mesmo tempo que os defensores	Como na CVD
Custo	Tempo da equipa para triagem e resposta	Trabalho de emergência não planeado	Tempo da equipa mais recompensas e, muitas vezes, taxas da plataforma

Um bug bounty não é uma alternativa a um programa de divulgação de vulnerabilidades (VDP). É um incentivo acrescentado a um programa desse tipo. Todos os fornecedores precisam de uma forma de qualquer pessoa reportar uma vulnerabilidade; um bounty apenas decide se alguns relatórios são pagos.

O que deve conter uma política de divulgação de vulnerabilidades

Uma política de divulgação de vulnerabilidades é o documento público que define os termos do seu programa. A ISO/IEC 29147, a norma internacional para a divulgação de vulnerabilidades, torna obrigatório um elemento, um mecanismo de contacto preferencial, e recomenda vários outros. Uma política completa cobre:

• Como reportar. Um endereço dedicado ou um formulário web, e uma forma de enviar pormenores sensíveis em segurança, como uma chave de cifra publicada.
• O que incluir. Produto e versão afetados, passos para reproduzir, impacto e como contactar o autor do relatório.
• Âmbito. Que produtos, versões e serviços estão abrangidos e que métodos de teste estão excluídos, como a negação de serviço ou o acesso a dados de outros utilizadores.
• Safe harbor. Um compromisso de não instaurar ações judiciais contra investigação de boa-fé que siga a política.
• O que os autores de relatórios podem esperar. Quando confirmará a receção do relatório, como os manterá informados e o seu prazo-alvo para uma correção.
• Calendário de divulgação. Quando os pormenores se tornam públicos e o que acontece se uma correção demorar mais.
• Publicação. Onde aparecem os avisos de segurança e se atribui identificadores CVE.
• Reconhecimento. Se e como dá crédito aos autores de relatórios, e se paga recompensas.

Mantenha a política curta e específica. Os autores de relatórios leem-na para decidir se reportar-lhe é seguro e compensa o esforço.

security.txt: torne o seu contacto fácil de encontrar

Uma política só funciona se os investigadores a conseguirem encontrar. O RFC 9116, publicado em abril de 2022, define security.txt, um pequeno ficheiro de texto servido em /.well-known/security.txt através de HTTPS.

Contact: mailto:[email protected]
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• Obrigatórios: Contact e Expires. O RFC 9116 recomenda uma data de expiração a menos de um ano, para que o ficheiro não fique desatualizado.
• Opcionais: Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical e Hiring.
• Assinatura: o RFC recomenda uma assinatura OpenPGP em texto claro, com Canonical definido.

Coloque um lembrete no calendário antes da data de Expires. Um ficheiro expirado diz aos investigadores que ninguém está a ler.

Embargos e calendários de divulgação

O embargo é o período entre o relatório e a publicação. A norma mais citada é a política da Google Project Zero: os fornecedores têm 90 dias para disponibilizar um patch, e os pormenores são publicados 30 dias depois da distribuição do patch. Um fornecedor que precise de um pouco mais de tempo pode pedir um período de tolerância, até 104 dias no total. Quando uma vulnerabilidade já está a ser explorada no terreno, o prazo desce para 7 dias.

A sua própria política pode definir termos diferentes, e muitos autores de relatórios aceitam-nos. O que importa é que o calendário esteja escrito, que mantenha os autores de relatórios informados e que peça uma prorrogação antes do prazo, e não depois. Um aviso de segurança publicado a tempo com uma mitigação é melhor do que o silêncio.

Identificadores CVE e CNA

A maioria dos avisos de segurança tem um identificador CVE, para que os clientes e as ferramentas os possam cruzar. Os identificadores são atribuídos por CVE Numbering Authorities (CNA), organizações autorizadas a atribuir identificadores num âmbito acordado. Muitos fornecedores de software são CNA para os seus próprios produtos, o que lhes permite atribuir o identificador e publicar o registo segundo o seu próprio calendário. Se não for o seu caso, uma CNA cujo âmbito cubra o seu produto, ou uma CNA of Last Resort, atribui-o.

Coordenação entre várias partes

Algumas vulnerabilidades afetam muitos fornecedores ao mesmo tempo: uma falha numa biblioteca amplamente usada, num protocolo ou num chip. Nesse caso, um coordenador ajuda a chegar a todos os fornecedores afetados e a acordar uma única data de publicação.

• O CERT/CC, no Software Engineering Institute da Carnegie Mellon University, coordena casos com vários fornecedores e publica o guia CVD do CERT.
• CSIRT nacionais na UE. Ao abrigo da NIS2, cada Estado-Membro designa um CSIRT como seu coordenador de CVD. Este atua como intermediário de confiança entre autores de relatórios e fornecedores, negoceia calendários de divulgação, trata de vulnerabilidades que afetam várias entidades e aceita relatórios anónimos.
• A European Vulnerability Database (EUVD) da ENISA, criada ao abrigo da NIS2, está operacional desde maio de 2025 e publica informação sobre vulnerabilidades publicamente conhecidas, incluindo as coordenadas na UE.

A ISO/IEC 29147 cobre também o caso em que é ambos: um fornecedor cujo produto contém um componente vulnerável de outro fornecedor, que tem de reportar a montante e avisar os seus próprios clientes.

Depois de chegar um relatório

1. Confirme a receção no prazo que a sua política promete e dê ao autor do relatório um identificador de acompanhamento.
2. Verifique o relatório e avalie a sua gravidade.
3. Encontre o que é afetado: todos os produtos, versões e branches suportadas que contêm o código ou o componente vulnerável.
4. Corrija e lance para cada branch afetada, mantendo o autor do relatório informado.
5. Publique o aviso de segurança, com um identificador CVE, as versões afetadas, a remediação e o crédito. Os avisos legíveis por máquina usam CSAF, e o VEX diz aos clientes que produtos não são afetados.

O processo completo, com papéis, prazos e métricas, está no ciclo de vida da gestão de vulnerabilidades.

A regulamentação está a tornar obrigatórias as políticas de CVD

O Cyber Resilience Act da UE exige que os fabricantes criem e apliquem uma política de divulgação coordenada de vulnerabilidades e forneçam um endereço de contacto para reportar vulnerabilidades, incluindo as de componentes de terceiros (Anexo I, parte II). Estas obrigações aplicam-se a partir de 11 de dezembro de 2027; consulte o que o CRA exige. O artigo 21.º, n.º 2, alínea e), da NIS2 inclui o tratamento e a divulgação de vulnerabilidades entre as medidas de segurança que as entidades essenciais e importantes têm de tomar. Nos EUA, a Executive Order 14028 determinou orientações para a cadeia de abastecimento de software que incluem a participação num programa de divulgação de vulnerabilidades.

Um relatório só é tão útil quanto o seu registo do que distribuiu

Cada relatório levanta a mesma primeira pergunta: que versões nossas contêm isto? O CRACI executa os seus builds de GitHub Actions em runners próprios e regista os pacotes que cada job realmente obteve, incluindo dependências transitivas, pacotes restaurados de caches de CI e dependências que nenhum lockfile lista. O histórico de builds mostra que builds anteriores continham uma dependência vulnerável, para que saiba durante que período esteve afetado, e a vista de inventário mostra que versões de software estão implementadas em que produtos.

O CRACI agrega SBOM entre builds e repositórios e reavalia continuamente as SBOM monitorizadas, pelo que, assim que uma vulnerabilidade num componente open source é publicada, vê todos os locais onde aparece. As equipas de segurança fazem a triagem das conclusões e enviam-nas para as equipas responsáveis pela correção, o CRACI suporta VEX, e os controlos de política podem bloquear builds que contenham uma CVE específica depois de esta ser corrigida. Consulte acompanhamento de vulnerabilidades.

Divulgação coordenada de vulnerabilidades: perguntas frequentes

O que é a divulgação coordenada de vulnerabilidades?

A divulgação coordenada de vulnerabilidades (CVD) é o processo em que a pessoa que encontra uma vulnerabilidade a reporta em privado ao fornecedor, o fornecedor a corrige e os pormenores são publicados quando os utilizadores se podem proteger, normalmente numa data acordada entre as partes. Coordenadores como o CERT/CC ou um CSIRT nacional intervêm quando um fornecedor não é contactável ou quando vários fornecedores são afetados.

Qual é a diferença entre um VDP e um bug bounty?

Um programa de divulgação de vulnerabilidades (VDP) diz a qualquer pessoa como reportar uma vulnerabilidade e o que esperar, sem pagar por conclusões. Um bug bounty paga aos investigadores por conclusões válidas, normalmente num âmbito definido e muitas vezes através de uma plataforma de bounties. A maioria das organizações começa por um VDP; um bounty é um acrescento opcional, não um substituto.

O que deve incluir uma política de divulgação de vulnerabilidades?

No mínimo, como reportar: um endereço de contacto ou um formulário. A ISO/IEC 29147 recomenda também indicar o que um relatório deve conter, como comunicar em segurança, o que os autores de relatórios podem esperar e quando, o que está no âmbito, como publica os avisos de segurança e como dá crédito aos autores de relatórios. A maioria das políticas acrescenta uma declaração de safe harbor e um calendário de divulgação.

O que é o security.txt?

security.txt é um ficheiro de texto simples definido no RFC 9116 e servido em /.well-known/security.txt. Diz aos investigadores onde reportar vulnerabilidades. Tem de conter os campos Contact e Expires e pode incluir ligações para a sua política, chave de cifra e página de agradecimentos.

Qual é a duração típica de um prazo de divulgação?

90 dias é a norma mais citada. A Google Project Zero dá aos fornecedores 90 dias para disponibilizar um patch e publica os pormenores 30 dias depois do patch, com um prazo de 7 dias quando uma vulnerabilidade já está a ser explorada no terreno. A sua própria política pode definir termos diferentes, e os coordenadores negoceiam caso a caso.

Uma política de divulgação coordenada de vulnerabilidades é obrigatória?

Cada vez mais, sim. O Cyber Resilience Act da UE exige que os fabricantes de produtos com elementos digitais criem e apliquem uma política de CVD e forneçam um endereço de contacto para relatórios, e a NIS2 inclui o tratamento e a divulgação de vulnerabilidades entre as medidas de segurança exigidas. Noutros contextos, os clientes e as regras de aquisição pedem muitas vezes uma.

Preciso de ser uma CNA para obter um identificador CVE?

Não. Uma CVE Numbering Authority (CNA) atribui identificadores CVE no seu próprio âmbito, e muitos fornecedores tornam-se CNA para os seus próprios produtos. Se não for o seu caso, uma CNA cujo âmbito cubra o seu produto, ou uma CNA of Last Resort, pode atribuir o identificador.