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

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, o aviso de 24 horas às autoridades 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

O canal vale o processo que o atende. 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. Nada disto é exótico; tudo isto falha quando é improvisado.

Por onde começar

O nosso ponto de partida está à vista: o security.txt deste site, com chave PGP publicada, é 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