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
- Desde 11 de setembro de 2026, o Artigo 14 da CRA exige que você notifique, no prazo de 24 horas após tomar conhecimento da existência de uma vulnerabilidade que esteja sendo explorada ativamente em seu produto.
- Uma SBOM de nível superior, ou seja, o mínimo exigido pelo Anexo I, não identificará um pacote localizado vários níveis abaixo; já um inventário no nível da versão de cada compilação enviada o fará.
- Uma adaptação compatível da versão que você já utiliza corrige uma dependência oculta sem alterar tudo o que está acima dela.
- O período de suporte do CRA é mais longo do que o de manutenção do upstream; portanto, cada versão do pacote precisa de um plano de correções que se estenda além do fim da vida útil definida pelo upstream.
Uma nova entrada aparece no catálogo KEV da CISA numa terça-feira. Ela identifica uma vulnerabilidade que está sendo ativamente explorada em um pacote que ninguém da sua equipe escolheu, localizado três níveis abaixo em uma árvore de dependências que ninguém montou intencionalmente. Em até 24 horas, alguém da sua empresa deve determinar se esse pacote está incluído em uma versão que vocês lançaram e se é necessário informar a CSIRT e a ENISA.
Veja como é o Artigo 14 da Lei de Resiliência Cibernética da UE (CRA) por dentro. Os prazos são curtos, e o critério de acionamento é mais restrito do que a maioria dos resumos sugere, mas o que causa problemas raramente é a própria notificação. O desafio está em determinar o que realmente está na versão, enquanto o tempo vai passando.
O relógio de 24 horas da CRA está correndo
Desde 11 de setembro de 2026, o Artigo 14 da CRA está em vigor. Trata-se da primeira exigência de notificação da CRA imposta aos fabricantes, e o prazo é estritamente limitado. Assim que você tomar conhecimento de que uma vulnerabilidade em seu produto está sendo ativamente explorada, você tem 24 horas.
A CRA utiliza o termo “fabricante” para se referir a uma organização ou pessoa que desenvolve um produto com elementos digitais, ou que o manda desenvolver, e o coloca no mercado da UE sob seu próprio nome ou marca registrada no âmbito de uma atividade comercial. Atividade comercial não significa apenas cobrar um preço. O suporte pago é considerado como tal quando vai além da recuperação dos custos reais. O mesmo se aplica à monetização por meio de uma plataforma ou à exigência de que os usuários forneçam dados pessoais por motivos que vão além de melhorar a segurança, a compatibilidade ou a interoperabilidade do software. Se esse for o caso da sua empresa e seu produto for distribuído como código aberto, o Artigo 14 já é um problema para você.
O Artigo 14 estabelece três prazos para a apresentação de relatórios. Cada relatório é encaminhado, por meio da Plataforma Única de Notificação da ENISA, ao CSIRT designado como coordenador — geralmente aquele correspondente ao seu estabelecimento principal — e à própria ENISA, a agência de segurança cibernética da UE.
A primeira é a notificação de alerta antecipado de 24 horas. Dentro de 72 horas, você envia uma notificação mais completa sobre a vulnerabilidade. No máximo 14 dias após a disponibilização de uma medida corretiva ou mitigadora — termo usado pela CRA para se referir a uma correção ou solução alternativa —, você envia um relatório final. Os prazos de 24 e 72 horas são limites máximos, e não períodos de espera. O texto diz “sem demora indevida e, em qualquer caso, dentro” desses prazos.
“Explorada ativamente” tem um significado preciso. Deve haver evidências confiáveis de que um agente mal-intencionado tenha explorado a vulnerabilidade em um sistema sem a permissão do proprietário do sistema. Um CVE publicado não é suficiente. Uma prova de conceito também não é suficiente. O artigo 14 também abrange incidentes graves que afetam a segurança de um produto. Esses são tratados em um processo separado, com um relatório final a ser apresentado um mês após a notificação do incidente. Este artigo trata de vulnerabilidades e da questão das dependências de código aberto no âmbito da CRA. A avaliação de riscos, a avaliação de conformidade e as demais obrigações do fabricante estão fora de seu escopo.
O prazo para o cumprimento das obrigações restantes dos fabricantes, bem como para o pagamento de multas, previsto na CRA, é 11 de dezembro de 2027. O Artigo 14 já está em vigor e abrange os produtos colocados no mercado da UE antes dessa data.
Fonte: Artigo 14, incisos 1, 2, 4 e 7; Artigo 3, incisos 13 e 42; Artigo 64; Artigo 71, inciso 2; Artigo 69, inciso 3; considerandos 15 e 18.
Por que uma SBOM de nível superior não pode indicar se você foi afetado
As evidências de que uma vulnerabilidade está sendo explorada geralmente chegam a você de fora: uma entrada no catálogo de Vulnerabilidades Exploradas Conhecidas (KEV) da CISA, um comunicado de um fornecedor ou mantenedor, ou uma mensagem de uma CSIRT, de um pesquisador ou de um cliente. A partir daí, três coisas acontecem. Você fica sabendo que uma vulnerabilidade está sendo explorada em algum lugar. Você verifica se o seu produto está afetado. Em seguida, identifica quais versões e quais usuários estão afetados.
O prazo começa a contar quando você toma conhecimento de uma vulnerabilidade que está sendo explorada ativamente em seu produto; portanto, comece a avaliar alertas confiáveis imediatamente. O fato de o nome do pacote corresponder não significa, por si só, que seu produto esteja afetado, e é um inventário preciso que permite esclarecer isso rapidamente. Na prática, as etapas se sobrepõem, e você não precisa esperar por uma lista completa de usuários antes de enviar um alerta antecipado à medida que o prazo se aproxima.
O pacote mencionado no alerta costuma ser uma dependência transitiva, incluída por uma de suas dependências diretas e que não foi escolhida por ninguém da sua equipe. Log4Shell (CVE-2021-44228) é o caso mais comum. log4j-core estava presente em muitas aplicações como uma dependência de frameworks e conectores, e a primeira tarefa da maioria das equipes era verificar se, de fato, já o possuíam.
É aqui que entra a exigência de inventário da CRA. O Anexo I exige que os fabricantes identifiquem e documentem os componentes de um produto, inclusive por meio da elaboração de uma lista de materiais de software (SBOM) em um formato comumente utilizado e legível por máquina. O nível mínimo de detalhamento é “no mínimo, as dependências de nível superior”. Esse limite mínimo é razoável. No entanto, também não é suficiente para a questão do prazo de 24 horas.
Uma SBOM de nível superior registra diretamente o que você adicionou. A questão que se coloca é se uma versão específica de um pacote específico aparece em algum lugar do produto, e há três locais onde se deve procurar.
Seu manifesto, seja ele package.json, pom.xml, ou requirements.txt, lista as dependências que você declarou, geralmente como intervalos de versão. Seu arquivo de bloqueio registra o gráfico de dependências resolvidas para uma compilação; no entanto, o que é finalmente distribuído ainda pode variar devido a dependências específicas da plataforma e opcionais, ferramentas de compilação, uso de vendoring e qualquer regeneração do arquivo de bloqueio ao longo do processo. Seu inventário de lançamento mostra o que o artefato distribuído contém: versões de componentes resolvidas, tudo o que foi empacotado ou incorporado ao artefato por meio de vendoring, e nenhuma das dependências de desenvolvimento que nunca saem da sua compilação.
O arquivo de bloqueio é uma informação essencial, mas não comprova o que foi lançado. Para determinar se a vulnerabilidade relatada está presente em uma versão específica, é necessário consultar o inventário de versões.
Há mais um problema para qualquer coisa que já tenha ultrapassado o fim do ciclo de vida do projeto original. Quando uma vulnerabilidade é corrigida, o comunicado geralmente diz algo como “corrigido na versão 4.2; ramos mais antigos não têm mais suporte”. A versão 3.x na sua árvore de código pode muito bem estar afetada, mas o projeto original talvez nunca mencione isso, pois ninguém lá está mais acompanhando esse ramo. A análise fica a seu cargo.
Fonte: Artigo 14, parágrafo 1; Artigo 3, parágrafo 42; Anexo I, Parte II, parágrafo 1.
Por que “nós não sabíamos” não serve de desculpa
O prazo previsto no Artigo 14 só começa a correr quando você toma conhecimento de uma vulnerabilidade ativamente explorada presente em seu produto. Trata-se de um limite restrito a um único fator desencadeador e não contribui de forma alguma para abordar o restante da CRA.
A partir de 11 de dezembro de 2027, passam a vigorar as obrigações mais amplas da CRA. Para produtos colocados no mercado antes dessa data, as regras de transição passam a se aplicar quando o produto sofrer uma modificação substancial nessa data ou após ela. Essas obrigações exigem que você identifique e documente os componentes e as vulnerabilidades do seu produto, além de realizar testes e análises de segurança eficazes e regulares. É necessário aplicar a devida diligência ao incorporar componentes de terceiros, incluindo aqueles de código aberto. E é necessário que você lide com as vulnerabilidades do produto, “incluindo seus componentes”, de forma eficaz durante todo o período de suporte.
O fato de um componente ter sido omitido em suas ferramentas não prova, por si só, que seu processo seja inadequado. Isso pode muito bem levar uma autoridade a avaliar se a identificação de componentes e o tratamento de vulnerabilidades são adequados. Essas obrigações se enquadram na faixa de multas mais alta da CRA, que pode chegar a 15 milhões de euros ou 2,5% do faturamento anual global total da sua empresa no exercício financeiro anterior, o que for maior. As autoridades de fiscalização de mercado também podem determinar medidas corretivas, restringir ou proibir vendas, ou exigir a retirada do mercado ou o recall.
A data de entrada em vigor ainda está um pouco distante. O próximo alerta, porém, não. Se sua ferramenta não detectou um pacote, as primeiras horas de uma janela de 24 horas são gastas tentando determinar se esse pacote está, de fato, na sua pilha, o que deixa muito menos tempo para todas as outras informações necessárias ao relatório.
Fonte: Anexo I, Parte II, alíneas (1) e (3); Artigo 13, alíneas (5) e (8); Artigo 54; Artigo 64, alínea (2); Artigo 69, alínea (2).
Agora conserte isso sem estragar tudo o que está acima
A notificação de 72 horas solicita o que você sabe até o momento: informações gerais sobre o produto, a natureza geral da exploração e da vulnerabilidade, quaisquer medidas corretivas ou de mitigação que você tenha tomado e as medidas que seus usuários podem adotar. Não é necessário ter um patch pronto para enviá-la. No entanto, no caso de uma dependência transitiva três níveis abaixo, ainda é necessário dedicar esforços para definir essas medidas.
Considere a situação comum. A correção já existe no upstream, na versão 4.2. O pacote intermediário em sua árvore está parado na linha 3.x, e seu mantenedor ainda não o atualizou. Nenhuma de suas opções é gratuita. Você pode esperar pelo mantenedor. Você pode forçar uma substituição no seu arquivo de bloqueio e aceitar o risco de que algo acima dele deixe de funcionar. Você pode atualizar o pacote intermediário para uma versão principal que ofereça suporte à 4.2 e incluir quaisquer alterações não relacionadas que venham com ela como parte de uma versão de segurança. Você pode substituir o componente ou aplicar um patch nele por conta própria. Ou você pode obter um backport compatível, que é a correção de segurança aplicada ao ramo 3.x que você já utiliza.
A partir de dezembro de 2027, o Anexo I estabelece duas exigências nesse sentido. É necessário identificar e corrigir vulnerabilidades sem demora. E, quando tecnicamente viável, as atualizações de segurança devem ser distribuídas separadamente das atualizações de recursos. A CRA não determina qual caminho você deve seguir. Ela também permite que você forneça a atualização de segurança apenas para a sua versão mais recente, desde que os usuários de versões anteriores possam migrar para ela gratuitamente e não tenham custos adicionais para adaptar seu ambiente.
Um backport compatível se adapta a essa separação e minimiza o trabalho de migração. Trata-se de uma compilação fixa da versão que já está em sua árvore, compatível com seus dependentes, com os pacotes dependentes recompilados conforme necessário. Quando feito corretamente, seus próprios manifestos permanecem inalterados, e os testes de compatibilidade são realizados apenas uma vez em seu produto.
Quando um backport inclui uma data de entrega confirmada, você tem um cronograma concreto de correção para relatar, juntamente com as medidas que já tomou. O resto fica por sua conta: integrar o componente corrigido, testá-lo e lançá-lo como uma atualização do seu produto. Quanto mais cedo o componente chegar, maior será o tempo disponível para isso.
Fonte: Artigo 14, parágrafo 2, alínea b); Anexo I, Parte II, item 2; Artigo 13, parágrafo 10; Artigo 69, parágrafo 2.
O relatório final é apresentado após a correção, e a obrigação se estende por anos
O relatório final deve ser entregue no prazo máximo de 14 dias após a disponibilização de uma medida corretiva ou mitigadora. Ele descreve a vulnerabilidade, sua gravidade e impacto, o que se sabe sobre o invasor e a atualização de segurança ou outras medidas que você disponibilizou.
Por outro lado, assim que você tomar conhecimento da vulnerabilidade, deverá informar os usuários afetados e, quando for o caso, todos os usuários. O aviso deve indicar o que eles podem fazer para mitigar ou corrigir o problema. Quando for o caso, ele deve ser enviado em um formato estruturado e legível por máquina. A CRA não prescreve um formato específico. O CSAF é o formato de aviso legível por máquina amplamente utilizado, e as declarações VEX — que indicam se uma vulnerabilidade afeta um produto específico — podem ser expressas como CSAF VEX, CycloneDX VEX ou OpenVEX.
A partir de dezembro de 2027, a própria atualização também deverá ser distribuída de forma segura, sem demora e gratuitamente.
Em seguida, vem a “cauda longa”, onde a lógica do código aberto deixa de funcionar a seu favor.
Enquanto durar o período de suporte, você deverá continuar a corrigir as vulnerabilidades do produto. Você mesmo define o período de suporte, mas ele deve refletir o tempo previsto de uso do produto e ser de pelo menos 5 anos, a menos que se preveja que o produto seja utilizado por menos tempo. Além disso, todas as atualizações de segurança emitidas durante o período de suporte devem permanecer disponíveis por pelo menos 10 anos após sua emissão, ou até o fim do período de suporte, o que ocorrer mais tarde, para que um usuário que atualize com atraso ainda possa obtê-las.
A manutenção de código-fonte de uma versão do pacote pode terminar bem antes do término do seu período de suporte. Quando isso ocorre, a CRA ainda exige que você cumpra o período estabelecido. Você não está obrigado a manter exatamente essa versão, já que substituir ou atualizar um componente pode ser uma solução válida. Você é obrigado a continuar corrigindo as vulnerabilidades do seu produto, por qualquer meio, durante todo o período de suporte.
Fonte: Artigo 14, parágrafos 2, alínea c), e 8; Anexo I, Parte II, itens 7 e 8; Artigo 13, parágrafos 8 e 9; Artigo 69, parágrafo 2.
Ninguém a montante compartilha seu relógio
A CRA isenta deliberadamente o software livre e de código aberto, desenvolvido ou fornecido fora do âmbito de uma atividade comercial, das obrigações do fabricante.
Cria-se uma categoria distinta, a de “responsável pelo software de código aberto”, destinada a pessoas jurídicas que prestam apoio contínuo ao desenvolvimento de software de código aberto destinado a atividades comerciais. Os responsáveis passam a se beneficiar de um regime mais flexível e personalizado, que entrará em vigor a partir de dezembro de 2027, com obrigações limitadas previstas no Artigo 14 em circunstâncias específicas. Os mantenedores individuais da comunidade não são automaticamente considerados fabricantes ou responsáveis.
Quaisquer que sejam suas obrigações e compromissos de suporte, eles são diferentes dos seus e não os anulam. O Artigo 13(6) deixa isso bem claro. Ao identificar uma vulnerabilidade em um componente que você distribui, você deve comunicá-la à pessoa ou entidade responsável pela fabricação ou manutenção desse componente, corrigi-la em seu produto, independentemente de eles responderem ou não, e compartilhar o código ou a documentação relevante caso tenha desenvolvido uma correção. Você pode aplicar um patch, substituir ou atualizar o componente. O que você não pode fazer é permitir que a inércia do fornecedor justifique o adiamento de sua própria resposta.
Essas obrigações previstas no Artigo 13 passam a vigorar a partir de 11 de dezembro de 2027. A lição operacional já se aplica agora. No caso de código localizado em camadas profundas da sua árvore de código — que você não escreveu e talvez nunca tenha lido —, a vulnerabilidade no seu produto ainda é de sua responsabilidade resolver, mesmo que o desenvolvedor original não ofereça ajuda.
Fonte: Artigo 24; Artigo 3, parágrafo 14; Artigo 13, parágrafo 6; Artigo 69, parágrafo 2; considerandos 18 e 19.
O que uma resposta viável tem a ver com isso
A CRA oferece flexibilidade para você decidir como lidar com a conformidade com o Artigo 14. A seguir, apresentamos um conjunto prático de recursos para o código-fonte aberto presente em seu produto. Eles são mais importantes nos casos em que manter a compatibilidade das versões existentes poupa trabalho de migração.
Comece com um inventário de nível de versão de tudo o que está no produto, até a última dependência transitiva, registrado como versões resolvidas e mapeado para o que cada versão do produto realmente é lançada. A questão das 24 horas passa então a ser respondida com base nos registros, em vez de uma verificação que você iniciou após o alerta ter sido emitido.
Em seguida, você precisa de correções que cheguem a tempo, incluindo backports compatíveis para as versões já presentes em sua árvore — nas quais a atualização não é viável —, com os pacotes dependentes recompilados conforme necessário. As alterações de segurança podem, então, ser distribuídas separadamente das alterações de funcionalidades, e o trabalho de migração permanece mínimo. Esse caminho de correção também deve continuar após o fim da vida útil do pacote pelo desenvolvedor original, durante todo o seu período de suporte, e não apenas enquanto houver interesse por parte do mantenedor.
Os dois últimos pontos dizem respeito ao que sai do seu ambiente. Os usuários afetados precisam ser notificados imediatamente, em formatos legíveis por máquina quando for o caso, e receber atualizações de segurança que permaneçam disponíveis por pelo menos 10 anos após a sua emissão, ou pelo restante do período de suporte, se este for mais longo. Além disso, é necessário que haja cobertura equivalente em todos os ecossistemas de idiomas do seu produto, pois o Artigo 14 não leva em conta a origem de um componente.
A maioria das demais obrigações dos fabricantes, bem como as medidas de fiscalização a elas associadas, entram em vigor a partir de 11 de dezembro de 2027. A obrigação de prestação de informações já está em vigor. Os meses que nos separam dessa data são o momento de implementar essas capacidades.
O papel do SecureChain e do Suporte ao Ciclo de Vida Ilimitado
O SecureChain e o Endless Lifecycle Support (ELS) da TuxCare são desenvolvidos com base nesses recursos, na mesma ordem.
Primeiro, o inventário. Os pacotes de código aberto entram no seu produto por meio do catálogo SecureChain, que rastreia as versões dos pacotes que mantém e publica SBOMs legíveis por máquina para eles — incluindo o CycloneDX —, com detalhes das dependências incluídos. Essa é a parte relacionada aos componentes do seu inventário de versões. Você o conecta aos seus registros de compilação e aos artefatos distribuídos e, a partir daí, determinar se o componente afetado está presente é uma simples consulta, em vez de uma busca frenética. Quando uma vulnerabilidade é confirmada, a TuxCare publica os dados da vulnerabilidade para que você possa comparar com as versões dos pacotes nesse inventário.
Em seguida, as correções. Enquanto o desenvolvedor original ainda as estiver disponibilizando, o SecureChain as recompila a partir do código-fonte e fornece substituições diretas para as versões compatíveis dos pacotes que você já executa. Quando o desenvolvedor original deixa de fornecer atualizações, o SecureChain aplica o patch diretamente no pacote e mantém sua compatibilidade. Quando uma dependência oculta recebe um patch, os pacotes dependentes são recompilados com base na correção, o que evita que seus próprios manifestos sejam afetados. A aplicação de correções segue os tempos de resposta-alvo publicados por nível de gravidade, definidos na ficha técnica de cobertura do ciclo de vida. Isso dá à sua notificação de 72 horas um cronograma concreto a ser relatado, juntamente com as medidas já tomadas e as ações de mitigação disponíveis para seus usuários. Integrar, testar e lançar a atualização como se fosse sua continua sendo sua responsabilidade.
Em seguida, vem a parte em que o desenvolvedor original deixa de oferecer suporte. Quando o desenvolvedor original deixa de corrigir uma versão — seja por não cumprir o prazo de um CVE ou por não lançar nenhuma versão por nove meses —, o SecureChain continua aplicando correções por mais três meses. Depois disso, o Suporte de Ciclo de Vida Ilimitado assume e faz o backport das correções enquanto você utilizar a versão, ou seja, pelo tempo que seu próprio período de suporte exigir.
Os alertas e atualizações são publicados por meio do portal de segurança da TuxCare na forma de documentos CSAF e VEX, com feeds RSS e metadados assinados, prontos para serem vinculados às suas próprias versões afetadas e avisos aos usuários. A TuxCare também é uma Autoridade de Numeração CVE (CNA), podendo, assim, atribuir identificadores CVE a vulnerabilidades dentro de seu próprio escopo e publicá-los em seus alertas, em vez de ficar na fila atrás de terceiros.
O modelo abrange JavaScript, Python, Java, Go, Rust e PHP. Um único catálogo, um único modelo de SBOM, um único modelo de correção, independentemente do ecossistema de origem de um pacote.
A TuxCare é, por si só, um fabricante nos termos do CRA para os produtos que coloca no mercado da UE; portanto, as mesmas obrigações do Artigo 14 se aplicam a ela, juntamente com o dever previsto no Artigo 13, parágrafo 6, de relatar vulnerabilidades de componentes aos fornecedores e compartilhar as correções. O que esses dois produtos mudam para você é o tempo que é gasto, no intervalo entre um alerta e o lançamento de uma versão corrigida, aguardando a correção de um componente de terceiros, bem como a qualidade do registro que você pode enviar enquanto o prazo está correndo.
Antes do próximo alerta
Você pode testar a maior parte disso em uma tarde. Escolha uma versão atual e um alerta, real ou hipotético. O Log4Shell serve, caso tenha afetado sua empresa. Caso contrário, considere uma entrada no KEV para uma biblioteca três níveis abaixo na sua árvore de dependências. Em seguida, siga o caminho que o alerta percorreria pela sua empresa e responda a cada pergunta com base na última vez em que isso realmente aconteceu ou, se nunca tiver ocorrido antes, use uma estimativa realista.
O seu inventário de versões indica se o pacote está incluído nessa compilação? De onde viria a correção, e alguém já se comprometeu com uma data para isso? Quanto tempo levou a sua última versão de segurança, desde o componente corrigido até o lançamento da atualização? Como seus usuários ficariam sabendo disso? Sempre que você não tiver uma resposta, é aí que o próximo alerta encontrará uma brecha.
Alguém na sua empresa é responsável pelas 24 horas seguintes à chegada desse alerta. O procedimento indica se essa pessoa conseguiria determinar a tempo se o Artigo 14 se aplica e, caso sim, dar entrada no pedido.
