Pular para o conteúdo principal
Vermont Solutions
Contato

Guia · Cibersegurança · DORA

Segurança de aplicações sob o DORA: SAST, DAST, SBOM e ciclo de vida seguro na banca e nos seguros

O DORA (Regulamento (UE) 2022/2554) aplica-se desde 17 de janeiro de 2025 e converte a segurança do software numa obrigação supervisionada: as entidades financeiras devem identificar, proteger, detetar e testar os sistemas TIC que sustentam as suas funções críticas ou importantes, e demonstrá-lo com evidência. Este guia traduz essas obrigações em práticas concretas de segurança de aplicações (SAST, DAST, SBOM, gestão de segredos, testes de resiliência) e explica como as integramos no ciclo de vida do software de bancos e seguradoras.

Não é aconselhamento jurídico: é um guia operacional para CISO, CTO, responsáveis pelo desenvolvimento e pela conformidade. Referências normativas verificadas em 15 de setembro de 2026; as obrigações concretas dependem do tipo de entidade e da criticidade de cada função.

O que o DORA exige ao software e onde o diz

O DORA não nomeia ferramentas nem metodologias: fixa resultados. O seu quadro de gestão do risco associado às TIC (artigos 5.º a 16.º) obriga a inventariar os ativos, protegê-los, detetar anomalias e recuperar; o capítulo dos incidentes (artigos 17.º a 23.º) exige classificar e notificar; o dos testes de resiliência operacional digital (artigos 24.º a 27.º) exige um programa anual de testes; e o dos terceiros (artigos 28.º a 30.º) estende tudo o anterior ao software e aos serviços que a entidade compra.

O Regulamento Delegado (UE) 2024/1774, que desenvolve o quadro de gestão do risco TIC, desce ao pormenor que interessa a uma equipa de desenvolvimento: a política de projetos TIC deve cobrir a aquisição, o desenvolvimento e a manutenção dos sistemas; todos os requisitos, incluindo os de segurança, devem ser testados antes de aprovar a passagem a produção; e os resultados dos testes de segurança devem ser acompanhados e traduzidos em medidas atualizadas sem demora indevida quando o sistema sustenta uma função crítica ou importante.

  • Artigo 8.º — identificação: inventário de ativos TIC, dependências e funções que sustentam, mantido atualizado.
  • Artigo 9.º — proteção e prevenção: políticas de segurança, gestão de patches e atualizações, segmentação e controlo de acessos.
  • Artigo 10.º — deteção: mecanismos de deteção de anomalias com limiares de alerta e monitorização contínua.
  • Artigo 11.º — resposta e recuperação: planos de continuidade TIC e de recuperação testados.
  • Artigos 24.º e 25.º — testes: programa anual que inclui, entre outros, avaliações e análises de vulnerabilidades, análises de código aberto, revisões do código-fonte sempre que exequível, testes baseados em cenários, testes de extremo a extremo e testes de penetração.
  • Artigo 26.º — TLPT: testes de penetração baseados em ameaças (quadro TIBER-EU) pelo menos de três em três anos para as entidades que a autoridade designar.
  • Artigos 28.º a 30.º — terceiros: o software e os serviços TIC contratados entram no mesmo quadro, com cláusulas contratuais mínimas e registo de acordos contratuais.

Da norma à prática: nove controlos de segurança de aplicações

Estes são os controlos que cobrem as obrigações anteriores num ciclo de vida de software moderno. A ordem importa: cada um gera a evidência de que o seguinte necessita e que o supervisor irá pedir.

1. Inventário e classificação por função crítica

Cada aplicação, serviço e componente associado à função de negócio que sustenta e à sua criticidade. Sem isto não é possível priorizar nem justificar o âmbito dos testes (artigo 8.º).

2. Modelação de ameaças na conceção

Antes de escrever código: que ativos a aplicação trata, quem a pode atacar e por onde. É o controlo mais barato e o que mais defeitos evita; alimenta os requisitos de segurança que o RTS exige testar.

3. SAST em cada alteração de código

Análise estática integrada no pipeline, com quality gates que bloqueiam a passagem a produção em função da severidade. É a forma prática de cumprir a revisão do código-fonte que o DORA pede «sempre que exequível» (artigo 25.º) e de deixar rasto de cada constatação e da sua correção.

4. SCA e SBOM: a cadeia de fornecimento do software

Inventário de componentes de terceiros (SBOM) e análise de composição para conhecer as suas vulnerabilidades ao longo do tempo. Cobre o risco de terceiros dos artigos 28.º a 30.º e a segurança da cadeia de fornecimento que a NIS2 também exige.

5. Gestão de segredos e infraestrutura como código

Nenhum segredo em repositórios nem em imagens; credenciais sujeitas a rotação e geridas centralmente; a infraestrutura declarada em código e analisada como o próprio software (artigo 9.º).

6. DAST e testes de penetração antes da produção

Testes dinâmicos contra o ambiente de pré-produção em cada versão relevante e pentest planeado dentro do programa anual (artigos 24.º e 25.º). As constatações entram no mesmo fluxo de correção que as do SAST.

7. Gestão de vulnerabilidades com prazos por criticidade

Um registo único de vulnerabilidades (código, componentes, infraestrutura) com prazos de correção segundo a severidade e a criticidade da função, e evidência da aplicação de patches (artigo 9.º).

8. Registo, deteção e resposta

Logs centralizados, deteção contínua (SIEM/SOC) e manuais de resposta ensaiados (artigos 10.º e 11.º). Os incidentes graves são classificados e notificados à autoridade nos prazos das normas técnicas do DORA: notificação inicial em horas, relatório intercalar e final depois.

9. Testes de resiliência e TLPT

