Regulamento de Ciber-Resiliência: integrar as obrigações no desenvolvimento de produtos

O Regulamento de Ciber-Resiliência (Cyber Resilience Act, CRA) traz obrigações de cibersegurança para o ciclo de vida dos produtos com elementos digitais abrangidos. Para um CTO, a tarefa prática consiste em ligar aquilo que a engenharia constrói, entrega e mantém às evidências necessárias para demonstrar o cumprimento dessas obrigações.

Essa ligação tem de funcionar ao nível do produto e da versão. Uma política de segurança para toda a empresa não explica se uma determinada versão tem predefinições seguras, que dependências contém ou como os clientes vão receber uma atualização de segurança. Um ticket de vulnerabilidade marcado como «corrigido» não determina que versões suportadas continuam expostas.

O ponto de partida útil é, por isso, um modelo do ciclo de vida do produto: âmbito, requisitos de segurança, evidências de cada versão, tratamento de vulnerabilidades, compromissos de suporte e decisões com responsáveis identificados. Integre esse modelo no desenvolvimento, em vez de o montar à parte antes de uma avaliação.

Defina o limite do produto antes de atribuir controlos

O CRA diz respeito aos produtos com elementos digitais abrangidos pelo seu âmbito, incluindo hardware e software abrangidos. Não é uma regra universal para todos os serviços SaaS. Um serviço alojado e um software distribuído aos clientes podem exigir análises diferentes, e o tratamento remoto de dados que faça parte integrante de um produto tem também de ser examinado.

Utilize as orientações da Comissão Europeia sobre o CRA como referência inicial e, depois, resolva as questões jurídicas específicas do produto. Registe a conclusão, em vez de confiar num pressuposto informal da equipa.

Para cada produto candidato, determine:

• O que os clientes recebem: hardware, software instalado, componentes descarregáveis ou uma combinação.
• Que funções de tratamento remoto de dados são necessárias para que o produto desempenhe as suas funções.
• Como é que o produto é disponibilizado no mercado da UE e que entidade o disponibiliza.
• O seu papel de operador económico: fabricante, importador, distribuidor ou outro papel relevante.
• As exclusões aplicáveis, a legislação específica do produto e as considerações relativas ao software de código aberto.
• A categoria do produto e os requisitos de avaliação da conformidade daí resultantes.

O código aberto exige especial cuidado. O tratamento dado ao software fornecido fora de uma atividade comercial não significa que um fabricante comercial possa ignorar os componentes de código aberto incorporados no seu produto. Distinga a posição do contribuidor a montante da sua responsabilidade pelo produto que disponibiliza.

O resultado de engenharia deve ser um breve registo de âmbito com um diagrama de arquitetura, os identificadores do produto, as entidades comerciais relevantes, os pressupostos e uma conclusão aprovada. Nomeie a pessoa responsável por reabrir essa conclusão quando a funcionalidade ou a distribuição mudarem.

Por exemplo, uma aplicação de gestão descarregável e o respetivo serviço de análise alojado não devem receber automaticamente uma única decisão de âmbito indiferenciada. Identifique que funções operam localmente, quais dependem do serviço e se esse tratamento remoto pertence ao limite do produto. Essa distinção afeta a avaliação do risco, os registos de dependências e a responsabilidade pelos incidentes.

Trabalhe com as datas de aplicação atuais

A Comissão indica 11 de setembro de 2026 para as obrigações de notificação e 11 de dezembro de 2027 para os principais requisitos do CRA. A 7 de outubro de 2026, a data das obrigações de notificação já passou. Trate a preparação para a notificação como um requisito operacional atual, e não como uma tarefa adiada até à preparação da conformidade.

Mantenha visíveis duas linhas de trabalho:

Os produtos colocados no mercado antes da data de aplicação principal exigem atenção às disposições transitórias e às modificações substanciais. Não presuma que um produto mais antigo é irrelevante para a notificação só porque a sua versão original é anterior a dezembro de 2027.

