Segurança desde a conceção CRA: trabalho de produto

«Segurança desde a conceção» não é um documento de política para assinar. Num produto com elementos digitais, deve ser visível nas decisões de conceção, na redução da superfície de ataque, nas predefinições seguras, no tratamento de atualizações, nos testes e na gestão de vulnerabilidades ao longo de todo o ciclo de vida do produto.

Um modelo prático é simples: risco → requisito → decisão de conceção → ação → teste → resultado → prova → revisão.

Transforme os requisitos essenciais em trabalho de produto

O anexo I do CRA contém requisitos essenciais de cibersegurança. No trabalho prático de produto, as equipas têm de tratar áreas como:

conceção do produto com um nível de cibersegurança adequado ao risco;
proteção contra acesso não autorizado;
confidencialidade, integridade e disponibilidade dos dados e das funções;
redução da superfície de ataque;
mecanismos que reduzem o impacto de um incidente;
registo e monitorização da atividade relevante para a segurança;
remoção segura de dados e definições;
distribuição segura de atualizações;
testes e revisões de segurança regulares;
divulgação coordenada de vulnerabilidades.

Uma lista de verificação é um ponto de partida. Não é uma prova de execução.

Exemplo: «proteger contra acesso não autorizado»

Um registo fraco diz:

«O sistema tem autenticação.»

Um registo operacional pode mostrar:

Risco: o comprometimento de uma conta administrativa pode alterar configurações críticas para a segurança.
Decisão: as funções privilegiadas exigem um mecanismo definido de autenticação e controlo de sessões.
Responsável: uma pessoa ou equipa identificada.
Implementação: ligação à alteração de engenharia.
Teste: cenário que verifica o comportamento exigido.
Resultado: PASS/FAIL com versão do produto e data.
Prova: relatório, registo técnico, captura de ecrã ou artefacto de teste.
Revisão: nova avaliação após alterações na autenticação ou no perfil de risco.

Meses depois, a organização consegue mostrar não apenas o que pretendia fazer, mas também o que foi efetivamente verificado.

Segurança por defeito

A configuração predefinida é relevante porque muitos utilizadores não alteram as definições de segurança após a instalação. Os requisitos CRA abrangem áreas como configuração segura, atualizações e mecanismos de proteção.

Para cada função relevante para a segurança, pergunte:

que configuração recebe um novo utilizador por defeito;
por que motivo essa predefinição é adequada à utilização normal;
que proteções podem ser enfraquecidas ou desativadas;
se as alterações de risco são compreensíveis para o utilizador;
se o produto consegue regressar a um estado seguro;
que teste verifica o comportamento após a instalação e a atualização.

Integre a segurança no processo de disponibilização de versões, e não na documentação posterior

Uma revisão de versão deve verificar, pelo menos:

se o modelo de ameaças ou o perfil de risco mudou;
se foram introduzidas novas dependências;
se os testes de segurança cobrem a alteração;
se as vulnerabilidades conhecidas têm decisões documentadas;
se a informação de segurança para os utilizadores continua correta;
se os pressupostos do período de apoio e as dependências continuam realistas;
se as provas estão anexadas à versão correta do produto.

Se estas perguntas só são feitas durante uma auditoria, a organização tem um processo de documentação, e não segurança desde a conceção.

ENISA: ações repetíveis em vez de slogans

A ENISA publicou o seu «Secure by Design and Default Playbook» para PME em 30 de julho de 2026. O material centra-se na transformação dos princípios em ações repetíveis nos processos existentes de engenharia, produto e disponibilização de versões. O mesmo princípio funciona na implementação do CRA: utilize o processo real de entrega da equipa e torne explícitas as responsabilidades e as provas.

Como o Pulsar apoia um fluxo baseado em provas

Os riscos, controlos, tarefas, documentos, provas, auditorias e relatórios no Pulsar podem ligar uma decisão de conceção à implementação, verificação e revisão.

A IA no Pulsar deve permanecer uma assistente na preparação de rascunhos. Não deve aprovar autonomamente uma avaliação do risco, uma exceção de segurança ou uma decisão de conformidade do produto.

Veja o Pulsar GRC num fluxo do requisito à prova

Orientações relacionadas

Método proposto: rever uma função de administração remota

Imagine um produto que acrescenta administração remota para facilitar assistência. A alteração também muda quem pode aceder, de onde e com que permissões. A revisão deve começar quando se propõe a função, antes de a implementação comprometer decisões difíceis de modificar. Este exemplo hipotético testa um processo de engenharia; não representa um produto de cliente nem um resultado garantido.

Produto descreve utilização prevista e limites do acesso. Engenharia identifica interfaces, dados e componentes remotos. Segurança propõe cenários de abuso pertinentes: utilização de uma sessão perdida, escalada de privilégios ou acesso a outra organização. A equipa seleciona riscos que correspondem à arquitetura e explica o motivo. Uma lista importada sem contexto pode omitir o problema real e criar trabalho irrelevante.

Cada risco torna-se um comportamento verificável. Por exemplo, uma conta sem autorização administrativa não pode alterar parâmetros protegidos, mesmo utilizando diretamente uma API. O ensaio verifica comportamento, não apenas se um botão está escondido. Registe versão, ambiente, passos e resultado. Se a prova pertence a outra versão, explique porque continua pertinente ou determine o que deve repetir.

Critérios que permitem detetar falhas