Programa anual documentado para todos os sistemas críticos ou importantes (artigo 24.º) e, para as entidades designadas, testes baseados em ameaças de três em três anos (artigo 26.º), com as constatações incorporadas no plano de remediação.

Sobreposições úteis: NIS2 e ISO/IEC 27001

Para as entidades financeiras, o DORA é a norma setorial e prevalece sobre a NIS2 (Diretiva (UE) 2022/2555) naquilo que regula, mas convém conhecer ambas: a NIS2 aplica-se a outras empresas do grupo e a muitos fornecedores, e o seu artigo 21.º enumera medidas que coincidem ponto por ponto com os controlos anteriores: segurança na aquisição, no desenvolvimento e na manutenção de sistemas, gestão e divulgação de vulnerabilidades, segurança da cadeia de fornecimento, criptografia, controlo de acessos e autenticação multifator.

A ISO/IEC 27001:2022 é a forma mais eficiente de organizar a evidência: os controlos do Anexo A sobre ciclo de vida de desenvolvimento seguro, requisitos de segurança das aplicações, arquitetura segura, codificação segura, testes de segurança em desenvolvimento e aceitação, desenvolvimento subcontratado e separação de ambientes (8.25 a 8.31) são exatamente o que um inspetor do DORA quer ver documentado. A Vermont Solutions opera sob certificação ISO/IEC 27001:2022.

Checklist de doze pontos para o CISO e o CTO

  1. Inventário de aplicações associado a funções críticas ou importantes, revisto pelo menos uma vez por ano.
  2. Requisitos de segurança definidos por aplicação e testados antes de cada passagem a produção.
  3. SAST com quality gates no pipeline e evidência de correção por constatação.
  4. SBOM gerado em cada build e análise de composição com alertas de novas vulnerabilidades.
  5. Gestão centralizada de segredos e análise da infraestrutura como código.
  6. DAST em pré-produção e pentest anual documentados dentro do programa de testes.
  7. Registo único de vulnerabilidades com prazos de correção por severidade e criticidade.
  8. Logs centralizados, deteção contínua e manuais de resposta ensaiados.
  9. Procedimento de classificação e notificação de incidentes graves com prazos e responsáveis.
  10. Cláusulas de segurança, auditoria e saída nos contratos de software e de serviços TIC.
  11. Programa anual de testes de resiliência aprovado pela direção e, se aplicável, TLPT planeado.
  12. Evidência de tudo o anterior gerada pelo próprio processo, e não recolhida à mão antes da inspeção.

Como o fazemos na Vermont Solutions

Integramos os controlos no pipeline de entrega da entidade, não num projeto à parte: SAST, análise de composição e SBOM em cada build, DAST em pré-produção, gestão de segredos e análise da infraestrutura como código, com quality gates que deixam evidência automática. Concebemos modelos de identidade de privilégio mínimo (IAM/PAM, Zero Trust) e implementamos visibilidade e deteção contínuas (SIEM/SOC) com processos de resposta alinhados com a continuidade do negócio.

Trabalhamos sobre plataformas críticas de banca e seguros que não podem parar (cores legacy, grids de cálculo, Kubernetes híbrido) e sob certificação ISO/IEC 27001:2022. Numa seguradora europeia, o reforço dos acessos (MFA em perfis críticos e retirada de protocolos herdados) elevou a pontuação de segurança do Microsoft 365 em 30 % sobre uma base de 11,48 % sem fricção para os utilizadores.

Perguntas frequentes

O DORA obriga a fazer SAST e DAST?

Não nomeia ferramentas. Exige testar os requisitos de segurança antes da produção, rever o código-fonte sempre que exequível e realizar testes de penetração dentro de um programa anual. O SAST e o DAST são a forma prática e rastreável de o cumprir.

Com que frequência é preciso fazer testes de segurança?

O programa de testes de resiliência operacional digital é anual para os sistemas que sustentam funções críticas ou importantes (artigo 24.º), com avaliação de vulnerabilidades e testes de penetração no seu âmbito. As entidades designadas pela sua autoridade realizam, além disso, testes de penetração baseados em ameaças (TLPT) pelo menos de três em três anos (artigo 26.º).

O que acontece com o software que compramos a terceiros?

Entra no mesmo quadro: os artigos 28.º a 30.º exigem diligência devida, cláusulas contratuais mínimas (segurança, auditoria, incidentes, saída) e registo de acordos contratuais. Na prática, cobre-se com SBOM, análise de composição e cláusulas de segurança nos contratos.

A NIS2 também se aplica a um banco ou a uma seguradora?

Para as entidades financeiras, o DORA é a norma setorial e prevalece naquilo que regula. A NIS2 continua a ser relevante para outras empresas do grupo e para muitos fornecedores, e as suas medidas do artigo 21.º coincidem com os controlos deste guia.

Que prazos existem para notificar um incidente grave?

As normas técnicas do DORA fixam uma notificação inicial em poucas horas a partir da classificação do incidente como grave, um relatório intercalar poucos dias depois e um relatório final cerca de um mês depois. Os prazos exatos dependem da norma técnica em vigor e da autoridade competente; o procedimento interno deve fixá-los com nomes e horas.

Assessment de segurança de aplicações sob o DORA

Revemos o seu inventário de aplicações críticas, o pipeline de entrega e a evidência disponível, e entregamos-lhe o plano de controlos com responsáveis e prazos. Sem alterar nada em produção até o plano estar aprovado.

Solicitar assessment →

Conteúdo relacionado

Última atualização: 2026-09-15. Conteúdo editorial da Vermont Solutions, citável mediante atribuição com ligação a esta página. Não constitui aconselhamento jurídico.