Preparar o fluxo de tratamento de vulnerabilidades de um fabricante para o CRA: recebimento, evidências e contagem dos prazos de notificação

Objetivo

Situação em 25 de outubro de 2026. Preparar o fluxo de tratamento de vulnerabilidades de um fabricante para que evidências, responsabilidades pelos produtos e prazos de notificação possam ser consultados durante um incidente. Consulte novamente o artigo 14, o Anexo I e as instruções atuais da SRP da ENISA ao atualizar o fluxo. Este é um protocolo de preparação proposto, não uma alegação de que uma organização passou por uma avaliação de conformidade com sucesso.

A notificação prevista no artigo 14 é aplicável desde 11 de setembro de 2026. O artigo 71 estabelece 11 de dezembro de 2027 para os requisitos mais amplos, incluindo as obrigações de tratamento de vulnerabilidades do Anexo I. A preparação para essas obrigações futuras pode apoiar as notificações agora, mas suas datas devem permanecer distintas. Orientações de notificação da Comissão.

Pré-requisitos

Identifique os produtos relevantes do fabricante, as equipes de engenharia responsáveis por eles, um responsável pelas notificações e um substituto. Disponibilize um registro de incidentes com acesso restrito, acesso a informações sobre versões e componentes e um canal de comunicação com os usuários afetados. Essas são medidas organizacionais propostas. Confirme a CSIRT coordenadora apropriada com base no artigo 14(7), em vez de selecionar uma apenas pela conveniência do idioma.

Passos

1. Vincule o recebimento dos relatos a um responsável identificado. Prepare a política de divulgação coordenada de vulnerabilidades e o contato para relatos descritos no Anexo I, Parte II. Um security.txt opcional conforme a RFC 9116 pode direcionar pesquisadores a eles: use HTTPS em /.well-known/security.txt, inclua os campos obrigatórios Contact e Expires e forneça o link da política em Policy. Mantenha o arquivo e os destinos atualizados. RFC 9116, seções 2, 3 e 5.

2. Crie imediatamente um registro do caso. Como modelo prático de registro, separe o horário de recebimento, as evidências recebidas, o momento em que se tomou conhecimento de um evento sujeito a notificação, o responsável pela decisão e as revisões posteriores. Preserve as evidências originais e explique as mudanças na avaliação. Aprovações internas não devem redefinir silenciosamente o registro de data e hora da tomada de conhecimento.

3. Associe o problema às versões. Mantenha uma lista de materiais de software (SBOM) junto aos identificadores de produtos e versões. O Anexo I, Parte II(1), exige um formato de uso comum legível por máquina que abranja pelo menos as dependências de nível superior, quando esse requisito for aplicável. Este protocolo propõe vincular esses registros às versões distribuídas, para que a lista de produtos afetados possa ser reconstruída. Uma SBOM é um inventário, não uma prova de exploração.

4. Avalie separadamente os critérios legais de notificação. Conforme o artigo 3(42), a exploração ativa exige evidências confiáveis de que um ator malicioso explorou a vulnerabilidade sem a permissão do proprietário do sistema. Compare incidentes graves com ambos os critérios do artigo 14(5). Registre as evidências e as questões não resolvidas; uma pontuação de gravidade, por si só, não comprova exploração ativa. Os passos 1, 3 e 4 se baseiam no regulamento.

5. Mantenha o registro dos prazos. Agende as etapas de 24 horas e 72 horas a partir da tomada de conhecimento, mantendo a exigência de agir prontamente. Conte o prazo do relatório final de vulnerabilidade a partir da disponibilização de uma medida corretiva ou de mitigação, e o do relatório final de incidente a partir do envio da notificação de incidente. Armazene juntos os comprovantes, as versões enviadas e as solicitações das autoridades.

6. Prepare o acesso à plataforma e as comunicações. A ENISA exige contas pessoais EU Login com autenticação multifator. Suas perguntas frequentes de outubro recomendam iniciar o cadastro na SRP quando uma notificação for necessária; prepare o acesso ao EU Login antecipadamente. Mantenha a comunicação com os usuários afetados em paralelo às notificações às autoridades. Perguntas frequentes da ENISA sobre a SRP, pergunta 9.

7. Faça uma simulação interna. Use um caso de produto fictício e rascunhos de relatórios fora da plataforma real de notificação. Peça ao substituto que localize as evidências, reconstrua os prazos e explique a seleção do destinatário. Registre as informações ausentes e repita a passagem de responsabilidade que falhou depois de corrigir essas lacunas.

Resultado esperado

Um revisor consegue acompanhar um caso desde o recebimento, passando pela associação aos produtos, pela avaliação dos critérios e pelo envio, até as comunicações aos usuários, sem reconstruir a cronologia a partir de mensagens dispersas.

Limites e base de verificação

Não se alega nenhum resultado de simulação ou de uso em campo. A proposta combina o regulamento, as orientações da Comissão, as perguntas frequentes da ENISA atualizadas em 15 de outubro de 2026 e a RFC 9116. Nem a publicação de um arquivo de contato nem uma simulação bem-sucedida comprovam conformidade; o enquadramento dos produtos e avaliações controversas dos critérios de notificação ainda exigem revisão qualificada.