Desenvolvimento e aquisição seguros NIS 2 ao abrigo do artigo 21.o, n.o 2, alínea e)
A NIS 2 diz que tem de proteger os sistemas na aquisição, no desenvolvimento e na manutenção. O artigo 21.o, n.o 2, alínea e), é o guarda-chuva. O §6 do CIR (UE) 2024/2690 divide-o em dez subsecções. A Alemanha inscreve-o no direito nacional através do §30(2)(5) BSIG.
A versão curta
O artigo 21.o, n.o 2, alínea e), é o dever-guarda-chuva para a segurança ao longo de todo o ciclo de vida das TI. Não só o código. Não só as correções. Todo o percurso: comprar um sistema, construí-lo, configurá-lo, alterá-lo, testá-lo, corrigi-lo, operá-lo, desmantelá-lo. A mesma regra aplica-se em toda a UE.
O CIR (UE) 2024/2690 preenche o detalhe. O §6 do anexo tem dez subsecções (§6.1 a §6.10) que operacionalizam o dever. Esta página cobre o lado do desenvolvimento e da alteração: aquisição (§6.1), o ciclo de vida de desenvolvimento seguro (§6.2), a gestão de configurações (§6.3), a gestão de alterações (§6.4), os testes de segurança (§6.5) e a gestão de correções (§6.6). A segurança de rede, a segmentação, a proteção contra software malicioso e a gestão de vulnerabilidades (§6.7 a §6.10) têm as suas próprias páginas.
A Alemanha inscreve a mesma regra no direito nacional através do §30(2)(5) BSIG. A redação é quase palavra por palavra o texto da UE. Esta página percorre a Diretiva, o regulamento de execução da UE e a transposição alemã por essa ordem.
Artigo 21.o, n.o 2, alínea e), da Diretiva NIS 2 (2022/2555)
Segurança na aquisição, no desenvolvimento e na manutenção das redes e dos sistemas de informação, incluindo o tratamento e a divulgação de vulnerabilidades.
Este é o ponto e) na lista das dez medidas de cibersegurança que todas as entidades essenciais e importantes têm de implementar. É o único ponto da lista que explicitamente se estende da ordem de compra até ao fim de vida.
CIR (UE) 2024/2690, anexo §6
Medidas de segurança na aquisição, no desenvolvimento e na manutenção das redes e dos sistemas de informação (artigo 21.o, n.o 2, alínea e), da Diretiva (UE) 2022/2555).
Por ser um regulamento (não uma diretiva), é direito da UE diretamente vinculativo. Não é necessária transposição nacional. Aplica-se a prestadores de DNS, registos TLD, prestadores de nuvem, centros de dados, prestadores de serviços geridos e aos outros setores enumerados no seu anexo. O §6 tem dez subsecções numeradas que nomeiam, cada uma, um dever específico.
§30(2)(5) BSIG (Alemanha)
Segurança na aquisição, no desenvolvimento e na manutenção de sistemas de tecnologias de informação, incluindo o tratamento e a divulgação de vulnerabilidades.
A Alemanha copia o texto da UE quase palavra por palavra. «Sistemas de tecnologias de informação» em vez de «redes e sistemas de informação» é redação, não significado. O BSI aponta os módulos IT-Grundschutz CON.8 (desenvolvimento de software) e OPS.1.1.3 (gestão de correções e alterações) como a via prática.
Inscreva requisitos de segurança em cada compra
Antes de comprar um produto ou serviço de TI, escreve o que ele tem de fazer em matéria de segurança. Autenticação, registo de eventos, suporte de atualizações, divulgação de vulnerabilidades, região de alojamento, onde os dados ficam. Depois valida que o fornecedor cumpre efetivamente os requisitos. Isto recai sobre a entidade compradora, não sobre o fornecedor. «Usamos SaaS» não transfere o dever.
Execute um ciclo de vida de desenvolvimento seguro
Os requisitos de segurança são analisados durante a especificação e o desenho. Aplicam-se princípios de codificação segura, incluindo segurança desde a conceção e arquiteturas de confiança zero. Os próprios ambientes de desenvolvimento são protegidos. Os testes de segurança ocorrem antes do lançamento. Os dados de teste são tratados com cuidado, não copiados da produção. Todo o ciclo de vida é documentado, não apenas uma ou duas práticas.
Aplique correções num prazo adequado, teste primeiro
As correções de segurança são aplicadas num prazo adequado (o texto do CIR), ligado à gravidade da vulnerabilidade. As correções são testadas antes da produção. As correções de emergência são documentadas. «Sempre que a equipa tiver tempo» não é um prazo. Escolha uma cadência, escreva-a e prove que a cumpre.
Segurança da aquisição ao desmantelamento
O §6 não é sobre desenvolvimento no sentido estrito. Cobre todo o ciclo de vida: como escolhe o que comprar, como constrói, como configura, como testa, como corrige, como altera, como retira. Um Mittelstand que compra 95 por cento do seu software continua a ser responsável pelo §6.1 (requisitos de aquisição) e pelo §6.6 (gestão de correções). Não pode sair do ciclo de vida só porque não escreve código.
Disciplina de alterações: nenhuma alteração de produção sem registo
O §6.4 é direto: as alterações à produção são geridas, documentadas e revistas. As alterações de emergência também são documentadas, mas após o facto em vez de antes. Uma alteração sem ticket, sem aprovador e sem plano de reversão falha o requisito, mesmo que funcione. Os auditores cruzam o registo de alterações com o sistema de tickets. Se não conseguirem reconstruir quem alterou o quê e quando, o controlo não está implementado.
BSI / IT-Grundschutz CON.8 + OPS.1.1.3
O BSI associa o §30(2)(5) BSIG a dois módulos Grundschutz. O CON.8 «Software-Entwicklung» cobre o lado do SDLC: requisitos, codificação segura, teste, lançamento. O OPS.1.1.3 «Patch- und Änderungsmanagement» cobre o lado da alteração e da correção. Se seguir o CON.8 e o OPS.1.1.3, está dentro do que o §30 BSIG exige.
Orientação Técnica de Implementação da ENISA
A ENISA, a agência de cibersegurança da UE, publica uma Orientação Técnica de Implementação (TIG) que pega no texto abstrato do §6 do CIR e mostra o que fazer na prática. Associa cada subsecção a controlos da ISO/IEC 27001:2022 (A.8.25 a A.8.32 sobre desenvolvimento seguro, A.5.20 a A.5.23 sobre relações com fornecedores), pelo que as certificações existentes dão uma vantagem.
Leis nacionais de transposição
Cada Estado-Membro tem a sua própria lei de transposição (Países Baixos: Cyberbeveiligingswet, Áustria: NISG, Bélgica: NIS2-Wet). Os deveres ao abrigo do artigo 21.o, n.o 2, alínea e), são os mesmos porque a Diretiva estabelece uma norma única à escala da UE. O que difere: qual o quadro nacional que o regulador aponta como via prática.
Usamos SaaS, por isso o desenvolvimento seguro é tarefa do fornecedor.
Meio certo. O fornecedor é dono do código. Você continua a ser responsável pelo §6.1: requisitos de segurança documentados para cada produto ou serviço de TI que compra, mais a validação de que o fornecedor os cumpre. Autenticação, registo de eventos, suporte de atualizações, localização dos dados, notificação de violações. Se o seu dossiê de aquisição está vazio, o dever não está cumprido, mesmo que o fornecedor seja excelente.
Fazemos revisões de código, por isso a parte do SDLC está coberta.
A revisão de código é uma prática. O §6.2 quer todo o ciclo de vida documentado: requisitos de segurança durante a especificação, princípios de codificação segura (incluindo segurança desde a conceção e confiança zero), ambientes de desenvolvimento protegidos, procedimentos de teste de segurança antes do lançamento, tratamento cuidadoso dos dados de teste. Uma única prática sobre um processo não documentado não cumpre a secção.
Aplicamos correções quando a equipa tem tempo.
O §6.6 exige um prazo adequado ligado à gravidade, mais testes antes da produção e documentação das correções de emergência. «Quando há tempo» não é um prazo. Escolha uma cadência (por exemplo, crítica em 72 horas, alta em 14 dias), escreva-a e prove que a cumpre no registo de alterações. Um auditor irá reconstruir o seu histórico de correções a partir do sistema de tickets.
A maior parte da TI do Mittelstand alemão é assim: 90 por cento de software de fornecedores (ERP, processamento salarial, correio, partilha de ficheiros, CRM), alguma cola de integração, scripts internos ocasionais. O grande esforço do §6 para esse perfil não é o SDLC. É o §6.1 aquisição e o §6.6 gestão de correções.
Escreva o modelo de requisitos de segurança uma vez. Autenticação, registo de eventos, divulgação de vulnerabilidades, suporte de atualizações, região de alojamento, exportação de dados, notificação de violações. Aplique-o a cada nova aquisição e a cada renovação. Conjugue-o com uma cadência de correções escrita (crítica / alta / média, cada uma com um prazo) e um registo de alterações que todos usam. Isso cobre o grosso do §6 para um Mittelstand típico sem contratar um especialista em segurança de software.
Construímos os requisitos de aquisição do §6.1, a documentação do SDLC do §6.2, o registo de alterações do §6.4 e a cadência de correções do §6.6 no módulo PRO da plataforma. Preenche o modelo de aquisição uma vez e reutiliza-o. Cada novo produto ou serviço de TI passa pela mesma lista de verificação de segurança com uma aprovação.
O registo de alterações e a cadência de correções correm sobre o mesmo rasto de auditoria do resto da plataforma: ticket, aprovador, plano de reversão, ficheiro de prova. As alterações de emergência recebem o formulário após o facto. Não mantém um registo de conformidade separado. Quando um auditor pergunta como corrigiu um CVE, a resposta é uma consulta, não três folhas de cálculo.
- Diretiva (UE) 2022/2555 (NIS 2), artigo 21.o, n.o 2, alínea e). eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulamento de Execução (UE) 2024/2690 da Comissão (CIR), anexo §6. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Lei do BSI (BSIG), §30(2)(5) com a redação da Lei de Implementação da NIS2 e de Reforço da Cibersegurança
- Módulos IT-Grundschutz do BSI CON.8 «Software-Entwicklung» e OPS.1.1.3 «Patch- und Änderungsmanagement»
- Orientação Técnica de Implementação da ENISA para o CIR (UE) 2024/2690 (à data de maio de 2026)