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
- A Starlette não divulga um ciclo de vida de suporte nem mantém ramificações de versões mais antigas; portanto, as correções de segurança são incorporadas nas versões mais recentes, em vez de serem adaptadas para versões anteriores — e todo aplicativo ASGI que ainda esteja vinculado a uma versão mais antiga carrega esse risco para o ambiente de produção.
- Migrações motivadas pelo pânico levam a pilhas de middleware comprometidas, falhas de compatibilidade assíncrona, instabilidade do sistema e excedentes orçamentários, o que pode tornar o suporte prolongado provisório a opção mais previsível.
- Opções de suporte estendido, como o “Endless Lifecycle Support” da TuxCare, oferecem cobertura de segurança contínua para versões do Starlette que chegaram ao fim do ciclo de vida, enquanto você planeja as atualizações de acordo com seu próprio cronograma, e não com o de um verificador de vulnerabilidades.
Se você está desenvolvendo serviços assíncronos em Python, é bem provável que o Starlette esteja em algum lugar da sua pilha de tecnologias, quer você saiba disso ou não. Ele pode estar rodando diretamente como sua estrutura ASGI. É mais provável, porém, que esteja discretamente alimentando o aplicativo FastAPI que sua equipe desenvolveu há dois anos — aquele que lida com autenticação, envio de arquivos ou metade das suas ferramentas internas. De qualquer forma, quando o Starlette chegar ao fim de sua vida útil, o risco não será apenas teórico.
Muitas equipes nem percebem que o Starlette está em sua árvore de dependências. Seja instalado diretamente ou incluído de forma transitiva por meio do FastAPI, ele funciona de maneira tão discreta que fica em segundo plano até que uma divulgação de CVE ou uma auditoria de segurança o coloque em destaque.
Então, vamos falar sobre o que o fim da linha 0.x do Starlette significa para o seu ambiente de produção e, mais importante ainda, o que você pode fazer de forma realista a respeito disso sem comprometer seu plano de desenvolvimento.
Como funcionam, na verdade, os lançamentos da Starlette
Antes de entrarmos na parte do tipo “tudo bem, e agora o que fazemos?”, é bom entender como o Starlette gerencia o ciclo de vida de suas versões, pois é um pouco diferente do que você poderia imaginar.
O Starlette foi criado em junho de 2018 por Kim Christie e passou anos em uma longa linha de versões 0.x que a comunidade costuma chamar de “ZeroVer”. Hoje, ele é baixado cerca de 10 milhões de vezes por dia, serve de base para o FastAPI e é uma dependência do SDK do Python MCP. Por quase oito anos, porém, ela foi lançada como 0.x.y, o que significava que não havia ciclo formal de descontinuação, nem designação LTS, nem política de fim de vida útil publicada vinculada aos números de versão. O projeto continuou a ser lançado, e as versões mais antigas simplesmente deixaram de receber atenção.
Isso mudou em 22 de março de 2026, quando o Starlette atingiu a versão 1.0.0 após uma versão candidata ao lançamento em fevereiro. Foi um verdadeiro marco: anos de APIs obsoletas foram removidas, a direção do projeto foi formalizada e o versionamento semântico finalmente foi adotado. A linha 1.x continuou evoluindo desde então, passando pelas versões 1.0.1, 1.1.0, 1.2.x e 1.3.1 em junho de 2026; portanto, a meta de atualização hoje é a versão 1.x atual, e não a própria 1.0.0.
Aqui está o ponto importante para quem ainda estiver na versão 0.x. O Starlette não divulga um ciclo de vida de suporte e não mantém ramos de versões mais antigas. As correções são fornecidas em versões mais recentes. Portanto, se você estiver executando uma versão 0.x que já foi substituída, a questão prática não é se a data oficial de fim de vida útil (EOL) já passou, mas sim se você deve esperar que uma correção de segurança seja adaptada para a versão que você fixou. Você não deve.
Além disso, um grande número de aplicativos em produção está fixado em versões específicas da série 0.x, muitas vezes indiretamente, por meio dos intervalos de versões compatíveis do FastAPI. Equipes que não revisam seus arquivos de dependências há algum tempo podem estar muito atrasadas. Um aplicativo fixado na versão 0.27.0 do Starlette — uma fixação muito comum nas versões mais antigas do FastAPI — está mais de vinte versões secundárias atrás da 0.50.0 e é anterior a duas correções de segurança documentadas.
Ao contrário do Node.js, com suas linhas LTS, ou do CPython, com seu período de suporte documentado de cinco anos, o Starlette não possui um ramo de manutenção ao qual recorrer. Na prática, as correções são disponibilizadas por meio de novas versões, e não pela versão que você está executando.
O que o fim da vida útil (EOL) do Starlette realmente significa para o seu ambiente de produção
Tudo bem, então uma versão já não está mais recebendo atenção. Seu aplicativo ASGI ainda está em execução, as solicitações continuam chegando e tudo parece estar bem. Por que se preocupar?
Porque as vulnerabilidades não deixam de ser descobertas quando a atenção dos desenvolvedores originais se volta para outros assuntos. Os invasores não consultam o changelog do Starlette antes de testar seus endpoints, e os pesquisadores de segurança continuam encontrando problemas em versões amplamente utilizadas, especialmente aquelas que servem de base para uma grande parte das aplicações web em Python.
As versões mais antigas do Starlette já foram afetadas por vários problemas de alta gravidade, e esse padrão é consistente o suficiente para ser motivo de preocupação para quem ainda as utiliza.
CVE-2024-47874 (CVSS 4.0: 8,7, Alta): uma vulnerabilidade de negação de serviço que afeta todas as versões do Starlette anteriores à 0.40.0. O problema está na forma como o Starlette lida com partes do `multipart/form-data` que não incluem um nome de arquivo. Essas partes são tratadas como campos de texto e armazenadas em buffer na memória sem limite de tamanho. Um invasor pode enviar campos de formulário arbitrariamente grandes, fazendo com que o Starlette esgote a memória por meio de alocações e operações de cópia excessivas. O envio de várias solicitações desse tipo em paralelo pode tornar um serviço praticamente inutilizável, mesmo quando um proxy reverso impõe limites gerais ao tamanho das solicitações. Isso afeta qualquer aplicativo desenvolvido com Starlette ou FastAPI que aceite solicitações de formulário, o que representa uma área de impacto muito ampla. Corrigido na versão 0.40.0.
CVE-2025-62727 (CVSS 3.1: 7,5, Alta): uma vulnerabilidade de negação de serviço que afeta o Starlette das versões 0.39.0 a 0.49.0. Um invasor não autenticado pode enviar um cabeçalho HTTP Range malicioso que aciona um processamento em tempo quadrático no FileResponse do Starlette. Cada solicitação maliciosa consome tempo de CPU desproporcional, e solicitações repetidas ou simultâneas podem prejudicar a disponibilidade de qualquer endpoint que sirva arquivos, incluindo qualquer um que utilize StaticFiles ou FileResponse diretamente. Corrigido na versão 0.49.1.
Esses dois também não são a lista completa. A versão 0.27.0 do Starlette corrigiu uma vulnerabilidade de traversal de caminho em StaticFiles, e a versão 0.25.0 adicionou limites ao número de partes multipart que uma solicitação poderia conter. Qualquer versão fixada abaixo dessas ainda apresenta esses problemas até hoje.
Esses não são casos isolados nem vulnerabilidades teóricas, e não se limitam apenas ao Starlette. A IBM publicou boletins de segurança para produtos que incluíam versões vulneráveis do Starlette, incluindo o Maximo Application Suite, o App Connect Enterprise Certified Container e o Planning Analytics Workspace. No que diz respeito ao vLLM, os colaboradores abriram um ticket solicitando uma atualização urgente da dependência após descobrirem que o projeto estava fixado na versão 0.46.2, que se encontrava no intervalo afetado pela vulnerabilidade CVE-2025-62727.
Agora, a verdade sobre essas duas CVEs: cada uma delas foi corrigida no código-fonte original enquanto a versão 0.x ainda era a linha ativa. Esse é exatamente o ponto. A correção chegou em uma versão mais recente da 0.x, não como um backport para a versão que você fixou, e agora que o desenvolvimento mudou para a 1.x, a próxima vulnerabilidade divulgada será corrigida na 1.x. Em uma versão substituída, uma vulnerabilidade recém-divulgada permanece exposta até que você faça a atualização, aplique o backport da correção por conta própria ou obtenha um patch de outra fonte.
As estruturas de conformidade têm posições sobre essa lacuna. A norma PCI DSS v4.0.1 (requisito 6.3.3) exige que patches de segurança críticos sejam instalados no prazo de um mês após o lançamento, enquanto outras vulnerabilidades devem ser tratadas de acordo com o cronograma definido pelo seu processo documentado de classificação de riscos. Componentes sem suporte também podem suscitar questionamentos durante as auditorias SOC 2 sobre o gerenciamento de vulnerabilidades e a eficácia de seus controles, e podem exigir um tratamento documentado do risco e controles compensatórios, em vez de uma resposta direta.
O risco oculto: sua pilha de dependências
A exposição não se limita ao próprio código do Starlette. A dependência que merece maior atenção é python-multipart, que é onde a análise de formulários do Starlette realmente é executada. Ela apresentava sua própria vulnerabilidade de negação de serviço, CVE-2024-53981 (CVSS 4.0: 8,7, Alta), corrigida na versão 0.0.18 — e o Starlette só elevou sua versão mínima para 0.0.18 na versão 0.42.0. Se você estiver com uma versão anterior a essa, é bem provável que a versão do analisador que você definiu seja anterior à correção. O Jinja2 para modelos e o itsdangerous para assinatura de cookies de sessão estão na mesma categoria: complementos opcionais que trazem seus próprios alertas de segurança e que muitas equipes nunca auditam separadamente.
O AnyIO e o typing-extensions são um problema à parte. Nenhum dos dois tem grande peso no CVE, e o typing-extensions só é usado em versões do Python anteriores à 3.10 nas versões mais recentes. O que as versões mais antigas do Starlette fazem é restringir quais versões desses pacotes você pode resolver. Isso não as torna vulneráveis, mas complica a correção: se uma correção para outro problema em sua árvore exigir uma versão mais recente que o Starlette fixado não aceita, você acaba tendo que fazer a atualização do Starlette de qualquer maneira, seguindo o cronograma de outra pessoa.
A ação prática aqui leva dez minutos. Execute pip list (ou verifique seu arquivo de bloqueio) e confira as versões resolvidas de python-multipart, jinja2e itsdangerous, e não apenas a versão do próprio Starlette.
Suas opções quando o Starlette chegar ao fim da vida útil
Então, sua versão do Starlette está ultrapassada, ou está caminhando nessa direção. Quais são suas opções realistas daqui para frente?
Existem três opções, e a escolha da mais adequada depende do tamanho da sua aplicação, da cobertura de testes, da versão do Python, do cronograma de migração e da tolerância ao risco. Duas delas envolvem planejamento, custos e riscos reais. A terceira, o suporte estendido, oferece cobertura de segurança provisória quando uma atualização imediata não é viável.
Opção 1: Atualizar para uma versão compatível do Starlette 1.x
A recomendação do desenvolvedor original é atualizar para uma versão 1.x do Starlette que seja suportada atualmente, obter cobertura de segurança ativa e se beneficiar de uma linha de versões adequadamente gerenciada daqui para frente.
E o Starlette 1.x é realmente melhor. O projeto eliminou anos de APIs obsoletas acumuladas, adotou um sistema estável de versionamento semântico e vem lançando correções desde então: a versão 1.0.1 lida com cabeçalhos malformados ao construir request.url, a 1.1.0 rejeita caminhos absolutos em StaticFiles.lookup_path, e a versão 1.3.1 impõe o uso de max_fields e max_part_size no analisador de formulários. Para equipes que estão começando do zero ou mantendo bases de código ativas, esse é claramente o caminho certo a longo prazo.
Mas atualizar um aplicativo de produção que está vinculado a uma versão 0.x mais antiga significa lidar com tudo isso:
Decoradores removidos: o @app.route(), @app.websocket_route(), @app.exception_handler()e @app.middleware() não existem mais. As rotas passaram para Route e WebSocketRoute no arquivo parâmetro routes e os manipuladores são transferidos para a seção exception_handlers e middleware no aplicativo. Em um aplicativo grande, com muitas rotas e registros de middleware, isso afeta muitos arquivos.
APIs de ciclo de vida removidas: a on_startup e on_shutdown , o @app.on_event() , add_event_handler()e Router.startup()/Router.shutdown() foram todos removidos. Os aplicativos que os utilizam precisam migrar para o interface `lifespan` .
Alterações no modelo: O Jinja2Templates não aceita mais **env_options (passar um ambiente pré-configurado via env ), o antigo TemplateResponse(name, context) foi removida, o jinja2 agora precisa estar instalado para que a classe possa ser importada, e o autoescape está ativado por padrão.
Alterações no gerenciamento de sessões: O Starlette 1.0 adicionou o rastreamento de acessos e modificações na sessão no SessionMiddleware. Não há garantia de que algo deixará de funcionar, mas se sua aplicação apresentar um comportamento sensível em relação às sessões, inclua os fluxos de sessão no plano de testes de regressão, em vez de simplesmente presumir que tudo continuará funcionando.
Requisitos de execução: O Starlette 1.x requer o Python 3.10 ou posterior. O suporte ao Python 3.9 foi descontinuado na versão 0.50.0 e ao 3.8 na versão 0.45.0. Se você estiver usando qualquer uma dessas versões, precisará primeiro atualizar o ambiente de execução, o que traz suas próprias implicações de compatibilidade para sua árvore de dependências mais ampla — e ambas as versões do Python já estão no fim de vida útil, portanto, são dois problemas que se sobrepõem, e não apenas um.
Complexidade do alinhamento com o FastAPI: se você estiver usando o FastAPI, a atualização não é tão simples quanto aumentar a versão do Starlette no seu arquivo de dependências. O FastAPI especifica intervalos de versões compatíveis do Starlette, o que significa que, muitas vezes, você precisa atualizar os dois ao mesmo tempo e verificar se ambos funcionam conforme o esperado em relação ao código do seu aplicativo.
Para um aplicativo pequeno e bem testado, trata-se de um sprint bem focado. Para um sistema maior, com middleware extenso, gerenciamento complexo de sessões e padrões acumulados ao longo de anos, é necessário um planejamento cuidadoso, testes minuciosos e há um risco real de regressões sutis sob carga de produção.
Opção 2: Migrar para outro framework
Algumas equipes olham para uma versão da Starlette que está no fim de sua vida útil e pensam: “talvez este seja o momento de reconsiderar”.
Se você estiver usando o Starlette sem nada mais, vale a pena considerar o FastAPI – ele adiciona validação e serialização sobre a mesma base da qual você já depende. O Litestar é outro framework ASGI moderno com uma filosofia de design diferente. Para equipes que estão avaliando uma mudança mais ampla na arquitetura, existem opções viáveis.
Mas não vamos nos iludir sobre o que uma migração de framework envolve. Talvez seja necessário reescrever os manipuladores de rota de acordo com a API do novo framework, refatorar o middleware e o tratamento de exceções (que variam bastante entre os frameworks), atualizar sua infraestrutura de testes, validar se a configuração do servidor ASGI ainda funciona corretamente e manter o sistema existente em funcionamento enquanto o substituto é desenvolvido.
Os benefícios arquitetônicos de longo prazo podem justificar esse investimento. Mas o prazo e o custo podem ultrapassar em muito a estimativa inicial, especialmente quando o aplicativo apresenta muitos comportamentos específicos do framework. E o período em que a produção ainda está na versão antiga enquanto a migração está em andamento é exatamente a janela de vulnerabilidade que você estava tentando eliminar.
Opção 3: Suporte estendido de terceiros
Existe uma terceira opção que não recebe a atenção que merece: o suporte estendido de segurança oferecido por empresas especializadas nesse problema.
A TuxCare oferece suporte contínuo ao ciclo de vida para versões do Starlette que chegaram ao fim de vida. Em vez de forçar uma migração para a qual você ainda não está preparado, ou deixar suas aplicações expostas enquanto planeja essa migração, você continua executando sua versão atual com cobertura contínua de patches de segurança.
A lógica é simples: você ganha tempo e controle. Tempo para planejar uma atualização bem pensada quando for mais adequado ao seu plano de ação. Controle sobre o cronograma da sua migração, em vez de ficar à mercê de uma divulgação de CVE que o obrigue a agir no pior momento possível.
Então, concretamente:
Se você estiver usando uma versão 0.4x, já estiver no Python 3.10 ou superior, com uma cobertura de testes satisfatória e apenas alguns poucos middlewares personalizados, então faça a atualização para a versão 1.x atual agora mesmo. Isso é uma tarefa rápida, não um projeto.
Se você estiver usando uma versão 0.2x ou 0.3x com Python 3.8 ou 3.9, então faça a atualização do runtime primeiro e use o suporte estendido para corrigir as falhas de segurança enquanto realiza a atualização.
Se você já se comprometeu a migrar para outra estrutura, então utilize o suporte estendido para cobrir o período de migração, em vez de ficar exposto a riscos por dois trimestres.
Se o prazo para conformidade for daqui a algumas semanas e a migração estiver prevista para daqui a alguns meses, então o suporte estendido é a única opção que atende a ambos, e você faz a atualização posteriormente, de acordo com sua própria programação.
O verdadeiro custo de apressar uma atualização do ciclo de vida (EOL) do Starlette
Vamos falar sobre o que acontece quando as equipes migram às pressas um aplicativo ASGI em produção porque os alertas de fim de vida útil finalmente atingiram um nível crítico no painel de segurança.
Imagine uma equipe de SaaS com 40 pessoas trabalhando com o FastAPI 0.95 e o Starlette 0.36, com Python 3.9 como base, 180 rotas, quatro middlewares personalizados e um prazo de conformidade em três semanas. Quando a atualização é comprimida nesse prazo, coisas previsíveis dão errado:
Aumento da carga de suporte: as mudanças sutis de comportamento que não vieram à tona nos testes começam a aparecer na produção. Uma API obsoleta que finalmente foi removida, um caso extremo de gerenciamento de sessão que agora se comporta de maneira diferente, uma interação de middleware que não foi coberta pelo seu conjunto de testes. Sua equipe de suporte fica sobrecarregada com tickets, e metade deles está relacionada à migração.
Instabilidade do sistema: problemas de compatibilidade com o async são difíceis de depurar. Talvez uma dependência que funcionava bem com sua versão anterior do AnyIO agora apresente diferenças sutis de tempo sob carga. Talvez uma cadeia de middleware se comporte de maneira diferente quando o ciclo de vida da solicitação muda. Esses são os problemas que geram alertas tarde da noite e deixam os engenheiros de plantão muito insatisfeitos.
Acúmulo de dívida técnica: na pressa para garantir a conformidade, a refatoração adequada acaba sendo adiada. São adicionados shims de compatibilidade com comentários do tipo “vamos dar um jeito nisso depois”. Seis meses após a migração, você está tecnicamente na versão 1.x, mas executando uma base de código cheia de soluções provisórias que ninguém tem tempo para resolver.
Excedentes orçamentários: a estimativa original era de duas semanas. Cinco semanas depois, você ainda está lidando com regressões. O prestador de serviços contratado para ajudar continua cobrando. Os recursos foram adiados. O custo de oportunidade de engenheiros sênior depurando interações de middleware assíncrono em vez de desenvolver novos recursos aumenta rapidamente.
A atualização é a solução correta a longo prazo. Uma atualização apressada, motivada pela pressão para cumprir normas, é um tipo específico e totalmente previsível de falha. Não são a mesma coisa.
Mantendo o Starlette protegido enquanto você planeja a atualização: o suporte de ciclo de vida ilimitado da TuxCare
É aí que o Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare para o Starlette muda o jogo.
A TuxCare vem realizando esse trabalho há bem mais de uma década, fornecendo patches de segurança para sistemas operacionais, ambientes de execução, bibliotecas e estruturas de aplicativos que chegaram ao fim de vida útil em ambientes de produção corporativos.
O que diferencia a abordagem da TuxCare
Cobertura da pilha de dependências: A TuxCare não aplica patches apenas ao Starlette. A cobertura se estende às dependências diretas e transitivas do Starlette sem custo adicional, o que é importante, já que a fonte mais provável de problemas em uma pilha ASGI é um analisador de formulários ou um mecanismo de modelos localizado várias camadas abaixo.
Aplicação automatizada de patches com validação por especialistas: A TuxCare monitora CVEs 24 horas por dia no NVD, nos alertas de segurança dos fornecedores e nos alertas de segurança do GitHub. Quando um CVE relevante é identificado, as correções são adaptadas por meio de automação algorítmica e assistida por IA, com validação por especialistas; em seguida, são testadas quanto à integridade, funcionalidade e regressões, assinadas e publicadas nos repositórios da TuxCare. Se você quiser saber mais detalhes, leia o white paper técnico da TuxCare sobre seu processo de correção de código aberto.
Se adapta ao seu fluxo de trabalho atual: Os pacotes ELS para o Starlette são fornecidos via pip a partir de repositórios hospedados pela TuxCare, portanto, eles são instalados por meio do fluxo de trabalho de empacotamento e CI/CD que você já utiliza. Você não precisa reformular seu pipeline nem treinar novamente sua equipe.
Resposta baseada no SLA: os compromissos relativos ao fornecimento de patches e ao suporte estão definidos no acordo de nível de serviço aplicável; assim, você pode planejar com base em um cronograma contratual, em vez de ficar esperando que alguém, eventualmente, publique um backport.
Previsibilidade de custos: o suporte prolongado pode sair mais barato do que acelerar uma migração complexa, quando se leva em conta o tempo de engenharia a taxas reais, os ciclos de teste, os honorários de prestadores de serviços, o possível tempo de inatividade e o atraso na implementação de recursos. Além disso, trata-se de um valor definido para um prazo determinado, o que é mais fácil de justificar em uma discussão sobre orçamento do que uma estimativa de migração sem prazo definido. Solicite um orçamento e compare-o com seus próprios cálculos.
Conformidade e transparência: cada versão traz informações sobre quais componentes receberam correções e quais CVEs foram sanados, para que você possa verificar o que já foi resolvido na sua lista de materiais de software. Essa documentação auxilia na coleta de evidências para avaliações PCI DSS, revisões SOC 2 e processos internos de gerenciamento de vulnerabilidades.
Como começar
Se você estiver utilizando uma versão do Starlette que chegou ao fim da vida útil e quiser saber qual é a cobertura disponível atualmente, a TuxCare mantém um rastreador de CVE em tempo real onde você pode ver quais vulnerabilidades já foram corrigidas.
Quer saber tudo sobre as versões compatíveis, preços e implementação? Acesse Suporte de Ciclo de Vida Ilimitado da TuxCare para Starlette para obter detalhes, incluindo quais versões do Starlette são cobertas atualmente e como solicitar uma que ainda não esteja na lista.
Não deixe que o fim da vida útil do Starlette coloque seus sistemas em risco
O Starlette vem tendo um grande sucesso. Ele estabeleceu as bases para o desenvolvimento web assíncrono moderno em Python, é a base do FastAPI, é utilizado pelo SDK do Python MCP e é baixado cerca de 10 milhões de vezes por dia. Chegar à versão 1.0.0 após quase oito anos é um verdadeiro marco para o projeto, e a linha 1.x é mantida ativamente.
Mas se você estiver executando uma versão antiga em produção, seja uma versão na faixa de 0.30 a 0.39 ou uma versão posterior, de 0.40 a 0.49, “ainda está funcionando” não é o mesmo que “ainda é seguro”.
Isso não significa necessariamente agir às pressas. Você tem opções reais. Você pode planejar uma atualização bem pensada do Starlette 1.x atual, quando isso se encaixar no roteiro da sua equipe. Você pode avaliar se uma estrutura diferente faz sentido do ponto de vista arquitetônico. Ou você pode utilizar o suporte estendido para manter a segurança e a conformidade estáveis enquanto toma essas decisões de acordo com o seu próprio cronograma, em vez de ficar à mercê de uma auditoria de segurança.
As equipes que lidam bem com isso reconhecem o risco desde o início, entendem o que está disponível e tomam decisões deliberadas, em vez de reativas, com base em sua arquitetura, nos recursos disponíveis e nos prazos de conformidade.
Se você está de olho em uma versão do Starlette que está chegando ao fim de sua vida útil, vale a pena conferir o que a TuxCare oferece. Você pode descobrir que proteger o que já desenvolveu, enquanto planeja a atualização que realmente deseja, é um próximo passo melhor do que apressar uma migração para a qual ainda não está pronto.
Visite o Suporte de Ciclo de Vida Ilimitado da TuxCare para software de código aberto para ver como o suporte estendido pode proteger os componentes suportados em toda a sua pilha de código aberto pelo tempo que você precisar.