Mantenha um registo datado dos requisitos legais. Quanto aos limiares dos eventos, aos prazos faseados de notificação, aos destinatários e aos procedimentos de submissão, verifique o texto legal atual e as orientações oficiais de aplicação. Não substitua o processo específico do CRA por um modelo genérico de resposta a incidentes.

Transforme os requisitos de segurança em critérios de conceção e de lançamento

Os requisitos essenciais do CRA abrangem as propriedades de segurança dos produtos e o tratamento de vulnerabilidades. A sua implementação deve decorrer da avaliação do risco de cibersegurança do produto, e não de uma checklist universal aplicada sem contexto arquitetural.

Comece pela forma como o produto pode causar danos. Descreva os utilizadores, os ambientes de implementação, as interfaces expostas, as operações privilegiadas, os dados sensíveis e a utilização indevida razoavelmente previsível. Inclua os pressupostos operacionais do cliente: um equipamento implementado numa rede industrial tem uma exposição e restrições de recuperação diferentes das de um utilitário de desktop.

Um exercício prático de modelação de ameaças pode apoiar este trabalho; as orientações da OWASP sobre modelação de ameaças oferecem uma abordagem consolidada. O resultado deve ligar as ameaças a requisitos, decisões de implementação e testes concretos.

Veja como requisitos conhecidos se tornam testáveis:

Estes são exemplos práticos de implementação, e não um substituto dos requisitos aplicáveis. Determine a relevância e a suficiência através da avaliação do risco.

Acrescente critérios de aceitação de segurança ao trabalho sobre funcionalidades. Uma nova API administrativa deve chegar com decisões sobre autenticação, autorização, tratamento de entradas e registo de eventos, e não com a promessa de que a segurança a irá analisar mais tarde. Reveja o modelo de ameaças quando acrescentar uma interface remota, um componente privilegiado ou um novo limite de confiança.

A aprovação de uma versão deve identificar as vulnerabilidades por resolver, a sua explorabilidade, as configurações afetadas e o respetivo tratamento. Aplique o requisito do CRA de disponibilizar os produtos no mercado sem vulnerabilidades exploráveis conhecidas, tendo em conta a avaliação do risco e os requisitos essenciais aplicáveis; registar ou aceitar um risco não satisfaz, por si só, esse requisito. O resultado de um scanner não pode, sozinho, tomar essa decisão: a acessibilidade da vulnerabilidade, os pré-requisitos e o comportamento do produto contam. Inversamente, uma pontuação de gravidade numérica baixa não é razão suficiente para ignorar uma vulnerabilidade que tem consequências no seu modelo de implementação.

O registo da versão deve ligar a revisão do código-fonte aprovada, o artefacto de build, o inventário de dependências, os resultados dos testes e a decisão de segurança. Isto torna a avaliação reprodutível quando, mais tarde, um cliente ou uma autoridade perguntar por uma versão específica.

Integre a diligência devida sobre componentes no processo de build

Os componentes de terceiros criam obrigações que não podem ser cumpridas reencaminhando um aviso de segurança do fornecedor a montante. Precisa de perceber o que entregou, se está afetado e como pode corrigi-lo.

O CRA inclui um requisito de lista de materiais de software no âmbito dos requisitos de tratamento de vulnerabilidades: um formato de uso comum e legível por máquina que abranja, pelo menos, as dependências de primeiro nível. Como recomendação prática, recolha informação mais aprofundada sobre as dependências sempre que as suas ferramentas de build consigam produzir resultados fiáveis. As dependências transitivas determinam muitas vezes a exposição.

Uma SBOM só é útil quando corresponde a um artefacto real do produto. Associe-a ao identificador da versão e ao build, e distinga os componentes entregues das ferramentas usadas apenas no desenvolvimento. Inclua firmware, pacotes do sistema operativo, bibliotecas incluídas e componentes comerciais, quando relevante; uma exportação do gestor de pacotes pode deixar de fora vários destes.