«O acesso será seguro» não permite avaliar uma entrega. Escreva quem tenta fazer o quê, sob que condição e qual deve ser o resultado. Inclua casos autorizados e não autorizados. Para operações sensíveis, considere estado anterior, resultado esperado e registo pertinente. A escolha dos ensaios depende da função e da avaliação de risco, não de uma lista igual para todos os produtos.

A especificação descreve a intenção; o resultado de ensaio demonstra o que foi observado. Mantenha ambos separados e ligados. Um documento que propõe um controlo não prova que foi implementado. Uma tarefa concluída pode precisar de verificação independente ou de um resultado concreto antes de apoiar uma afirmação sobre proteção.

Quando se encontra uma falha, a decisão pode exigir correção, restrição de função ou adiamento. Se alguém propõe aceitar risco, uma pessoa com autoridade revê efeitos e compatibilidade com requisitos aplicáveis. Uma aceitação interna não elimina obrigações legais. Registe também o que falta e as condições que obrigam a rever a decisão.

Instalação e atualização podem produzir estados diferentes

Uma configuração inicial adequada pode perder-se ao atualizar uma versão antiga. Defina ensaios para percursos suportados: instalação nova, atualização e migração quando pertinente. Conserve condições de origem, versão final e alterações de configuração. Se a migração afeta permissões ou dados, a verificação deve cobrir esse efeito.

A recuperação merece atenção própria. Uma interrupção durante atualização pode deixar o produto num estado parcial. Engenharia determina estados admissíveis, informação ao utilizador e método de recuperação. Nem todos os produtos permitem a mesma solução. O dossier conserva fundamento e demonstra o comportamento escolhido por ensaio, em vez de repetir uma promessa geral de continuidade.

Reveja também a primeira utilização. Identifique proteções ativadas por defeito, decisões que o utilizador deve tomar e alterações que enfraquecem segurança. A informação precisa de ser compreensível para o utilizador previsto. Um aviso tecnicamente correto mas incompreensível pode não apoiar uma decisão consciente sobre configuração.

Uma limitação temporária precisa de uma saída

Suponha que uma dependência externa impede uma melhoria no prazo previsto. Registe produtos afetados, limitação, medidas possíveis e responsável. Defina uma revisão que impeça «temporário» de se tornar indefinido. As condições de distribuição e tratamento do risco devem ser avaliadas conforme o caso e o direito aplicável, não decididas pelo estado de uma tarefa.

Comprove que uma mitigação atua sobre o mecanismo de falha. Um aviso pode informar sem substituir o controlo necessário. Uma restrição pode reduzir exposição, mas precisa de verificação. Distinga medidas ensaiadas de trabalho ainda planeado. Uma atividade futura nunca deve aparecer como proteção já existente.

Se a dependência muda, conserve nova avaliação e relação com a anterior. Não elimine o historial para apresentar uma conclusão mais limpa. As decisões passadas explicam como a organização chegou à versão atual e ajudam a evitar repetição de pressupostos rejeitados.

Revisão da publicação com provas pertinentes

Organize uma revisão limitada ao produto e alteração. Quem aprova deve localizar risco, requisito, implementação e resultado. As lacunas abertas têm efeito e responsável claros. Uma aprovação da versão de teste não autoriza automaticamente outra compilação. Uma decisão relativa a uma função não abrange mudanças posteriores sem revisão.

Para testar o processo, selecione uma alteração já publicada e peça a outra pessoa reconstruir o fundamento. Deve explicar por que se escolheu a proteção, que ensaio se executou e onde está o resultado. Uma fonte inacessível revela problema de conservação; uma prova que não cobre o risco revela problema técnico. São ações diferentes.

Documentação e engenharia mantêm responsabilidades próprias

O Pulsar pode ligar riscos, decisões, ações e provas fornecidas pela organização. Compilações, análise de código e ensaios executam-se com ferramentas adequadas de engenharia. Conserve identificadores que permitam relacionar os resultados. Um link documental não executa uma prova nem demonstra recolha automática da nuvem.

Um ensaio deve incluir um comportamento indesejado

Para uma proteção de autorização, teste uma operação que deveria ser recusada, além do percurso permitido. A mesma interface pode apresentar resultado correto e a API aceitar ação indevida. A seleção depende da arquitetura. Registe condição e resultado sem utilizar dados ou sistemas de terceiros fora da autorização de teste.

Se o resultado diverge, preserve evidência e decisão sobre tratamento. Não modifique o critério depois para aceitar comportamento observado. Uma mudança de requisito precisa de fundamento e revisão própria. Caso contrário, a prova torna-se apenas um documento que descreve qualquer implementação como adequada.

Após correção, confirme que se ensaiou a versão pertinente e que o resultado acompanha entrega. A prova de um protótipo não demonstra automaticamente outra compilação. Identificadores claros permitem perceber o que foi verificado e que diferenças continuam abertas. Esse detalhe torna a revisão útil para engenharia e para avaliação posterior.

A IA pode propor critérios ou resumos, mas uma pessoa verifica arquitetura, fontes e conclusões. Não aceite referências impossíveis de localizar nem preenchimento fictício de resultados. O objetivo é uma decisão defensável sobre uma alteração real. Uma política extensa sem esse percurso deixa por resolver o risco que deveria tratar.

Fontes

Fontes verificadas: 12 de setembro de 2026.

Pulsar GRC — acesso, isolamento de dados e exportação (polaco)