Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Starlette no publica un ciclo de vida de soporte ni mantiene ramas de versiones anteriores, por lo que las correcciones de seguridad se incluyen en las versiones más recientes en lugar de retroportarse; y todas las aplicaciones ASGI que sigan fijadas a una versión anterior siguen expuestas a ese riesgo en el entorno de producción.
- Las migraciones impulsadas por el pánico provocan fallos en las pilas de middleware, problemas de compatibilidad asíncrona, inestabilidad del sistema y sobrecostes que pueden hacer que la ampliación del soporte técnico provisional sea la opción más predecible.
- Las opciones de soporte ampliado, como el «Endless Lifecycle Support» de TuxCare, ofrecen una cobertura de seguridad continua para las versiones de Starlette que han llegado al final de su ciclo de vida, mientras planificas las actualizaciones según tu propio calendario, y no según el de un escáner de vulnerabilidades.
Si estás desarrollando servicios asíncronos en Python, es muy probable que Starlette forme parte de tu pila de tecnologías, lo sepas o no. Puede que se esté ejecutando directamente como tu marco ASGI. Lo más probable es que esté impulsando discretamente la aplicación FastAPI que tu equipo creó hace dos años, aquella que se encarga de la autenticación, la subida de archivos o la mitad de tus herramientas internas. En cualquier caso, cuando Starlette llegue al final de su ciclo de vida, el riesgo no será meramente teórico.
Muchos equipos ni siquiera se dan cuenta de que Starlette forma parte de su árbol de dependencias. Tanto si se ha instalado directamente como si se ha incorporado de forma transitiva a través de FastAPI, funciona de forma tan discreta que pasa a un segundo plano hasta que una divulgación de CVE o una auditoría de seguridad lo pone en el punto de mira.
Hablemos, pues, de lo que supone el fin de la línea 0.x de Starlette para tu entorno de producción y, lo que es más importante, de qué medidas realistas puedes tomar al respecto sin echar por tierra tu hoja de ruta de ingeniería.
Cómo funcionan realmente los lanzamientos de Starlette
Antes de pasar a la parte de «vale, ¿y ahora qué hacemos?», conviene entender cómo gestiona Starlette el ciclo de vida de sus versiones, ya que es un poco diferente de lo que cabría esperar.
Starlette fue creado en junio de 2018 por Kim Christie y pasó años en una línea de versiones 0.x de larga duración que la comunidad suele denominar «ZeroVer». Hoy en día se descarga cerca de 10 millones de veces al día, sirve de base para FastAPI y es una dependencia del SDK de Python MCP. Sin embargo, durante casi ocho años se distribuyó como 0.x.y, lo que significaba que no había un ciclo formal de obsolescencia, ni designación LTS, ni política publicada de fin de vida útil vinculada a los números de versión. El proyecto siguió lanzando versiones, y las versiones más antiguas simplemente dejaron de recibir atención.
Eso cambió el 22 de marzo de 2026, cuando Starlette alcanzó la versión 1.0.0 tras una versión candidata lanzada en febrero. Fue un auténtico hito: se eliminaron años de API obsoletas, se formalizó la dirección del proyecto y, por fin, se implantó el versionado semántico. La línea 1.x ha seguido avanzando desde entonces, pasando por las versiones 1.0.1, 1.1.0, 1.2.x y 1.3.1 en junio de 2026, por lo que el objetivo de actualización actual es la versión 1.x vigente, en lugar de la propia 1.0.0.
Esta es la parte importante para cualquiera que siga utilizando una versión 0.x. Starlette no publica un ciclo de vida de soporte y no mantiene ramas de versiones antiguas. Las correcciones se incluyen en las versiones más recientes. Por lo tanto, si estás utilizando una versión 0.x obsoleta, la cuestión práctica no es si ha pasado ya la fecha oficial de fin de vida útil (EOL), sino si debes esperar que se aplique una corrección de seguridad a la versión que has fijado. No deberías.
Además, un gran número de aplicaciones en producción están fijadas a versiones 0.x específicas, a menudo de forma indirecta, a través de los rangos de versiones compatibles de FastAPI. Los equipos que llevan tiempo sin revisar sus archivos de dependencias pueden encontrarse muy desactualizados. Una aplicación fijada a Starlette 0.27.0 —una fijación muy habitual en las versiones anteriores de FastAPI— se encuentra a más de veinte versiones menores por detrás de la 0.50.0 y es anterior a dos correcciones de seguridad documentadas.
A diferencia de Node.js, con sus líneas LTS, o de CPython, con su periodo de soporte documentado de cinco años, Starlette no cuenta con una rama de mantenimiento a la que recurrir. En la práctica, las correcciones se incorporan a través de nuevas versiones, no a través de la versión que estés utilizando.
Qué significa realmente el fin de vida útil (EOL) de Starlette para tu entorno de producción
Vale, supongamos que una versión ya no recibe atención. Tu aplicación ASGI sigue funcionando, siguen llegando solicitudes y todo parece ir bien. ¿Por qué preocuparse?
Porque no dejan de descubrirse vulnerabilidades cuando la atención de los desarrolladores deja de centrarse en ellas. Los atacantes no consultan el registro de cambios de Starlette antes de sondear tus terminales, y los investigadores de seguridad siguen encontrando problemas en versiones ampliamente implantadas, especialmente en aquellas que sirven de base a una gran parte de las aplicaciones web escritas en Python.
Las versiones anteriores de Starlette ya se han visto afectadas por varios problemas de alta gravedad, y esta tendencia es lo suficientemente constante como para resultar preocupante para cualquiera que aún las utilice.
CVE-2024-47874 (CVSS 4.0: 8,7, Alta): una vulnerabilidad de denegación de servicio que afecta a todas las versiones de Starlette anteriores a la 0.40.0. El problema radica en la forma en que Starlette gestiona las partes «multipart/form-data» que no incluyen un nombre de archivo. Estos se tratan como campos de texto y se almacenan en memoria sin límite de tamaño. Un atacante puede enviar campos de formulario de tamaño arbitrariamente grande, lo que provoca que Starlette agote la memoria debido a un exceso de asignaciones y operaciones de copia. El envío de varias solicitudes de este tipo en paralelo puede dejar un servicio prácticamente inutilizable, incluso cuando un proxy inverso impone límites al tamaño total de las solicitudes. Afecta a cualquier aplicación desarrollada con Starlette o FastAPI que acepte solicitudes de formulario, lo que supone una superficie de impacto muy amplia. Corregido en la versión 0.40.0.
CVE-2025-62727 (CVSS 3.1: 7,5, Alta): una vulnerabilidad de denegación de servicio que afecta a Starlette desde la versión 0.39.0 hasta la 0.49.0. Un atacante no autenticado puede enviar un encabezado HTTP Range manipulado que desencadena un procesamiento de tiempo cuadrático en la función FileResponse de Starlette para el análisis y la fusión de rangos. Cada solicitud maliciosa consume un tiempo de CPU desproporcionado, y las solicitudes repetidas o simultáneas pueden reducir la disponibilidad de cualquier punto final que sirva archivos, incluyendo cualquier elemento que utilice StaticFiles o FileResponse . Corregido en la versión 0.49.1.
Esas dos tampoco son todas. La versión 0.27.0 de Starlette corrigió un error de recorrido de rutas en StaticFiles, y la versión 0.25.0 añadió límites al número de partes que puede contener una solicitud multiparte. Cualquier versión anterior a estas que siga fijada sigue presentando esos problemas a día de hoy.
No se trata de casos aislados ni de vulnerabilidades teóricas, y no se limitan únicamente a Starlette. IBM ha publicado boletines de seguridad para productos que incluían versiones vulnerables de Starlette, entre los que se encuentran Maximo Application Suite, App Connect Enterprise Certified Container y Planning Analytics Workspace. En cuanto a vLLM, los colaboradores abrieron un incidencia solicitando una actualización urgente de las dependencias tras descubrir que el proyecto tenía fijada la versión en 0.46.2, que se encontraba dentro del rango afectado por CVE-2025-62727.
Ahora bien, la verdad sobre esas dos CVE es que ambas se corrigieron en el código fuente original mientras la rama 0.x aún estaba activa. Ese es precisamente el quid de la cuestión. La corrección llegó en una versión más reciente de la serie 0.x, no como una adaptación a la versión que tenías fijada, y ahora que el desarrollo ha pasado a la serie 1.x, la próxima vulnerabilidad que se revele se corregirá en la serie 1.x. En una versión obsoleta, una vulnerabilidad recién revelada permanece expuesta hasta que actualices, adaptes tú mismo la corrección o consigas un parche de otra fuente.
Los marcos de cumplimiento tienen su propia visión sobre esa brecha. La norma PCI DSS v4.0.1 (requisito 6.3.3) exige que los parches de seguridad críticos se instalen en el plazo de un mes desde su lanzamiento, mientras que otras vulnerabilidades deben gestionarse según el calendario definido en su proceso documentado de clasificación de riesgos. Los componentes sin soporte técnico también pueden suscitar dudas durante las auditorías SOC 2 sobre la gestión de vulnerabilidades y la eficacia de sus controles, y es posible que requieran un tratamiento documentado del riesgo y controles compensatorios, en lugar de una respuesta clara.
El riesgo oculto: tu pila de dependencias
La exposición no se limita al código propio de Starlette. La dependencia que merece mayor atención es python-multipart, que es sobre el que realmente se ejecuta el análisis de formularios de Starlette. Este presentaba su propio problema de denegación de servicio, CVE-2024-53981 (CVSS 4.0: 8,7, Alto), corregido en la versión 0.0.18; y Starlette no elevó su propia versión mínima a 0.0.18 hasta la versión 0.42.0. Si tu versión es anterior a esa, es muy probable que la versión del analizador que tienes instalada sea anterior a la corrección. Jinja2 para las plantillas e itsdangerous para la firma de cookies de sesión se encuentran en la misma categoría: complementos opcionales que conllevan sus propios avisos de seguridad y que muchos equipos nunca auditan por separado.
AnyIO y typing-extensions son un problema distinto. Ninguno de los dos tiene mucho peso en cuanto a CVE, y typing-extensions solo se utiliza en versiones de Python anteriores a la 3.10 en las últimas versiones. Lo que hacen las versiones más antiguas de Starlette es limitar las versiones de esos paquetes que se pueden resolver. Eso no las hace vulnerables, pero complica la corrección: si una corrección para otro elemento de tu árbol requiere una versión más reciente que tu Starlette fijada no acepta, acabas teniendo que actualizar Starlette de todos modos, según el calendario de otra persona.
Esta tarea práctica dura diez minutos. Ejecuta pip list (o revisa tu archivo de bloqueo) y comprueba las versiones resueltas de python-multipart, jinja2y itsdangerous, no solo la versión de Starlette en sí.
Tus opciones cuando Starlette llegue al final de su vida útil
Así que tu versión de Starlette ha quedado obsoleta, o va por ese camino. ¿Cuáles son tus opciones realistas de cara al futuro?
Hay tres opciones, y la más adecuada depende del tamaño de tu aplicación, la cobertura de las pruebas, la versión de Python, el plazo de migración y tu tolerancia al riesgo. Dos de ellas implican una planificación real, costes y riesgos. La tercera, el soporte ampliado, ofrece una cobertura de seguridad provisional cuando no resulta viable realizar una actualización inmediata.
Opción 1: Actualizar a una versión compatible de Starlette 1.x
La solución recomendada por el equipo de desarrollo es actualizar a una versión 1.x de Starlette que cuente actualmente con soporte técnico, disponer de una cobertura de seguridad activa y beneficiarse de una línea de versiones correctamente gestionada de cara al futuro.
Y Starlette 1.x es realmente mejor. El proyecto se ha deshecho de años de API obsoletas acumuladas, ha adoptado un sistema de versionado semántico estable y ha seguido publicando correcciones desde entonces: la versión 1.0.1 corrige los errores de encabezados malformados al construir request.url, la 1.1.0 rechaza las rutas absolutas en StaticFiles.lookup_path, y la versión 1.3.1 impone max_fields y max_part_size en el analizador de formularios. Para los equipos que empiezan desde cero o que mantienen bases de código activas, esta es sin duda la opción más adecuada a largo plazo.
Pero actualizar una aplicación de producción que está vinculada a una versión anterior 0.x implica lidiar con todo esto:
Decoradores eliminados: el @app.route(), @app.websocket_route(), @app.exception_handler()y @app.middleware() han desaparecido. Las rutas se trasladan a Route y WebSocketRoute en el archivo parámetro «routes» , y los controladores se trasladan a la sección exception_handlers y middleware de la aplicación. En una aplicación grande con muchas rutas y registros de middleware, esto afecta a un gran número de archivos.
API de ciclo de vida eliminadas: la on_startup y on_shutdown , así como la función @app.on_event() , add_event_handler()y Router.startup()/Router.shutdown() se han eliminado. Las aplicaciones que los utilicen deben migrar a la interfaz «lifespan» .
Cambios en las plantillas: Jinja2Templates ya no admite **env_options (pasar un entorno preconfigurado mediante env ), la antigua TemplateResponse(name, context) ha desaparecido, ahora ahora debe estar instalado para poder importar la clase, y el autoescape está activado por defecto.
Cambios en la gestión de sesiones: Starlette 1.0 ha incorporado el seguimiento del acceso y la modificación de sesiones en SessionMiddleware. No hay garantía de que nada vaya a dejar de funcionar, pero si tu aplicación presenta un comportamiento de sesión delicado, incluye los flujos de sesión en el plan de pruebas de regresión en lugar de darlo por sentado.
Requisitos de ejecución: Starlette 1.x requiere Python 3.10 o posterior. La compatibilidad con Python 3.9 se eliminó en la versión 0.50.0 y la de 3.8 en la 0.45.0. Si utilizas alguna de estas versiones, tendrás que actualizar primero el entorno de ejecución, lo que conlleva sus propias implicaciones de compatibilidad para tu árbol de dependencias más amplio; además, ambas versiones de Python ya han llegado al final de su ciclo de vida, por lo que se trata de dos problemas que se solapan, no de uno solo.
Complejidad de la actualización con FastAPI: si utilizas FastAPI, la actualización no es tan sencilla como simplemente actualizar Starlette en tu archivo de requisitos. FastAPI especifica rangos de versiones compatibles de Starlette, lo que significa que a menudo tendrás que actualizar ambos a la vez y comprobar que ambos funcionan según lo esperado con el código de tu aplicación.
En el caso de una aplicación pequeña y bien probada, se trata de un sprint específico. Sin embargo, en el caso de un sistema más grande, con un amplio middleware, una gestión compleja de sesiones y patrones acumulados a lo largo de años, hay que contar con una planificación minuciosa, pruebas exhaustivas y un riesgo real de que se produzcan regresiones sutiles bajo la carga de producción.
Opción 2: Migrar a otro marco de trabajo
Hay equipos que ven una versión de la Starlette al final de su vida útil y piensan: «Quizá sea el momento de replanteárselo».
Si estás utilizando Starlette sin modificaciones, vale la pena plantearse FastAPI, ya que añade validación y serialización sobre la misma base en la que ya te apoyas. Litestar es otro marco ASGI moderno con una filosofía de diseño diferente. Para los equipos que estén barajando un cambio arquitectónico más amplio, existen opciones viables.
Pero no nos engañemos sobre lo que implica la migración de un marco de trabajo. Es posible que tengas que reescribir los controladores de rutas adaptándolos a la API del nuevo marco, refactorizar el middleware y la gestión de excepciones (que varían mucho de un marco a otro), actualizar tu infraestructura de pruebas, comprobar que la configuración de tu servidor ASGI sigue funcionando correctamente y mantener el sistema actual en funcionamiento mientras se desarrolla el nuevo.
Las ventajas arquitectónicas a largo plazo pueden justificar esa inversión. Sin embargo, los plazos y los costes pueden superar con creces la estimación inicial, sobre todo cuando la aplicación presenta un comportamiento muy específico del marco de trabajo. Y el periodo en el que el entorno de producción sigue funcionando con la versión antigua mientras se lleva a cabo la migración es precisamente el periodo de vulnerabilidad que se intentaba eliminar.
Opción 3: Asistencia técnica ampliada de terceros
Existe una tercera vía a la que no se le presta la atención que merece: el soporte de seguridad ampliado que ofrecen las empresas especializadas en este problema.
TuxCare ofrece soporte técnico de ciclo de vida ilimitado para las versiones de Starlette que han llegado al final de su vida útil. En lugar de verte obligado a realizar una migración para la que aún no estás preparado, o de dejar tus aplicaciones desprotegidas mientras la planificas, puedes seguir utilizando tu versión actual con cobertura continua de parches de seguridad.
La lógica es sencilla: ganas tiempo y control. Tiempo para planificar una actualización bien meditada cuando mejor se adapte a tu hoja de ruta. Control sobre tu calendario de migración, en lugar de verte obligado a actuar por la publicación de un CVE que te obliga a tomar medidas en el peor momento posible.
En concreto:
Si utilizas una versión 0.4x, ya estás en Python 3.10 o superior, tienes una cobertura de pruebas decente y solo unos pocos componentes de middleware personalizados, entonces actualízate ya a la versión 1.x actual. Es una tarea rápida, no un proyecto.
Si utilizas una versión 0.2x o 0.3x con Python 3.8 o 3.9, entonces realiza primero la actualización del entorno de ejecución y utiliza el soporte ampliado para cubrir la brecha de seguridad mientras lo haces.
Si ya te has comprometido a cambiar a otro marco de trabajo, entonces utiliza el soporte ampliado para cubrir el periodo de migración, en lugar de quedarte sin protección durante dos trimestres.
Si quedan unas semanas para el plazo de cumplimiento y la migración está prevista para dentro de unos meses, entonces la extensión del soporte es la única opción que satisface ambos requisitos, y después puedes actualizar según tu propio calendario.
El verdadero coste de precipitarse al actualizar el ciclo de vida de un Starlette
Hablemos de lo que ocurre cuando los equipos migran precipitadamente una aplicación ASGI en producción porque las advertencias de fin de vida útil finalmente alcanzan un nivel crítico en el panel de control de seguridad.
Imagina un equipo de SaaS de 40 personas que utiliza FastAPI 0.95 y Starlette 0.36, con Python 3.9 como base, 180 rutas, cuatro middlewares personalizados y un plazo de cumplimiento que vence en tres semanas. Cuando la actualización se comprime en ese plazo, surgen los problemas previsibles:
Aumento de la carga de soporte: los sutiles cambios de comportamiento que no salieron a la luz durante las pruebas empiezan a aparecer en producción. Una API obsoleta que finalmente se ha eliminado, un caso extremo de gestión de sesiones que ahora se comporta de forma diferente, una interacción con el middleware que no estaba cubierta por tu conjunto de pruebas. Tu equipo de soporte se ve desbordado por las incidencias, y la mitad de ellas se remontan a la migración.
Inestabilidad del sistema: los problemas de compatibilidad con async son muy difíciles de depurar. Quizás una dependencia que funcionaba bien con tu versión anterior de AnyIO ahora presente sutiles diferencias de sincronización bajo carga. Quizás una cadena de middleware se comporte de forma diferente cuando cambia el ciclo de vida de la solicitud. Estos son los problemas que generan alertas a altas horas de la noche y dejan muy descontentos a los ingenieros de guardia.
Acumulación de deuda técnica: en el afán por cumplir con los requisitos, se pospone la refactorización adecuada. Se añaden soluciones provisionales de compatibilidad con comentarios del tipo «ya lo arreglaremos más adelante». Seis meses después de la migración, técnicamente estás en la versión 1.x, pero ejecutas un código lleno de soluciones provisionales que nadie tiene tiempo de abordar.
Sobrecostes: la estimación inicial era de dos semanas. Cinco semanas después, sigues persiguiendo regresiones. El contratista al que se ha recurrido para ayudar sigue facturando. Se han pospuesto algunas funcionalidades. El coste de oportunidad que supone que los ingenieros sénior se dediquen a depurar interacciones asíncronas de middleware en lugar de desarrollar nuevas capacidades se acumula rápidamente.
La actualización es la solución adecuada a largo plazo. Una actualización precipitada, impulsada por la presión de cumplir con la normativa, es una forma de fracaso concreta y totalmente predecible. No son lo mismo.
Mantén Starlette a salvo mientras planificas la actualización: el soporte de ciclo de vida ilimitado de TuxCare
Aquí es donde el servicio «Endless Lifecycle Support» (ELS) de TuxCare para Starlette cambia las reglas del juego.
TuxCare lleva más de una década dedicándose a esto, proporcionando parches de seguridad para sistemas operativos, entornos de ejecución, bibliotecas y marcos de aplicaciones que han dejado de recibir soporte, en entornos de producción empresariales.
¿Qué diferencia al enfoque de TuxCare?
Cobertura de la pila de dependencias: TuxCare no solo aplica parches a Starlette. La cobertura se extiende a las dependencias directas y transitivas de Starlette sin coste adicional, lo cual es importante dado que la fuente más probable de problemas en una pila ASGI es un analizador sintáctico de formularios o un motor de plantillas situado varias capas más abajo.
Aplicación automatizada de parches con validación por parte de expertos: TuxCare realiza un seguimiento de los CVE las 24 horas del día a través del NVD, los avisos de seguridad de los proveedores y los avisos de seguridad de GitHub. Cuando aparece un CVE relevante, las correcciones se retroaplican mediante automatización algorítmica y asistida por IA con validación por expertos; a continuación, se comprueba su integridad, funcionalidad y regresiones, se firman y se publican en los repositorios de TuxCare. Si quieres conocer los detalles, lee el informe técnico de TuxCare sobre su proceso de aplicación de parches de código abierto.
Se adapta a tu flujo de trabajo actual: Los paquetes ELS para Starlette se distribuyen a través de pip desde los repositorios alojados en TuxCare, por lo que se instalan mediante el flujo de trabajo de paquetes y CI/CD que ya utilizas. No es necesario que modifiques tu proceso ni que vuelvas a formar a tu equipo.
Respuesta basada en el SLA: los compromisos relativos a la entrega de parches y a la asistencia técnica se definen en el acuerdo de nivel de servicio correspondiente, por lo que puedes planificar tus acciones en función de un calendario contratado, en lugar de esperar a que alguien publique, en algún momento, una versión retrocompatible.
Previsibilidad de los costes: la ampliación del soporte técnico puede resultar más económica que acelerar una migración compleja, una vez que se tienen en cuenta el tiempo de ingeniería a tarifas reales, los ciclos de pruebas, los honorarios de los contratistas, el posible tiempo de inactividad y el retraso en la implementación de nuevas funciones. Además, se trata de una cifra conocida para un plazo determinado, lo que resulta más fácil de defender en una reunión sobre el presupuesto que una estimación de migración sin plazos definidos. Solicita un presupuesto y compáralo con tus propias cifras.
Cumplimiento normativo y transparencia: cada versión incluye información sobre qué componentes se han parcheado y qué CVE se han solucionado, para que puedas ver qué elementos de tu lista de materiales de software ya se han solucionado. Esa documentación sirve de base para la recopilación de pruebas en evaluaciones de PCI DSS, revisiones de SOC 2 y procesos internos de gestión de vulnerabilidades.
Cómo empezar
Si estás utilizando una versión de Starlette que ha llegado al final de su ciclo de vida y quieres saber qué cobertura hay actualmente, TuxCare mantiene un rastreador de CVE en tiempo real en el que puedes ver qué vulnerabilidades ya han sido corregidas.
¿Quieres conocer todos los detalles sobre las versiones compatibles, los precios y la implementación? Visita el servicio de soporte de ciclo de vida ilimitado de TuxCare para Starlette para obtener más detalles, incluyendo qué versiones de Starlette están cubiertas actualmente y cómo solicitar una que aún no figure en la lista.
No dejes que el fin de la vida útil de Starlette ponga en riesgo tus sistemas
Starlette ha tenido una trayectoria impresionante. Sentó las bases del desarrollo web asíncrono moderno en Python, es la base de FastAPI, lo utiliza el SDK de Python MCP y se descarga casi 10 millones de veces al día. Alcanzar la versión 1.0.0 tras casi ocho años supone un auténtico hito para el proyecto, y la rama 1.x se mantiene de forma activa.
Pero si estás utilizando una versión antigua en entorno de producción, ya sea una versión comprendida entre 0.30 y 0.39 o una posterior, entre 0.40 y 0.49, que «siga funcionando» no es lo mismo que «siga siendo segura».
Esto no tiene por qué suponer una carrera contrarreloj. Tienes opciones reales. Puedes planificar una actualización bien meditada de la versión actual de Starlette 1.x cuando se ajuste a la hoja de ruta de tu equipo. Puedes evaluar si otro marco de trabajo tiene sentido desde el punto de vista arquitectónico. O puedes recurrir al soporte ampliado para mantener la seguridad y el cumplimiento normativo a un nivel estable mientras tomas esas decisiones según tu propio calendario, en lugar de según el de una auditoría de seguridad.
Los equipos que gestionan bien esta situación detectan el riesgo a tiempo, conocen las opciones disponibles y toman decisiones deliberadas, en lugar de reactivas, basándose en su arquitectura, sus recursos disponibles y sus plazos de cumplimiento normativo.
Si en estos momentos estás considerando una versión de Starlette que está llegando al final de su ciclo de vida, merece la pena que te informes sobre lo que ofrece TuxCare. Quizá descubras que asegurar lo que ya has creado, mientras planificas la actualización que realmente deseas, es un mejor paso a seguir que precipitarte a realizar una migración para la que aún no estás preparado.
Visita el servicio de soporte de ciclo de vida ilimitado de TuxCare para software de código abierto para descubrir cómo el soporte ampliado puede proteger los componentes compatibles de toda su pila de código abierto durante todo el tiempo que lo necesite.