Construa a revisão dos componentes em torno de perguntas que alteram as decisões de engenharia:

• O componente é mantido, e o seu período de suporte é compatível com o nosso?
• Conseguimos obter rapidamente informação sobre vulnerabilidades e atualizações de segurança?
• Temos acesso ao código-fonte, uma via de correção através do fornecedor ou uma estratégia de substituição?
• O componente introduz execução privilegiada ou uma nova ligação externa?
• O produto pode continuar a ser mantido se o fornecedor deixar de dar suporte ao componente?

Nos componentes comerciais, a área de compras deve garantir contactos de segurança, mecanismos de notificação e acesso às correções. Os prazos do fornecedor têm de deixar margem para a sua própria avaliação e para as suas obrigações de notificação. O fabricante do produto continua a precisar de uma via interna de escalada quando a resposta de um fornecedor é incompleta.

Nas dependências de código aberto, conserve a proveniência e um plano de manutenção realista. O facto de um repositório ser publicamente acessível não é evidência de que alguém produzirá uma correção compatível durante o seu período de suporte.

Conceba em conjunto o período de suporte e o mecanismo de atualização

O suporte é um compromisso de engenharia com consequências comerciais. Em regra, o CRA exige um período de suporte de, pelo menos, cinco anos, salvo se o período de utilização previsto do produto for inferior. Determine o período aplicável com base nos critérios do regulamento, em vez de escolher uma data arbitrária que encaixe no roadmap.

Registe a fundamentação, comunique aos clientes a informação de suporte exigida e ligue-a às versões do produto que são mantidas. O compromisso de suporte tem de ter em conta a capacidade de disponibilizar atualizações de segurança, e não apenas a manutenção de um endereço de helpdesk.

Antes de aprovar o plano de suporte de um produto, pergunte se consegue:

• Reconstruir ramos mais antigos ainda suportados com toolchains mantidas.
• Produzir, autenticar e distribuir atualizações de segurança de forma segura.
• Testar as correções em todo o hardware e em todas as configurações de implementação suportados.
• Manter as chaves de assinatura e recuperar com segurança de um comprometimento de chaves.
• Manter disponível a informação de atualização e de segurança destinada aos clientes.
• Lidar com dependências cujo suporte a montante termina antes do seu.

As atualizações de segurança devem, em regra, ser fornecidas gratuitamente durante o período de suporte, nos termos das disposições do regulamento. Cada atualização de segurança disponibilizada durante esse período tem de permanecer disponível durante, pelo menos, dez anos após a sua disponibilização ou durante o resto do período de suporte, consoante o que for mais longo. Planeie as correções de segurança separadamente do desenvolvimento de funcionalidades, para que os clientes não sejam desnecessariamente obrigados a aceitar alterações funcionais sem relação.

Teste mais do que o caminho feliz. Uma instalação interrompida, armazenamento insuficiente, credenciais expiradas e uma verificação falhada podem transformar uma correção válida num problema de disponibilidade. Decida que mecanismos de recuperação são necessários para o perfil de risco do produto.

No fim do suporte, a comunicação aos clientes e os registos internos devem estar de acordo. Não deixe uma página de descarga a sugerir uma manutenção de segurança contínua quando o registo do produto indica que o compromisso terminou.

Construa um runbook de notificação que resista à incerteza

Uma constatação comum de vulnerabilidade, uma vulnerabilidade ativamente explorada e um incidente de segurança grave não são intermutáveis. O processo de notificação do CRA precisa de uma avaliação documentada do facto desencadeador relevante, e não da notificação automática de todos os alertas de um scanner nem da rejeição automática de tudo o que não tenha uma investigação forense concluída.

