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 Artigo 13, parágrafo 5, da Lei de Resiliência Cibernética (CRA) exige a devida diligência em relação a componentes de terceiros, incluindo os de código aberto.
- A violação do Artigo 13º pode acarretar multas de até 15 milhões de euros ou 2,5% do faturamento anual global, o que for maior.
- O Considerando 34, de caráter não vinculativo, vincula a devida diligência ao risco associado aos componentes e enumera quatro ações possíveis; no entanto, cabe a você escolher e documentar o método a ser utilizado.
- De acordo com as orientações da Comissão Europeia, ao integrar um componente de código aberto, você não assume a responsabilidade pela conformidade desse componente com a CRA. A conformidade do seu produto continua abrangendo o componente, incluindo o tratamento de suas vulnerabilidades durante o período de suporte, mesmo depois que o desenvolvedor original deixar de corrigi-las.
- As ações do Recital 34 não verificam se um pacote foi compilado a partir do código-fonte publicado ou se contém código injetado; portanto, cabe à sua própria avaliação de risco determinar até que ponto verificar ambos os aspectos.
Se o seu produto incluir componentes de código aberto, a Lei de Resiliência Cibernética (CRA) exige que você exerça a devida diligência em relação a eles a partir de 11 de dezembro de 2027. As orientações não vinculativas da Comissão Europeia acrescentam que os mantenedores que não comercializam seus componentes de código aberto não têm nenhuma obrigação para com você nos termos da CRA. O Artigo 13(5) estende seu dever de devida diligência até mesmo a esses componentes; portanto, uma biblioteca que não seja monetizada pelo seu mantenedor ainda é considerada.
Qual é o nível adequado de diligência? A CRA deixa essa questão em aberto, e o Considerando 34 adapta o nível ao risco do componente e lista exemplos de ações, sem exigir que nenhuma delas seja realizada. Nenhuma dessas ações verifica se o pacote no qual seu produto é executado foi compilado a partir do código-fonte publicado ou se contém código que não deveria estar presente. A decisão é sua, e o descumprimento pode acarretar multas administrativas (Artigo 64, parágrafo 2).
O que a Lei de Resiliência Cibernética diz sobre componentes que você não desenvolveu
A Lei de Resiliência Cibernética da UE, Regulamento (UE) 2024/2847, atribui aos fabricantes o dever de diligência devida. Um produto com elementos digitais é um produto de software ou hardware, incluindo componentes de software ou hardware colocados no mercado separadamente (artigo 3º, parágrafo 1º). O artigo 3º, parágrafo 13º, define fabricante como uma pessoa física ou jurídica que desenvolve ou fabrica tais produtos, ou que os manda projetar, desenvolver ou fabricar, e os comercializa sob seu nome ou marca registrada. A definição se aplica independentemente de o produto ser vendido, monetizado ou doado.
Um componente é um software ou hardware destinado à integração em um sistema eletrônico de informação (Artigo 3º, parágrafo 6º); portanto, uma biblioteca de código aberto na qual seu produto se baseia geralmente se enquadra nessa definição. De acordo com o Artigo 2º, parágrafo 1º, a CRA abrange produtos disponibilizados no mercado cuja finalidade prevista ou uso razoavelmente previsível inclua uma conexão de dados com um dispositivo ou rede.
O Artigo 3º, parágrafo 22, define “colocação à disposição no mercado” como o fornecimento para distribuição ou uso no mercado da UE no âmbito de uma atividade comercial, seja a título oneroso ou gratuito. O fornecimento gratuito de algo ainda pode ser considerado comercial. No caso do código aberto, o que importa é se o editor o monetiza, por exemplo, cobrando por ele, condicionando o acesso a versões ou atualizações ao pagamento ou utilizando-o para vender outros serviços (Considerando 18; orientações da Comissão, seção 3.2). Uma biblioteca que seu mantenedor disponibiliza fora do âmbito de uma atividade comercial não é considerada um produto, mas ainda assim é um componente do seu.
O Artigo 13, parágrafo 5, exige que os fabricantes ajam com a devida diligência ao integrar componentes fornecidos por terceiros, de modo que tais componentes não comprometam a segurança cibernética do produto. Isso inclui expressamente componentes de código aberto e de uso livre que não tenham sido disponibilizados no mercado no âmbito de atividades comerciais. O Artigo 13 entra em vigor a partir de 11 de dezembro de 2027 (Artigo 71, parágrafo 2).
A violação do Artigo 13 pode acarretar multas administrativas de até 15.000.000 de euros ou, no caso de uma empresa (termo utilizado na UE para designar uma pessoa jurídica), até 2,5% de seu faturamento anual total mundial no exercício financeiro anterior, o que for maior (Artigo 64, parágrafo 2).
A indenização por danos decorrentes de produtos defeituosos está sujeita a um regime específico, a Diretiva (UE) 2024/2853, conhecida como Diretiva sobre Responsabilidade pelo Produto. O considerando 31 a define como complementar à CRA e afirma que a falta de atualizações de segurança que cause danos pode acionar a responsabilidade do fabricante nos termos dessa diretiva.
O que a due diligence identifica e o que não identifica
A Lei de Resiliência Cibernética (CRA) exige que os fabricantes exerçam a devida diligência, e é no Considerando 34, de caráter não vinculativo, que o texto se torna mais específico. Ele afirma que o nível adequado depende da natureza e do grau de risco à segurança cibernética associado a um componente, e que a devida diligência deve levar em conta uma ou mais das quatro ações listadas (Tabela 1). As Perguntas Frequentes da Comissão sobre a CRA, um documento de perguntas e respostas distinto de suas orientações, acrescenta outros exemplos.
Tabela 1. Ações mencionadas pelas fontes para a devida diligência em relação a um componente
| Ação | Fonte | Base |
|---|---|---|
| Quando for o caso, verifique se o fabricante do componente comprovou a conformidade com a CRA, por exemplo, por meio da marcação CE | Considerando 34 | Recital (interpretativo) |
| Verifique se o componente recebe atualizações de segurança regularmente, por exemplo, por meio de seu histórico de atualizações | Considerando 34 | Recital (interpretativo) |
| Verifique se o componente não apresenta vulnerabilidades registradas no banco de dados europeu de vulnerabilidades ou em outros bancos de dados públicos de vulnerabilidades | Considerando 34 | Recital (interpretativo) |
| Realizar testes de segurança adicionais | Considerando 34 | Recital (interpretativo) |
| Executar uma análise da composição do software, isolar componentes altamente críticos, revisar a lista de materiais de software (SBOM) do componente, quando disponível, verificar seu período de suporte, confirmar se a finalidade pretendida está de acordo com o uso indicado pelo fabricante ou avaliar a postura de segurança do fabricante | Perguntas Frequentes da Comissão, resposta 4.4.2 (versão 1.4, 4 de setembro de 2026) | Perguntas frequentes sobre a Comissão (sem caráter oficial) |
Observação: A seção de perguntas frequentes da Comissão afirma que suas respostas não acrescentam nenhum requisito e que suas opiniões não têm caráter oficial.
O considerando 34 diz “uma ou mais”, portanto não considera nenhuma ação isolada como obrigatória. Nem ele nem o artigo 13, parágrafo 5, determinam um método, uma profundidade ou um formato de registro.
O Anexo VII enumera o que a documentação técnica deve conter. Ele inclui a avaliação de riscos, a descrição de como os componentes de software se integram ao sistema como um todo e os relatórios de teste, mas não possui um item específico para a devida diligência dos componentes. Isso não significa que a devida diligência não seja registrada. O Artigo 13, parágrafo 7, ainda exige que os fabricantes documentem sistematicamente os aspectos relevantes de segurança cibernética do produto, de forma proporcional à sua natureza e aos riscos de segurança cibernética.
Com o nível definido pelo risco e o método deixado em aberto, é o seu próprio raciocínio que determina o grau de diligência que cada componente recebe. As orientações da Comissão (pontos 170 e 171) dividem essa obrigação em duas etapas: utilize a avaliação de risco do seu produto para identificar o que o produto necessita de cada componente e, em seguida, verifique se o componente atende a essa necessidade. Uma anotação dessa verificação, redigida no momento da incorporação do componente, é mais confiável do que uma reconstruída anos depois, pois o Artigo 13, parágrafo 5, vincula a obrigação à integração.
O que fica na memória e o que não fica
As orientações da Comissão de 27 de julho de 2026 estabelecem que os fabricantes que integram componentes de código aberto não são responsáveis pela conformidade individual desses componentes com a CRA, mesmo quando contribuem com código-fonte para sua manutenção (ponto 86). Eles mantêm suas próprias obrigações em relação ao produto, incluindo a devida diligência prevista no Artigo 13(5), bem como a notificação de vulnerabilidades e o compartilhamento de correções, conforme previsto no Artigo 13(6) (ponto 88).
Os administradores e mantenedores a montante têm obrigações de CRA muito mais leves do que os fabricantes. O Artigo 3(14) define um administrador de software de código aberto como uma pessoa jurídica, que não seja um fabricante, cujo objetivo seja apoiar sistematicamente, de forma sustentável, o desenvolvimento de produtos específicos livres e de código aberto destinados a atividades comerciais, e que garanta sua viabilidade. O artigo 24º estabelece um regime menos rigoroso para os administradores: uma política documentada de segurança cibernética, cooperação com as autoridades de fiscalização de mercado e, em casos limitados, o cumprimento de partes do artigo 14º relativas à notificação de vulnerabilidades exploradas e incidentes (artigo 24º, parágrafo 3º). As orientações acrescentam que os mantenedores de componentes que não tenham sido disponibilizados no mercado não têm obrigações perante os fabricantes que os integram (ponto 87).
Suas obrigações não se limitam à integração. O Artigo 13(6) exige que você comunique uma vulnerabilidade identificada em um componente ao fabricante ou responsável pela manutenção do mesmo, para que seja corrigida, e que compartilhe o código ou a documentação relevante caso tenha desenvolvido uma correção. O Artigo 13(8) exige que as vulnerabilidades no produto, incluindo seus componentes, sejam tratadas de forma eficaz durante todo o período de suporte definido por você. Esse período deve ser de pelo menos 5 anos, a menos que se preveja que o produto permaneça em uso por menos de 5 anos. De acordo com a CRA, nem os administradores (artigo 24) nem os mantenedores de componentes que não tenham sido disponibilizados no mercado (ponto 87) têm a obrigação de garantir um período de suporte a você; portanto, uma versão de componente pode deixar de receber correções do upstream mesmo que o período de suporte do seu produto ainda tenha anos pela frente.
As ações listadas não perguntam como um pacote foi compilado
Três das quatro ações mencionadas no Considerando 34 analisam o histórico publicado de um componente. Elas verificam se o fabricante demonstrou conformidade, se o componente recebe atualizações de segurança regulares e o que os bancos de dados de vulnerabilidades indicam a respeito dele. A quarta ação, que consiste em testes de segurança adicionais, é a única que exige que você mesmo teste o componente.
O registro de um componente descreve como um projeto se comporta, mas não indica se o pacote que seu produto acaba executando foi compilado a partir do código-fonte publicado pelo projeto, nem se contém código que não deveria estar presente. A proveniência da compilação e o código injetado não aparecem em nenhuma das ações mencionadas no Considerando 34 nem nos exemplos das Perguntas Frequentes da Comissão. No entanto, ambos afetam diretamente se um componente compromete a segurança cibernética do produto — o resultado que o Artigo 13(5) visa impedir.
O Artigo 13, parágrafo 5, não especifica o método a ser utilizado; portanto, cabe a você decidir como verificar a proveniência e procurar por código injetado. Verificar um pacote em relação ao seu código-fonte e analisá-lo em busca de código malicioso antes que ele entre no seu ambiente são duas opções. Uma SBOM lista o que um produto contém, mas listar um pacote não verifica como ele foi compilado nem qual código ele contém. Sua avaliação de risco deve indicar o nível de verificação necessário para cada componente.
Verificação de pacotes antes que eles cheguem ao seu ambiente
O SecureChain da TuxCare analisa o código-fonte dos pacotes de código aberto que abrange em busca de malware conhecido, padrões de código suspeitos e outros riscos à cadeia de suprimentos; em seguida, recompila os pacotes a partir desse código-fonte analisado em ambientes de compilação isolados e reforçados. Os pacotes que não passam na análise são bloqueados antes de chegarem ao seu ambiente. Cada pacote vem acompanhado de um SBOM, um documento VEX e uma proveniência SLSA Nível 3, um registro da fonte e da compilação que o produziram.
Para componentes que ainda recebem manutenção ativa, a SecureChain fornece correções em pacotes recompilados, sob um acordo de nível de serviço, à medida que novas vulnerabilidades são identificadas. Quando a manutenção do desenvolvedor original é encerrada, o Suporte de Ciclo de Vida Ilimitado da TuxCare continua a corrigir vulnerabilidades em todos os níveis de gravidade, de crítico a baixo, nas versões específicas que você utiliza.
Não consegue confirmar o que há dentro dos pacotes que você envia? Veja como o SecureChain os verifica antes que eles cheguem às suas compilações.
Perguntas frequentes
Quem é afetado pela Lei de Resiliência Cibernética?
A Lei de Resiliência Cibernética (CRA), regulamentação da UE sobre segurança cibernética de produtos, abrange produtos com elementos digitais que são disponibilizados no mercado da UE no âmbito de uma atividade comercial e cuja finalidade prevista ou uso razoavelmente previsível inclua uma conexão de dados a um dispositivo ou rede (Artigos 2(1) e 3(22)). As obrigações recaem principalmente sobre os fabricantes. Importadores, distribuidores e administradores de software de código aberto têm obrigações específicas (artigos 19, 20 e 24).
Quando se aplicam as disposições da Lei de Resiliência Cibernética?
A Lei de Resiliência Cibernética (CRA) entrou em vigor em 10 de dezembro de 2024. O Capítulo IV, relativo à notificação dos organismos de avaliação da conformidade, está em vigor desde 11 de junho de 2026, e o Artigo 14, relativo aos relatórios dos fabricantes, desde 11 de setembro de 2026. O restante entra em vigor a partir de 11 de dezembro de 2027 (Artigo 71, parágrafo 2).
A CRA substitui as regras de responsabilidade civil pelo produto?
Não. O considerando 31 da Lei de Resiliência Cibernética (CRA) considera a Diretiva (UE) 2024/2853, a Diretiva sobre Responsabilidade pelo Produto, como complementar. Essa diretiva abrange a indenização por danos causados por produtos defeituosos, enquanto a CRA estabelece os deveres dos fabricantes, respaldados por multas administrativas (artigo 64). O artigo 65 aplica as regras da UE sobre ações representativas às infrações que prejudiquem ou possam prejudicar os interesses coletivos dos consumidores.
Os fabricantes podem utilizar software de código aberto de mantenedores aos quais a CRA não se aplica?
Sim, desde que o fabricante tome as devidas precauções para que esses componentes não comprometam a segurança cibernética do produto. O Artigo 13(5) da Lei de Resiliência Cibernética (CRA) abrange expressamente os componentes de código aberto que não foram disponibilizados comercialmente no mercado, e o Considerando 34 estabelece que o nível depende do risco do componente.
Os fabricantes são obrigados a comunicar vulnerabilidades de componentes ao responsável pela manutenção?
Sim, assim que identificarem uma. A partir de 11 de dezembro de 2027, o Artigo 13(6) da Lei de Resiliência Cibernética (CRA) exige que um fabricante comunique uma vulnerabilidade em um componente integrado — incluindo aqueles de código aberto — ao fabricante ou responsável pela manutenção do mesmo, e que a corrija. Se o fabricante desenvolver uma correção, deverá compartilhar o código ou a documentação relevante. Isso é distinto da notificação às autoridades prevista no artigo 14, que está em vigor desde 11 de setembro de 2026.
