Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- O registro de informações da DORA lista contratos de serviços de tecnologia prestados de forma contínua; portanto, uma biblioteca que você baixa sem contrato geralmente não consta nesse registro.
- Normas técnicas vinculativas exigem o rastreamento das bibliotecas de código aberto utilizadas por serviços que suportam funções críticas ou importantes.
- O software presente nos sistemas de uma entidade financeira está sujeito às regras de gestão de riscos, independentemente da existência ou não de um contrato com o fornecedor.
Os requisitos de conformidade da DORA se estendem às bibliotecas de código aberto, mesmo quando seu registro de informações não as inclui. A Lei de Resiliência Operacional Digital (DORA) da UE as menciona em suas normas técnicas sobre gestão de riscos em tecnologias da informação e comunicação (TIC), que são distintas das regras relativas aos contratos com fornecedores.
O registro de informações é a lista que uma entidade financeira mantém de seus contratos de serviços de TIC em andamento. O fato de uma biblioteca constar nesse registro depende da existência de um contrato subjacente, como, por exemplo, um contrato de suporte pago. As regras de gestão de riscos se aplicam à biblioteca de qualquer forma, desde que ela seja executada em seus sistemas. Portanto, ela deve constar no inventário de softwares que você utiliza, mesmo que o registro a omita. A ausência de uma biblioteca nesse inventário constitui uma lacuna no registro exigido pela DORA. Os supervisores podem ordenar que você corrija isso, e cada Estado-Membro estabelece penalidades para violações da DORA. As autoridades publicam as decisões finais sobre as penalidades.
A quais organizações se aplicam os requisitos de conformidade da DORA?
A DORA se aplica a vinte categorias de entidades financeiras, entre as quais instituições de crédito, instituições de pagamento e de moeda eletrônica, empresas de investimento, seguradoras, prestadores de serviços de criptoativos, contrapartes centrais e plataformas de negociação. Os prestadores de serviços terceirizados de TIC — empresas que fornecem serviços de tecnologia a essas entidades — são listados separadamente e estão sujeitos à supervisão direta da UE apenas se forem designados como críticos.
Algumas entidades estão fora do âmbito de aplicação, incluindo certas gestoras de fundos de investimento alternativos de menor porte e seguradoras, instituições de previdência com até 15 membros e instituições de giro postal (bancos postais que administram contas de pagamento). Os Estados-Membros também podem excluir certas entidades que a diretiva bancária da UE isenta de suas próprias regras.
Empresas de investimento de pequeno porte e não interconectadas, instituições de pagamento e de dinheiro eletrônico isentas, pequenas instituições de previdência (com menos de 100 participantes) e as instituições isentas da diretiva bancária que os Estados-Membros mantêm no âmbito de aplicação dispõem de um quadro simplificado de gestão de riscos de TIC, com regras específicas nas normas técnicas. Se esse for o seu caso, comece por aí. Todos os demais devem seguir o quadro completo, adaptado ao porte e ao perfil de risco, e é isso que o restante deste artigo aborda.
O Registro é estruturado em torno de contratos
O texto principal da DORA é o Regulamento (UE) 2022/2554, doravante denominado “o Regulamento”. O artigo 3º do Regulamento define um prestador de serviços de TIC de terceiros como uma empresa que presta serviços de TIC, e os serviços de TIC como serviços digitais e de dados prestados por meio de sistemas de TIC de forma contínua. O registro, os termos contratuais e as regras de saída referem-se a um prestador que oferece esse tipo de serviço.
Nos termos do Artigo 28, parágrafo 3, você deve manter um registro com informações sobre todos os acordos contratuais relativos a esses serviços, separando aqueles que dão suporte a funções críticas ou importantes dos demais. Funções críticas ou importantes são aquelas cuja interrupção prejudicaria significativamente as finanças da entidade, seus serviços ou sua capacidade de cumprir as condições de sua autorização. Pelo menos uma vez por ano, você deve comunicar seus novos contratos à autoridade competente, incluindo quem os presta e quais serviços e funções eles abrangem. Você também deve disponibilizar o registro completo mediante solicitação. Os modelos padrão do registro estão previstos no Regulamento de Execução (UE) 2024/2956 da Comissão.
O Artigo 30 estabelece os termos mínimos do contrato, e o Artigo 28, parágrafo 8, exige estratégias de saída para serviços que dão suporte a funções críticas ou importantes. Quando um contrato para tal serviço permitir a subcontratação, o Artigo 29 exige que você avalie os riscos, incluindo aqueles decorrentes de cadeias longas ou complexas. Uma norma técnica regulatória (RTS), o Regulamento Delegado da Comissão 2025/532, especifica os elementos que você deve determinar e avaliar quando esses serviços forem subcontratados. Os modelos do registro também registram cada subcontratado que efetivamente sustenta tal serviço.
Observação: As Autoridades Europeias de Supervisão (ESAs) publicam um documento com perguntas frequentes (FAQ) elaborado pela equipe sobre a prestação de informações ao registro, disponível no site da Autoridade Bancária Europeia (EBA). O documento afirma que a aquisição única de uma solução estática, sem manutenção, suporte ou atualizações contínuas, não constitui um serviço de TIC. Trata-se de uma orientação da equipe, e não da posição oficial das ESAs.
Os provedores críticos estão sujeitos a um regime de supervisão separado, administrado pelas ESAs: a EBA, a Autoridade Europeia de Seguros e Pensões Ocupacionais e a Autoridade Europeia dos Valores Mobiliários e dos Mercados. Elas publicaram a primeira lista de provedores terceirizados de serviços de TIC críticos designados em 18 de novembro de 2025 e devem atualizá-la anualmente. A designação se aplica a empresas que prestam serviços de TIC; portanto, uma biblioteca de código aberto, por si só, não é candidata. Uma biblioteca baixada sem contrato fica fora do registro, das regras contratuais e da supervisão de provedores críticos, pois nenhum provedor a fornece a você como um serviço contínuo. No entanto, ela ainda está sujeita às regras de gestão de riscos de TIC da DORA, que a tratam como software utilizado pela entidade.
Onde as bibliotecas de código aberto aparecem no regulamento
Os requisitos de conformidade com o DORA que se referem ao software de código aberto estão previstos nas normas de gestão de riscos de TIC. O Regulamento define um ativo de TIC como um ativo de software ou hardware presente na rede e nos sistemas de informação utilizados pela entidade. O Artigo 6º exige a proteção dos ativos de TIC, incluindo software de computador, e o Artigo 8º exige que você os identifique, classifique e documente, mapeie suas interdependências e mantenha inventários.
A tabela apresenta os requisitos regulatórios com impacto mais direto sobre as bibliotecas. Nela, “RTS 2024/1774” refere-se ao Regulamento Delegado 2024/1774 da Comissão, o RTS sobre gestão de riscos em TIC.
| Tema | O que é necessário | Fonte |
|---|---|---|
| Inventário de ativos de TIC | Identificar, classificar e documentar os ativos de software e suas interdependências, além de manter os inventários atualizados | Regulamento, Artigo 8º |
| Acompanhamento da biblioteca | Acompanhar as bibliotecas de terceiros e de código aberto utilizadas por serviços que suportam funções críticas ou importantes e monitorar suas versões e atualizações, junto ao provedor, quando for o caso | RTS 2024/1774, Artigo 10 |
| Testes de pré-produção | Analisar e testar o código-fonte aberto, sempre que possível, antes que ele chegue à produção, e realizar testes de segurança em pacotes de software, o mais tardar na fase de integração | RTS 2024/1774, Artigo 16 |
| Código malicioso | Implemente medidas de segurança contra códigos maliciosos e certifique-se de que apenas softwares autorizados sejam instalados | RTS 2024/1774, Artigo 11 |
| Políticas de atualização | Mantenha políticas documentadas para patches e atualizações, com prazos e procedimentos de escalonamento caso esses prazos não sejam cumpridos | Regulamento, Artigo 9; RTS 2024/1774, Artigo 10 |
| Sistemas legados | Realizar uma avaliação de riscos específica dos sistemas de TIC legados pelo menos uma vez por ano | Regulamento, artigos 3º e 8º |
De acordo com o Regulamento: o Artigo 25, parágrafo 1, cita as “análises de código aberto” como um exemplo de testes adequados no programa de testes de resiliência de uma entidade financeira, juntamente com varreduras de vulnerabilidades, revisões de código-fonte, quando viável, e testes de penetração.
No caso de componentes prontos para uso empregados em serviços que não suportam funções críticas ou importantes, o Artigo 10 da RTS 2024/1774 ainda exige que você acompanhe as bibliotecas de terceiros e de código aberto utilizadas por eles, na medida do possível.
O Regulamento define um sistema de TIC legado como aquele que ainda está em uso e dá suporte às funções da entidade, mas que atingiu o fim de vida útil, não é adequado para atualizações ou correções por motivos tecnológicos ou comerciais, ou não conta mais com suporte do fornecedor ou de um prestador de serviços de TIC terceirizado. Essa definição abrange sistemas de TIC como um todo. Cada entidade deve decidir e registrar se uma biblioteca sem suporte torna o sistema que a executa um sistema legado. As microempresas — ou seja, entidades financeiras de menor porte, com menos de 10 funcionários e um faturamento ou balanço patrimonial total de até 2 milhões de euros — estão isentas da revisão anual de sistemas legados.
O fato de uma biblioteca constar no cadastro depende da forma como ela chega até você
Toda biblioteca executada em seus sistemas é considerada software utilizado pela entidade; portanto, as regras de gestão de riscos se aplicam a ela. A aplicabilidade das regras relativas a terceiros e do registro depende do fato de a biblioteca chegar até você por meio de um serviço de TIC.
O que se considera um serviço de TIC é uma decisão da própria entidade. A Pergunta e Resposta nº 2999, uma resposta da Comissão Europeia publicada por meio das ESAs, define o conceito de forma intencionalmente ampla e deixa a avaliação a cargo da entidade financeira. Para uma biblioteca, isso significa que cabe a você decidir se um acordo de suporte ou distribuição se enquadra como um serviço de TIC e deve constar no registro.
| Como a biblioteca chega | ativo de TIC | No registro de informações | Base |
|---|---|---|---|
| Download do registro público, sem acordo de suporte | Sim, como software, a entidade utiliza | Normalmente não, já que não existe nenhum contrato para um serviço contínuo | Regulamento, artigos 3º e 28º; perguntas frequentes do pessoal (orientações) |
| Acordo de distribuição comercial ou de suporte | Sim | Sim, se a entidade o considerar um serviço de TIC contínuo | Regulamento, artigos 3 e 28; Perguntas e Respostas 2999 (orientações) |
| Incorporado ao produto ou serviço hospedado de um fornecedor | Sim, desde que seja executado na rede e nos sistemas de informação utilizados pela entidade financeira | A estrutura do fornecedor, além dos subcontratados que, na prática, sustentam os serviços que dão suporte a funções críticas ou importantes | Regulamento, artigos 28 e 29; Regulamento de Execução 2024/2956, artigo 3 |
Quando uma biblioteca é incorporada ao produto ou serviço hospedado de um fornecedor, o fornecedor que a distribui geralmente se enquadra na definição de uma empresa prestadora de serviços de TIC, ao passo que o mantenedor da biblioteca raramente se enquadra nessa definição. As regras contratuais, portanto, se aplicam ao fornecedor, mas uma biblioteca que é executada nos sistemas que você utiliza permanece sujeita às suas regras de gestão de riscos.
Uma breve lista de verificação para as bibliotecas em suas funções essenciais
Cada item desta lista de verificação de conformidade com a DORA cita o texto normativo em que se baseia e pressupõe que você esteja sujeito a todo o quadro normativo.
- Inventário. Seu inventário abrange os softwares que suportam funções críticas ou importantes e a forma como eles se interconectam (Regulamento, Artigo 8).
- Acompanhamento. Você deve acompanhar as bibliotecas de terceiros e de código aberto utilizadas pelos serviços que oferecem essas funções, bem como monitorar suas versões e atualizações, em conjunto com o provedor, quando for o caso (RTS 2024/1774, Artigo 10).
- Testes. O código-fonte aberto é analisado e testado antes da entrada em produção, sempre que possível, e os pacotes de software são submetidos a testes de segurança, o mais tardar na fase de integração (RTS 2024/1774, Artigo 16).
- Código malicioso. Seus procedimentos de segurança incluem medidas contra código malicioso e permitem que apenas softwares autorizados sejam instalados em seus sistemas (RTS 2024/1774, Artigo 11).
- Aplicação de patches. Uma política documentada de patches e atualizações estabelece prazos e etapas de escalonamento (Regulamento, Artigo 9; RTS 2024/1774, Artigo 10). Quando a única solução é uma versão mais recente, a atualização pode trazer alterações que causam incompatibilidades, conforme explicamos no artigo sobre por que “basta atualizar” é um conselho de segurança inadequado.
- Sistemas legados. Os sistemas de TIC legados devem passar por uma avaliação de risco específica pelo menos uma vez por ano, a menos que se trate de uma microempresa (Regulamento, Artigo 8).
- Registro. Seu registro de informações lista todos os acordos contratuais relativos a serviços de TIC, incluindo contratos de software que se enquadram como serviços contínuos, e você pode explicar por que uma determinada biblioteca não consta nele (Regulamento, Artigo 28).
- Funções. O órgão de gestão define funções claras para as áreas relacionadas às TIC e a forma como elas se coordenam (Regulamento, Artigo 5). A menos que se trate de uma microempresa, uma função de controle gerencia e supervisiona os riscos de TIC, incluindo os riscos relacionados à biblioteca (Regulamento, Artigo 6). As regras não especificam qual equipe é responsável pelo acompanhamento da biblioteca; portanto, decida se essa tarefa ficará a cargo da equipe de riscos de TIC ou da equipe de riscos de terceiros.
Comece com uma função essencial
Seu registro não exibirá as bibliotecas que você baixou sem um contrato; portanto, procure-as em seus próprios sistemas. Escolha uma função crítica ou importante e liste as bibliotecas relacionadas a ela, incluindo aquelas incorporadas indiretamente. Marque qualquer biblioteca que não tenha um mantenedor ativo no upstream ou que não tenha uma correção no upstream para a sua versão. Em seguida, escolha um caminho para cada uma delas: seja substituí-la, atualizar para uma versão corrigida, se houver, ou aplicar um patch na versão que você utiliza. Uma função é suficiente para produzir uma lista concreta de resultados e uma maneira de avaliar o restante do seu software.
Se você optar pela rota das correções, o SecureChain é uma opção a ser considerada. Ele verifica o código-fonte de cada pacote de código aberto em busca de malware conhecido e padrões de código suspeitos antes que o pacote chegue até você e, em seguida, recompila o pacote a partir desse mesmo código-fonte. Ele corrige CVEs recém-publicados nesses pacotes, de acordo com o SLA. Cada pacote vem com um SBOM para seu inventário e dados VEX indicando quais CVEs afetam sua versão. Sua proveniência SLSA Nível 3 comprova que ele foi recompilado a partir do código-fonte verificado. Quando os mantenedores upstream param de disponibilizar correções de segurança, o Endless Lifecycle Support (ELS) assume automaticamente a manutenção desses pacotes. O SecureChain e o ELS estão disponíveis para os ecossistemas JavaScript, Python, Java, Go e PHP.
Perguntas frequentes
O que é a conformidade com a DORA?
A conformidade com a DORA significa que uma entidade financeira cumpre a Lei de Resiliência Operacional Digital (DORA) da UE, o Regulamento (UE) 2022/2554 e suas normas técnicas. O objetivo é manter os serviços em funcionamento mesmo em caso de interrupções tecnológicas. As regras estão em vigor desde 17 de janeiro de 2025.
Quais são os requisitos de conformidade da DORA?
A DORA, a Lei de Resiliência Operacional Digital da União Europeia, abrange cinco áreas. São elas: gestão de riscos em tecnologias da informação e comunicação (TIC), notificação de incidentes graves de TIC, testes de resiliência, gestão de riscos de terceiros em TIC e compartilhamento de informações sobre ameaças cibernéticas. As normas técnicas fornecem detalhes sobre muitas dessas áreas.
Quem deve cumprir os requisitos de conformidade da DORA?
A Lei de Resiliência Operacional Digital (DORA) abrange vinte categorias de entidades financeiras, incluindo instituições de crédito, instituições de pagamento, empresas de investimento, seguradoras e plataformas de negociação. Algumas entidades estão excluídas, e certas entidades de pequeno porte seguem um quadro simplificado de gestão de riscos. Os prestadores de serviços de tecnologia estão sujeitos à supervisão direta apenas se forem designados como críticos.
As bibliotecas de código aberto constam no Registro de Informações da DORA?
O registro de informações da Lei de Resiliência Operacional Digital (DORA) lista contratos de serviços de tecnologia da informação e comunicação (TIC) prestados de forma contínua. Uma biblioteca, por se tratar de um órgão público, geralmente não possui esse tipo de contrato e, portanto, não consta na lista. O suporte pago pode mudar essa situação. De qualquer forma, as regras de gestão de riscos continuam se aplicando à biblioteca, na medida em que o software é utilizado pela entidade.
A DORA menciona o software de código aberto?
Sim. Uma norma técnica prevista na Lei de Resiliência Operacional Digital (DORA), o Regulamento Delegado (UE) 2024/1774 da Comissão, exige que as entidades financeiras monitorem as bibliotecas de código aberto utilizadas pelos serviços de tecnologia da informação e comunicação (TIC) que dão suporte a funções críticas ou importantes. Além disso, exige que o código aberto seja testado antes da entrada em produção, sempre que viável.
Quais são as penalidades por descumprimento da DORA?
A Lei de Resiliência Operacional Digital (DORA) deixa a definição dos níveis de penalidades para as entidades financeiras a cargo de cada Estado-Membro, que deve garantir que elas sejam eficazes, proporcionais e dissuasivas. As autoridades competentes podem ordenar que uma entidade ponha fim a uma violação e adote medidas corretivas, além de publicarem as decisões finais sobre as penalidades. Os provedores de tecnologia crítica estão sujeitos a uma penalidade separada em nível da UE de até 1% de seu faturamento médio diário mundial, cobrada diariamente por um período de até seis meses.
Quem é responsável pelo risco de dependência nos termos da DORA?
A Lei de Resiliência Operacional Digital (DORA) exige que todas as entidades financeiras, com exceção das microempresas, atribuam a uma função de controle a responsabilidade de gerenciar e supervisionar os riscos relacionados às tecnologias da informação e comunicação (TIC). A lei não especifica qual equipe é responsável pelo acompanhamento das bibliotecas. Esse papel é definido pelo órgão de gestão; portanto, cada entidade decide se essa função será desempenhada pela equipe de riscos de TIC ou pela equipe de riscos de terceiros.