O runbook deve começar pela receção. Investigadores, apoio ao cliente, fornecedores e equipas de engenharia precisam de uma via conhecida até à função de segurança dos produtos. Conserve o relatório original e registe quando a informação relevante passou a ser conhecida; não reinicie as datas de tomada de conhecimento quando um ticket muda de equipa.

Para eventos potencialmente notificáveis, recolha:

• Os identificadores do produto e as versões suportadas afetadas.
• As evidências de exploração ou do impacto do incidente, com o grau de confiança e as incertezas.
• As condições de ataque conhecidas, as funções afetadas e os pressupostos de implementação.
• As mitigações disponíveis e o estado das medidas corretivas.
• A avaliação do facto desencadeador, o responsável pela notificação e os cálculos dos prazos aplicáveis.
• As notificações submetidas, os avisos de receção, as atualizações posteriores e as comunicações aos clientes.

Verifique em fontes oficiais os prazos faseados de notificação, os requisitos do relatório final, os destinatários e o procedimento de notificação em vigor. As vulnerabilidades ativamente exploradas e os incidentes graves têm pormenores de notificação distintos; um único campo de prazo copiado não basta.

Designe um responsável principal pela notificação e um suplente com autoridade para coordenar a engenharia, a área jurídica e a comunicação com os clientes. Organize antecipadamente o acesso ao mecanismo de notificação aplicável. A revisão jurídica deve estar disponível dentro do prazo de notificação, em vez de se tornar uma fila de aprovação sem limite.

Pratique o processo com informação incompleta. Um ensaio útil começa com um relatório de exploração credível, uma lista incerta de versões afetadas e um fornecedor de componentes indisponível. A equipa deve conseguir tomar uma decisão de notificação atempada e documentada enquanto a investigação prossegue.

A notificação no âmbito do CRA não substitui outros deveres aplicáveis. Um evento relativo a um produto pode também exigir uma avaliação ao abrigo da legislação de proteção de dados ou de um contrato com um cliente. Coordene essas avaliações, mas preserve os respetivos factos desencadeadores, destinatários e registos de decisão separados.

Confirme a classificação antes de escolher o plano de avaliação

A classificação do produto afeta a via de avaliação da conformidade disponível. Não presuma que todos os produtos ligados precisam da mesma avaliação externa, nem que todos os fabricantes podem recorrer a uma avaliação interna.

Determine a categoria aplicável a partir das funções do produto e das definições e anexos do regulamento. Depois confirme a via permitida, incluindo quaisquer condições relativas a normas harmonizadas, especificações reconhecidas, sistemas de certificação ou avaliação por terceiros.

O planeamento das normas precisa de um registo explícito de dependências: que referências são aplicáveis, qual o seu estado atual e o que muda se uma via esperada não estiver disponível. Evite fazer depender o plano de lançamento de um pressuposto não confirmado sobre as normas ou a capacidade de avaliação.

Reveja a classificação quando a funcionalidade mudar. Acrescentar capacidades de gestão da segurança ou de controlo da rede pode afetar a análise, mas o nome de uma funcionalidade, por si só, não determina uma categoria. Avalie a função real e documente a conclusão.

Mantenha a classificação, a via escolhida e os resultados da conformidade ligados à documentação técnica. A marcação CE e a declaração de conformidade têm de seguir o processo aplicável; não substituem a implementação dos requisitos subjacentes.

Mantenha um dossiê de evidências capaz de explicar uma versão

A documentação técnica deve descrever tanto o produto como o raciocínio por detrás das suas decisões de segurança. Conserve as avaliações do risco e a documentação à medida que o produto muda, e aplique aos registos relevantes os requisitos legais de conservação.

Um dossiê de evidências útil para o produto inclui a decisão de âmbito, a arquitetura, a avaliação do risco, os requisitos de segurança, a informação sobre componentes, os resultados da verificação, os procedimentos de tratamento de vulnerabilidades, a fundamentação do suporte e os registos de conformidade. Cada elemento precisa de um responsável e de uma versão identificável.

