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
- De acordo com a Lei de Resiliência Cibernética, você deve lidar com as vulnerabilidades do seu produto, incluindo aquelas presentes em suas dependências, por pelo menos cinco anos, a menos que se preveja que ele permaneça em uso por um período menor.
- Muitas estruturas de código aberto oferecem suporte a uma versão por um a três anos; portanto, um produto lançado com base em uma versão recente pode perder o acesso às correções de segurança do desenvolvedor original no meio do seu período de suporte.
- Quatro maneiras de continuar recebendo correções de segurança após o fim do suporte do desenvolvedor original: migrar para uma versão mais recente, substituir a dependência, corrigir por conta própria ou adquirir as correções.
- As obrigações de notificação estão em vigor desde 11 de setembro de 2026; portanto, uma vulnerabilidade ativamente explorada em uma dependência cujo ciclo de vida já tenha chegado ao fim deve ser notificada hoje, mesmo que não haja uma correção do desenvolvedor original para indicar. As regras relativas ao período de suporte entram em vigor em 11 de dezembro de 2027.
O período de suporte previsto na Lei de Resiliência Cibernética da UE (CRA) deve durar pelo menos cinco anos, a menos que se preveja que um produto permaneça em uso por um período mais curto. Versões recentes de frameworks populares, como Laravel, Django e Spring Boot, deixaram de receber correções de segurança de código aberto entre 1 e 3 anos após o lançamento. Se você comercializar software desenvolvido com base nesses frameworks, as correções do desenvolvedor original serão interrompidas no meio do seu período de suporte, e você terá que fornecer as correções para o restante desse período.
Um período de suporte é o tempo durante o qual um fabricante deve continuar a tratar das vulnerabilidades de um produto. De acordo com a CRA, o fabricante é quem comercializa o produto sob seu próprio nome ou marca registrada no âmbito de uma atividade comercial, seja mediante pagamento ou gratuitamente. A obrigação do fabricante de corrigir vulnerabilidades abrange todo o produto, incluindo seus componentes. As pessoas responsáveis pela manutenção das bibliotecas subjacentes geralmente não têm essa obrigação; portanto, nada as obriga a continuar corrigindo a versão que você distribui.
As principais obrigações entram em vigor em 11 de dezembro de 2027, o que pode parecer distante até você comparar os requisitos do período de suporte com o tempo durante o qual as plataformas que você escolheria hoje continuariam recebendo correções.
O que o Período de Apoio da CRA exige
A Lei de Resiliência Cibernética é o Regulamento (UE) 2024/2847. Nos termos da lei, entende-se por fabricante qualquer pessoa física ou jurídica que desenvolva um produto, ou o mande desenvolver, e o comercialize em seu próprio nome ou sob sua própria marca registrada, seja a título oneroso ou gratuito. A lei define o período de suporte como o tempo durante o qual o fabricante deve garantir que as vulnerabilidades do produto sejam corrigidas de forma eficaz.
O Artigo 13 da CRA exige que os fabricantes definam o período de forma a refletir por quanto tempo se espera que o produto permaneça em uso. As expectativas razoáveis do usuário, a natureza do produto e sua finalidade prevista são fatores que devem ser levados em consideração. O período deve ser de, no mínimo, 5 anos. A única exceção é um produto que se espera que seja utilizado por menos tempo; nesse caso, o período corresponde ao tempo de uso previsto. Quando se espera, razoavelmente, que um produto seja utilizado por mais de cinco anos, o período deve ser mais longo. Os considerandos da Lei citam roteadores, sistemas operacionais e sistemas de controle industrial como exemplos.
Três obrigações acompanham esse período. Os fabricantes devem disponibilizar atualizações de segurança sem demora e gratuitamente. A única exceção é um produto personalizado, no qual o fabricante e o usuário empresarial podem acordar uma taxa para as atualizações. A data de término, indicando pelo menos o mês e o ano, deve estar clara no momento da compra. E cada atualização de segurança permanece disponível por pelo menos 10 anos, ou pelo restante do período de suporte, se este for mais longo. Todas as três regras se aplicam tanto às correções para os componentes de código aberto dentro do produto quanto ao seu próprio código. A data de término publicada é um compromisso público; portanto, verifique por quanto tempo suas dependências continuarão recebendo correções do desenvolvedor original antes de publicá-la.
Observação: Os produtos colocados no mercado antes de 11 de dezembro de 2027 estão sujeitos aos principais requisitos da CRA somente se passarem por uma modificação substancial após essa data. Isso significa uma alteração após o lançamento que afete a conformidade com os requisitos da Lei relativos ao produto ou que altere a finalidade para a qual o produto foi avaliado. O Artigo 14, que trata da prestação de informações, funciona de maneira diferente: suas obrigações se aplicam aos produtos abrangidos pela lei que já estão no mercado e estão em vigor desde 11 de setembro de 2026.
Quanto tempo duram as dependências comuns
Três versões de frameworks — uma em Python, uma em PHP e uma em Java — chegaram recentemente ao fim de vida útil. Neste artigo, “fim de vida útil” significa a data em que um projeto deixa de lançar correções de segurança para uma versão.
| Dependência | Lançado | Correções de segurança na fonte foram concluídas | Extensão | Base |
|---|---|---|---|---|
| Django 4.2 (suporte de longo prazo) | 3 de abril de 2023 | 7 de abril de 2026 | Cerca de 3 anos | Política do projeto, não lei |
| Laravel 11 | 12 de março de 2024 | 12 de março de 2026 | 2 anos | Política do projeto, não lei |
| Spring Boot 3.5 | 22 de maio de 2025 | 30 de junho de 2026 | Cerca de 13 meses | Política do projeto, não lei |
Cada projeto se refere a isso de maneira diferente. O Django chama isso de “fim do suporte estendido”, o Laravel indica quando as correções de segurança são interrompidas e o Spring chama de “fim do suporte ao código aberto”. Para você, todos significam a mesma coisa, pois a versão que você lançou deixa de receber correções do desenvolvedor original.
Nenhuma das três recebeu cinco anos de correções de segurança do upstream, que é o mínimo que a CRA exige de você. A data de lançamento do framework, porém, é menos importante do que a data de lançamento do seu produto, pois o período de suporte começa quando você coloca o produto no mercado. No dia do lançamento, verifique quanto tempo de suporte do upstream ainda resta para o framework. Considere um produto lançado em 11 de dezembro de 2027, o dia em que as regras do período de suporte entram em vigor: seu período de suporte deve se estender, no mínimo, até 11 de dezembro de 2032. Desenvolvido com base no Laravel 13, lançado em 17 de março de 2026, ele continuaria recebendo correções de segurança do upstream até 17 de março de 2028, cerca de três meses após o início desse período. Se fosse desenvolvido com o Django 5.2, uma versão com suporte de longo prazo, continuaria recebendo essas correções até abril de 2028, cerca de quatro meses após o início do período. Versões mais recentes das estruturas chegarão antes de dezembro de 2027: o Laravel lança uma versão principal aproximadamente a cada ano, e o Django 6.2 está previsto para abril de 2027, com suporte estendido até abril de 2030, pouco mais de dois anos após o início desse mesmo período. Seja qual for a versão em que você lançar o projeto, as correções do desenvolvedor original terminam anos antes do fim do seu período de suporte, e as correções para os anos restantes terão que vir de você.
Você pode migrar para uma versão mais recente — e muitas equipes farão isso —, mas isso envolve um trabalho de engenharia que deve ser concluído antes ou durante o seu período de suporte. Três frameworks não constituem toda a pilha de tecnologia, e algumas de suas dependências terão vida útil superior a cinco anos. A tarefa é comparar as datas de lançamento de cada um com as suas.
Quem é responsável por quê em relação ao código-fonte aberto que você distribui
A CRA menciona dois aspectos sobre componentes que você não desenvolveu. “Componente” é o termo usado para designar as dependências que você incorpora. O Artigo 13 exige que os fabricantes exerçam a devida diligência ao integrar componentes de terceiros, incluindo aqueles de código aberto, para que esses componentes não comprometam a segurança do produto. E quando um fabricante identifica uma vulnerabilidade em um componente, ele deve relatá-la aos mantenedores do componente e corrigi-la em seu próprio produto. Se o fabricante desenvolver uma correção, ele deve compartilhar o código ou a documentação com esses mantenedores, em um formato legível por máquina, quando apropriado.
Os mantenedores são tratados de maneira diferente, dependendo de quem são. Um administrador de software de código aberto é uma pessoa jurídica, que não seja um fabricante, que oferece suporte sistemático a produtos específicos de código aberto destinados a atividades comerciais e os mantém viáveis. Fundações e empresas que publicam software de código aberto em um contexto empresarial podem se enquadrar nesse grupo. O artigo 24 exige que os administradores implementem e documentem uma política de segurança cibernética que apoie o desenvolvimento seguro e o tratamento eficaz de vulnerabilidades, além de cooperarem com as autoridades de fiscalização de mercado. Ele acrescenta obrigações limitadas de prestação de contas. Projetos de código aberto que não são monetizados geralmente ficam fora do âmbito das obrigações dos fabricantes, e colaboradores individuais de projetos que não administram também não estão abrangidos.
Conforme o Regulamento: Quando um fabricante determina a duração de seu período de suporte, o Artigo 13 permite que ele leve em consideração os períodos de suporte de componentes de terceiros que fornecem funções essenciais. Isso pode justificar um período mais longo. No entanto, tal período não pode ser inferior ao mínimo de cinco anos; portanto, uma estrutura que deixa de receber correções de fornecedores anteriores após dois anos não permite que você declare um período de dois anos. O mínimo de cinco anos continua válido.
| Ponto | O que diz | Base |
|---|---|---|
| Comprimento mínimo | Pelo menos cinco anos, a menos que se preveja que o produto fique em uso por menos tempo | Vigência (Artigo 13) |
| Componentes | O gerenciamento de vulnerabilidades abrange os componentes do produto, incluindo os de código aberto | Vigência (Artigo 13) |
| Responsáveis pela manutenção | Os administradores precisam de uma política de segurança cibernética documentada (que abranja o tratamento de vulnerabilidades) e não têm prazo de suporte para nenhuma versão | Caráter vinculativo (Artigo 24) |
| Cinco anos como atendente de loja | Cinco anos é o prazo mínimo, e as orientações da Comissão indicam que esse prazo não deve ser considerado como padrão para todos os produtos | Orientação (Comissão, não vinculativa) |
| Versões | Cada versão substancialmente modificada colocada no mercado precisa ter seu próprio prazo de validade declarado; uma modificação que não altere o tempo de uso previsto mantém inalterado também o prazo original | Orientação (Comissão, não vinculativa) |
Em resumo, a empresa fornecedora geralmente não oferece nenhum período de suporte, e a CRA responsabiliza você, na qualidade de fabricante, pelo tratamento das vulnerabilidades no produto final.
O que você pode fazer quando uma dependência chega ao fim de sua vida útil
Quando o desenvolvimento a montante é interrompido, alguém precisa elaborar as correções, e a CRA não especifica quem deve fazê-las. Isso deixa quatro opções, cada uma com um projeto de lei diferente.
Mudar para uma versão mais recente: isso funciona quando você controla quando os clientes recebem novas versões, mas exige tempo da equipe de engenharia a cada ciclo. Em uma pilha de tecnologia com várias estruturas (frameworks) em calendários diferentes, essas migrações acabam se acumulando.
Substitua a dependência: uma alternativa com suporte técnico resolve o problema, caso exista, desde que você tenha condições de fazer a reescrita.
Corrija você mesmo: sua equipe aplica retroativamente as correções de segurança à versão que você distribui. Isso exige pessoas que conheçam bem o código, e o Artigo 13 exige que você comunique a vulnerabilidade aos mantenedores e compartilhe sua correção com eles.
Adquira as correções: alguns projetos oferecem suporte estendido para versões mais antigas. O próprio anúncio do Spring, por exemplo, informa que o suporte comercial para o Spring Framework 6.2 se estende até meados de 2032. Os dados de suporte da Spring indicam que o suporte empresarial para o Spring Boot 3.5 — a versão apresentada na tabela acima — vai até 30 de junho de 2032. Provedores independentes também vendem patches para versões fora de suporte. A cobertura depende das versões específicas que você utiliza; portanto, forneça ao provedor sua lista de versões reais e confirme se cada uma delas está coberta antes de contar com esse serviço.
Outras duas medidas parecem tentadoras. Declarar um período de suporte mais curto só é possível se você esperar que o produto permaneça em uso por menos de cinco anos. Documentar uma vulnerabilidade conhecida em um registro de riscos explica isso, mas a CRA exige que os fabricantes tratem e corrijam as vulnerabilidades sem demora, e uma entrada no registro não constitui uma correção.
O que decidir antes de definir um período de pensão alimentícia
É preciso indicar a data de término no momento da compra; por isso, é mais fácil resolver as questões relacionadas às dependências antes de publicar o conteúdo do que depois.
- Comece com um inventário: uma lista atualizada do que seu produto contém, geralmente uma lista de materiais de software (SBOM), mostra quais dependências você deve verificar, incluindo aquelas incorporadas por suas dependências diretas.
- Organize as datas: coloque a data de fim de vida útil divulgada por cada dependência ao lado do período de suporte da CRA que você está considerando. Uma planilha serve para isso.
- Verifique cada versão: o suporte é válido por versão, conforme demonstrado pelas datas do Django, Laravel e Spring Boot. Verifique a data de fim de vida útil da versão exata que você comercializa. As orientações da Comissão também exigem que seja declarado um período de suporte para cada versão substancialmente modificada que você colocar no mercado.
- Indique um responsável para cada lacuna: para cada dependência que não esteja atendida, escolha uma das quatro opções e decida quem será o responsável por ela.
- Sinalize o que já ultrapassou o fim da vida útil: se uma dependência em um produto lançado já tiver ultrapassado o fim da vida útil hoje, a lacuna já existe. Se o produto estiver dentro do escopo, uma vulnerabilidade ativamente explorada nessa dependência deve ser comunicada em até 24 horas a partir de 11 de setembro de 2026. A notificação de 72 horas que se segue deve informar o que foi feito a respeito, caso não haja uma correção do desenvolvedor original para indicar.
- Anote o motivo: a documentação técnica deve incluir as informações que você utilizou para definir o período; portanto, registre seu raciocínio.
Reduzir a lacuna até dezembro de 2027
Você define um período de suporte ao lançar um produto no mercado e, em seguida, mantê-lo por anos, enquanto as estruturas subjacentes seguem seus próprios cronogramas. Alinhar os dois antes de se comprometer mostra quantos desses anos você passará buscando correções de segurança para um código cujos mantenedores deixaram de lançar patches.
Se uma das estruturas subjacentes ao seu produto deixar de receber correções de segurança do desenvolvedor original antes do término do seu período de suporte, alguém ainda precisará produzir a correção. O Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare faz exatamente isso. Os engenheiros da TuxCare adaptam as correções de segurança para as versões exatas que você já utiliza, enquanto você depender delas. Seus desenvolvedores mantêm as versões que possuem e os fluxos de trabalho que utilizam. O ELS também funciona em conjunto com o SecureChain, que verifica pacotes de código aberto antes da instalação e aplica patches neles enquanto o upstream ainda estiver ativo.
Quando adquiridos em conjunto, o SecureChain e o ELS fazem a transição da cobertura automaticamente. Quando um mantenedor deixa de lançar correções de segurança para uma versão que você utiliza, a cobertura dessa versão passa do SecureChain para o ELS. Você não precisa acompanhar a data de fim de vida útil de cada componente para saber quando as correções do desenvolvedor original são interrompidas. Os produtos agora abrangem os ecossistemas de JavaScript, Python, Java, Go e PHP.
Perguntas frequentes
Qual é a duração mínima do período de apoio do CRA da UE?
A Lei de Resiliência Cibernética da UE (CRA) estabelece um período mínimo de suporte de cinco anos. Um fabricante só pode reduzir esse período se for previsto que o produto permaneça em uso por menos tempo; nesse caso, o período de suporte deve corresponder a esse tempo de uso. Um produto que, de forma plausível, será utilizado por mais tempo necessita de um período de suporte mais longo.
Os mantenedores de software de código aberto precisam continuar oferecendo suporte a versões antigas?
Geralmente, não. A Lei de Resiliência Cibernética (CRA) trata dois grupos de maneira diferente, e nenhum deles tem a obrigação de oferecer um período de suporte. Os administradores de software de código aberto — pessoas jurídicas que oferecem suporte sistemático a produtos de código aberto para uso comercial — devem documentar uma política de segurança cibernética, incluindo o tratamento de vulnerabilidades, e cooperar com as autoridades. Os projetos de código aberto que não são monetizados estão fora do âmbito das obrigações do fabricante, e os colaboradores individuais de projetos que não administram não estão abrangidos de forma alguma. De qualquer forma, o fabricante que distribui o código deve mantê-lo atualizado com patches durante o período de suporte declarado.
O que acontece quando uma dependência deixa de receber correções de segurança durante o período de suporte?
A responsabilidade recai sobre o fabricante. De acordo com a Lei de Resiliência Cibernética (CRA), as vulnerabilidades no produto, incluindo seus componentes, devem ser tratadas durante todo o período de suporte declarado. As opções incluem migrar para uma versão com suporte, substituir a dependência, desenvolver a correção ou adquirir patches para a versão antiga.
O que os fabricantes devem informar aos usuários sobre o período de suporte?
De acordo com a Lei de Resiliência Cibernética (CRA), a data de término do período de suporte, indicando pelo menos o mês e o ano, deve estar claramente indicada no momento da compra. Os fabricantes também registram como definem esse período em sua documentação técnica e, quando tecnicamente viável, notificam os usuários sobre o término do suporte.
A Lei de Resiliência Cibernética se aplica a produtos que já estavam no mercado antes de dezembro de 2027?
Somente se forem submetidos a modificações substanciais. De acordo com a Lei de Resiliência Cibernética (CRA), os produtos que já estiverem no mercado antes de 11 de dezembro de 2027 só estarão sujeitos aos requisitos da lei após uma modificação substancial a partir dessa data. As obrigações de notificação previstas no artigo 14, inclusive no que diz respeito a vulnerabilidades ativamente exploradas, aplicam-se a esses produtos de qualquer maneira.
As orientações da Comissão sobre a Lei de Resiliência Cibernética são juridicamente vinculativas?
Não. A Comissão Europeia publicou suas orientações sobre a Lei de Resiliência Cibernética (CRA) em 27 de julho de 2026 para explicar como aplicar as regras, mas elas não são vinculativas. O próprio regulamento e os atos delegados ou de execução adotados têm força jurídica, e somente o Tribunal de Justiça da UE pode fornecer uma interpretação definitiva. As orientações mostram como a Comissão espera que as regras sejam aplicadas; portanto, devem ser consideradas como referência para o planejamento até que um tribunal decida de outra forma.
