Saltar para o conteúdo
folhas.io
secure by design para produtos ligados· Artigos

Artigos

Divulgação coordenada de vulnerabilidades: o canal que o CRA obriga a manter aberto

As obrigações de reporte às autoridades já estão em aplicação, mas são metade do circuito. O Anexo I, Parte II, exige a outra metade: um canal público para receber relatórios de vulnerabilidades, com política, ponto de contacto e processo por trás. Custa pouco a montar, e há norma para quase tudo.

Publicado
Atualizado

Nota de atualização (23 out 2026). Acrescentámos a secção «Do lado de quem integra», sobre a comunicação de vulnerabilidades a quem mantém os componentes (artigo 13.º, n.º 6), com o exemplo das correções ao PHP de outubro de 2026.

Desde 11 de setembro de 2026, um fabricante que saiba de uma vulnerabilidade ativamente explorada no seu produto tem prazos contados às horas para avisar as autoridades — o artigo sobre o reporte de 24h e 72h descreve esse circuito ao detalhe. Esse circuito é o de saída. O regulamento desenha também o de entrada: como é que a informação sobre uma vulnerabilidade chega ao fabricante, vinda de fora, pelo caminho mais curto possível.

O que o Anexo I, Parte II, pede

Os requisitos de tratamento de vulnerabilidades do CRA tornam-se exigíveis com a aplicação plena, a 11 de dezembro de 2027, para os produtos com elementos digitais colocados no mercado a partir daí. A lista é curta e concreta:

  • Inventariar os componentes e as vulnerabilidades do produto, com uma SBOM em formato legível por máquina (o artigo 01 trata de como a gerar sem mentir);
  • Tratar e corrigir vulnerabilidades sem demora, com atualizações de segurança distribuídas de forma segura e sem custo para o utilizador;
  • Testar a segurança do produto com regularidade;
  • Divulgar publicamente as vulnerabilidades corrigidas, com informação que sirva a quem opera o produto;
  • Ter uma política de divulgação coordenada de vulnerabilidades, publicada e aplicada na prática;
  • Facilitar a comunicação de vulnerabilidades vindas de fora, com um ponto de contacto público.

Quem espera por dezembro de 2027 para abrir o canal vai abri-lo com o resto da conformidade em cima da mesa, na pior altura para escrever política com calma.

O mínimo que já funciona

A porta de entrada tem norma própria e cabe num ficheiro de texto. O security.txt (RFC 9116) vive em /.well-known/, aponta um contacto, uma chave PGP para relatórios cifrados e uma data de validade que obriga a revisitá-lo. O contacto deve ser um endereço dedicado, que sobreviva a saídas de pessoas e a caixas de correio pessoais.

A política publicada não precisa de ser longa. Três coisas chegam: o âmbito (que produtos e versões), o que o fabricante promete (confirmação de receção num prazo definido, referência pública quando a correção sair), e o que pede a quem reporta (tempo razoável antes de divulgação pública, não aceder a dados de terceiros durante a investigação). Divulgação coordenada não é um programa de recompensas: a maior parte dos relatórios sérios chega de investigadores e de clientes que só querem resposta competente.

Para quem quer ir além do mínimo, a interface com o exterior está normalizada na ISO/IEC 29147 e o processo interno na ISO/IEC 30111. As duas foram escritas para se encaixarem, e a leitura é mais curta do que parece.

Fluxo da divulgação coordenada: quem descobre uma vulnerabilidade (investigador, cliente ou integrador, scanner de terceiros) entra por um canal público composto por security.txt, chave PGP, política publicada e triagem com dono; do canal saem dois destinos: a correção e o aviso aos utilizadores, e, se houver exploração ativa, a notificação de alerta precoce às autoridades, em 24 horas, ao abrigo do artigo 14.º.
Um canal, dois destinos. A triagem é a peça que decide se um relatório segue o circuito normal de correção ou dispara os prazos do artigo 14.º.

O processo por trás do endereço

Um relatório que entra precisa de quatro coisas, por esta ordem: confirmação de receção, triagem com dono e prazo, decisão sobre a gravidade, e um registo de tudo isto que sobreviva à memória de quem atendeu.

É na triagem que os dois circuitos se tocam. Um relatório externo pode ser exatamente o sinal que dispara o artigo 14.º: se descreve exploração ativa, a empresa acaba de “tomar conhecimento” e o relógio das 24 horas conta a partir da conclusão dessa triagem. Quem atende o canal de entrada tem de saber reconhecer o que tem prazos de saída.

O resto do processo é o que já se espera: corrigir, distribuir a atualização pelo canal seguro, publicar o aviso com a vulnerabilidade corrigida, e dar crédito a quem reportou, se o quiser.

Do lado de quem integra

O fabricante que recebe relatórios também tem de os enviar. A partir da aplicação plena, o artigo 13.º, n.º 6, obriga quem identifique uma vulnerabilidade num componente integrado no seu produto, incluindo de código aberto, a comunicá-la a quem fabrica ou mantém esse componente e a partilhar a correção, se a desenvolver. As orientações da Comissão de 27 jul 2026, C(2026) 5252, não vinculativas, pedem que essa comunicação siga os canais e a política de divulgação do próprio projeto, e entendem que não é exigida quando o fabricante pode confirmar que o mantenedor já conhece a vulnerabilidade.

O caso do PHP em outubro de 2026, que o artigo 09 acompanha, mostra o outro lado do mesmo circuito. O projeto pré-anunciou as correções na véspera, as distribuições Linux e os fornecedores de suporte alargado receberam-nas antes do lançamento, e quem integra o PHP sem passar por nenhum deles só as teve com o lançamento público. Para os componentes críticos, isto pede duas coisas preparadas de antemão: seguir os avisos de segurança de cada projeto a montante e saber por que distribuição ou fornecedor chega cada componente. O aviso que o fabricante publica depois tem de permitir identificar o produto afetado, e um documento VEX (afetado, não afetado, corrigido, em investigação) dá essa informação em formato legível por máquina.

Por onde começar

O nosso ponto de partida está à vista: o security.txt deste site, com chave PGP publicada, e a política de divulgação que o acompanha são o embrião do canal do nosso próprio produto, e a entrada 001 do diário fixou essa decisão antes de existir produto no mercado. Para um fabricante com produto vendido, a ordem prática é a mesma e cabe num trimestre: endereço dedicado e security.txt esta semana, política curta publicada a seguir, processo de triagem com dono e um ensaio marcado antes do fim do trimestre.

Um canal aberto antes do primeiro relatório é infraestrutura. Aberto depois, é gestão de crise.

Fontes