Utilize identificadores estáveis para ligar estes registos. Um registo de vulnerabilidade deve explicar as versões afetadas, a exposição, o tratamento, a versão de correção e a comunicação exigida. «Corrigido» sem contexto de versão deixa incompletas as evidências do produto.

Os processos existentes do SGSI podem fornecer evidências úteis de governação, de gestão de fornecedores e de desenvolvimento seguro. No entanto, a ISO 27001 diz respeito a um sistema de gestão da segurança da informação com âmbito definido; a certificação não demonstra a conformidade de um produto individual com o CRA. Reutilize as evidências relevantes sem tratar os mapeamentos entre referenciais como equivalência jurídica.

Exemplo prático: uma falha numa dependência de um equipamento suportado

Considere um fabricante ilustrativo que disponibiliza na UE um equipamento ligado à rede. Suponha que o seu âmbito e a sua classificação foram revistos, que dois ramos de versões continuam suportados e que uma biblioteca incluída é dada como ativamente explorada noutros contextos.

A primeira tarefa não é encerrar o aviso do fornecedor a montante. A engenharia identifica que builds do equipamento contêm a biblioteca vulnerável e se a função afetada é acessível. A SBOM sugere que ambos os ramos a contêm, mas a análise da configuração revela uma exposição diferente. Essa distinção é registada com as evidências de suporte.

O responsável pela segurança dos produtos avalia então se os factos disponíveis preenchem o facto desencadeador de notificação aplicável do CRA. A incerteza sobre uma configuração de implementação é registada; não justifica deixar por designar o responsável pela decisão. O runbook de notificação fornece as fases e o procedimento de notificação em vigor.

A engenharia desenvolve uma mitigação temporária e um build corrigido para cada ramo afetado. Os testes abrangem o caminho vulnerável, o funcionamento normal e a instalação autenticada da atualização. Se um dos ramos não puder utilizar a correção do fornecedor a montante, a equipa regista o tratamento alternativo e o risco residual, em vez de marcar todo o produto como corrigido.

A comunicação aos clientes identifica as versões afetadas, as ações de proteção imediatas e a forma de obter a atualização. O momento da divulgação é coordenado com os requisitos aplicáveis de tratamento de vulnerabilidades e com quaisquer considerações de segurança justificadas.

O registo concluído liga o aviso, a análise dos builds afetados, a decisão de notificação, as submissões quando exigidas, os commits da correção, os resultados dos testes, os artefactos da versão e as comunicações. Um revisor consegue agora reconstruir tanto a resposta de engenharia como a decisão de compliance.

Comece por um produto e por uma cadeia de evidências completa

Escolha um produto suportado representativo e acompanhe uma versão recente e uma vulnerabilidade ao longo do ciclo de vida. As ligações de versão em falta, os compromissos de suporte pouco claros e os procedimentos de notificação inacessíveis tornar-se-ão rapidamente visíveis. Transforme cada lacuna numa tarefa com responsável e, depois, alargue o modelo a todo o portefólio.

A Secani pode apoiar este fluxo de trabalho de evidências ligando requisitos, evidências, responsáveis, tarefas e decisões de revisão. As ferramentas de engenharia continuam a ser as fontes operacionais para builds, versões e vulnerabilidades; o espaço de trabalho de compliance relaciona esses registos com a obrigação aplicável. Mantenha explícita a aprovação humana dos mapeamentos e das conclusões, e preserve a rastreabilidade das fontes quando utilizar rascunhos assistidos por IA.

O próximo passo imediato é testar o runbook de notificação. Em paralelo, exija que a próxima versão do produto tenha associadas uma decisão de âmbito, uma avaliação do risco atual, um inventário de componentes e uma aprovação de segurança. Isso cria uma prática de engenharia repetível enquanto avança a preparação da conformidade.