Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Starlette ne publie pas de cycle de vie de support et n'assure pas la maintenance des anciennes branches de version ; par conséquent, les correctifs de sécurité sont intégrés dans les nouvelles versions plutôt que d'être rétroportés. Ainsi, toute application ASGI qui reste liée à une ancienne version expose son environnement de production à ce risque.
- Les migrations effectuées dans la précipitation entraînent des dysfonctionnements dans les piles de middleware, des problèmes de compatibilité asynchrone, une instabilité du système et des dépassements budgétaires, ce qui peut faire de la prolongation du support provisoire l'option la plus prévisible.
- Les options d'assistance étendue, telles que le service « Endless Lifecycle Support » de TuxCare, garantissent une protection continue des versions de Starlette en fin de vie, tout en vous permettant de planifier vos mises à niveau selon votre propre calendrier, et non selon celui d'un outil de détection des vulnérabilités.
Si vous développez des services Python asynchrones, il y a de fortes chances que Starlette fasse partie de votre pile technologique, que vous en soyez conscient ou non. Il se peut qu’il s’exécute directement en tant que framework ASGI. Mais il est plus probable qu’il alimente discrètement l’application FastAPI que votre équipe a développée il y a deux ans, celle qui gère l’authentification, les téléchargements de fichiers ou la moitié de vos outils internes. Quoi qu’il en soit, lorsque Starlette arrivera en fin de vie, les risques ne seront pas seulement théoriques.
De nombreuses équipes ne se rendent même pas compte que Starlette figure dans leur arborescence de dépendances. Qu’il ait été installé directement ou intégré de manière transitive via FastAPI, il fonctionne si discrètement qu’il passe inaperçu jusqu’à ce qu’une divulgation de CVE ou un audit de sécurité le mette sous les feux de la rampe.
Voyons donc ce que la fin de la gamme 0.x de Starlette implique pour votre environnement de production et, surtout, ce que vous pouvez concrètement faire pour y faire face sans bouleverser votre feuille de route technique.
Comment fonctionnent réellement les sorties « Starlette » ?
Avant d'aborder la question « Bon, alors, qu'est-ce qu'on fait maintenant ? », il est utile de comprendre comment Starlette gère le cycle de vie de ses versions, car cela diffère quelque peu de ce à quoi vous pourriez vous attendre.
Starlette a été créé en juin 2018 par Kim Christie et a passé plusieurs années dans une longue lignée de versions 0.x que la communauté a pris l’habitude d’appeler « ZeroVer ». Aujourd’hui, il est téléchargé près de 10 millions de fois par jour, sert de base à FastAPI et constitue une dépendance du SDK Python MCP. Pendant près de huit ans, cependant, elle a été distribuée sous la forme 0.x.y, ce qui signifiait l’absence de cycle officiel de dépréciation, de désignation LTS et de politique de fin de vie publiée liée aux numéros de version. Le projet a continué à être distribué, et les anciennes versions ont tout simplement cessé de faire l’objet d’une attention particulière.
Tout cela a changé le 22 mars 2026, lorsque Starlette a atteint la version 1.0.0 après une version candidate publiée en février. Ce fut une véritable étape décisive : des années d’API obsolètes ont été supprimées, l’orientation du projet a été officialisée et la version sémantique a enfin été mise en place. La branche 1.x n’a cessé d’évoluer depuis lors, passant par les versions 1.0.1, 1.1.0, 1.2.x et 1.3.1 en juin 2026 ; ainsi, l’objectif de mise à jour est aujourd’hui la version 1.x actuelle plutôt que la version 1.0.0 elle-même.
Voici ce qui importe pour tous ceux qui utilisent encore une version 0.x. Starlette ne publie pas de cycle de vie de support et ne assure pas la maintenance des anciennes branches de version. Les correctifs sont intégrés dans les nouvelles versions. Ainsi, si vous utilisez une version 0.x obsolète, la question pratique n’est pas de savoir si la date officielle de fin de vie (EOL) est dépassée, mais si vous pouvez vous attendre à ce qu’un correctif de sécurité soit rétroporté vers la version que vous avez figée. Vous ne devriez pas.
De très nombreuses applications en production sont par ailleurs verrouillées sur des versions 0.x spécifiques, souvent de manière indirecte, via les plages de versions compatibles de FastAPI. Les équipes qui n’ont pas revu leurs fichiers de dépendances depuis un certain temps peuvent avoir pris un retard considérable. Une application verrouillée sur Starlette 0.27.0, un verrouillage très courant dans les anciennes versions de FastAPI, accuse un retard de plus de vingt versions mineures par rapport à la version 0.50.0 et est antérieure à deux correctifs de sécurité documentés.
Contrairement à Node.js, avec ses branches LTS, ou à CPython, dont la durée de prise en charge est documentée à cinq ans, Starlette ne dispose d'aucune branche de maintenance sur laquelle s'appuyer. Concrètement, les corrections sont intégrées dans les nouvelles versions, et non dans celle que vous utilisez actuellement.
Ce que la fin de vie (EOL) de Starlette signifie réellement pour votre environnement de production
Bon, disons qu'une version ne suscite plus d'intérêt. Votre application ASGI fonctionne toujours, les requêtes continuent d'affluer et tout semble aller pour le mieux. Pourquoi s'inquiéter ?
En effet, la découverte de vulnérabilités ne s'arrête pas lorsque l'attention des développeurs en amont se porte ailleurs. Les pirates ne consultent pas le journal des modifications de Starlette avant de tester vos terminaux, et les chercheurs en sécurité continuent de découvrir des failles dans des versions largement déployées, en particulier celles qui sous-tendent une grande partie des applications web Python.
Les anciennes versions de Starlette ont déjà été touchées par plusieurs problèmes très graves, et cette tendance est suffisamment récurrente pour inquiéter tous ceux qui continuent à les utiliser.
CVE-2024-47874 (CVSS 4.0 : 8,7, Élevé) : une vulnérabilité de type déni de service affectant toutes les versions de Starlette antérieures à la version 0.40.0. Le problème réside dans la manière dont Starlette gère le format les parties « multipart/form-data » qui ne comportent pas de nom de fichier. Celles-ci sont traitées comme des champs de texte et mises en mémoire tampon sans limite de taille. Un attaquant peut envoyer des champs de formulaire d’une taille arbitrairement grande, ce qui provoque l’épuisement de la mémoire de Starlette en raison d’allocations et d’opérations de copie excessives. L’envoi simultané de plusieurs requêtes de ce type peut rendre un service pratiquement inutilisable, même lorsqu’un proxy inverse impose des limites globales sur la taille des requêtes. Cette vulnérabilité affecte toute application développée avec Starlette ou FastAPI qui accepte des requêtes de formulaire, ce qui représente une surface d’impact très étendue. Corrigée dans la version 0.40.0.
CVE-2025-62727 (CVSS 3.1 : 7,5, Élevé) : une vulnérabilité de type déni de service affectant Starlette des versions 0.39.0 à 0.49.0. Un attaquant non authentifié peut envoyer un en-tête HTTP Range spécialement conçu qui déclenche un traitement en temps quadratique dans la méthode FileResponse de Starlette. Chaque requête malveillante consomme un temps CPU disproportionné, et des requêtes répétées ou simultanées peuvent dégrader la disponibilité de tout point de terminaison servant des fichiers, y compris tout ce qui utilise StaticFiles ou FileResponse . Problème résolu dans la version 0.49.1.
Ces deux-là ne constituent pas non plus la liste complète. La version 0.27.0 de Starlette a corrigé une faille de traversée de chemin dans StaticFiles, tandis que la version 0.25.0 a ajouté des limites au nombre de parties pouvant composer une requête multipart. Toute version antérieure à ces versions présente encore ces problèmes aujourd’hui.
Il ne s’agit pas là de cas marginaux ni d’exploits théoriques, et ces vulnérabilités ne se limitent pas à Starlette. IBM a publié des bulletins de sécurité concernant des produits intégrant des versions vulnérables de Starlette, notamment Maximo Application Suite, App Connect Enterprise Certified Container et Planning Analytics Workspace. Du côté de vLLM, des contributeurs ont signalé un problème demandant une mise à jour urgente des dépendances après avoir constaté que le projet était bloqué à la version 0.46.2, qui se trouvait dans la plage concernée par la faille CVE-2025-62727.
Maintenant, voici la vérité sur ces deux CVE : chacune d’entre elles a été corrigée en amont alors que la branche 0.x était encore active. C’est exactement là où réside le problème. Le correctif a été intégré dans une version 0.x plus récente, et non sous forme de backport vers la version que vous avez figée ; désormais que le développement est passé à la branche 1.x, la prochaine vulnérabilité divulguée sera corrigée dans la branche 1.x. Sur une version obsolète, une vulnérabilité nouvellement divulguée reste exposée jusqu’à ce que vous effectuiez une mise à jour, que vous appliquiez vous-même le correctif via un backport, ou que vous obteniez un correctif auprès d’une autre source.
Les référentiels de conformité ont leur propre point de vue sur cette lacune. La norme PCI DSS v4.0.1 (exigence 6.3.3) impose l’installation des correctifs de sécurité critiques dans un délai d’un mois à compter de leur publication, les autres vulnérabilités devant être traitées selon le calendrier défini par votre processus documenté de classement des risques. Les composants non pris en charge peuvent également soulever des questions lors des audits SOC 2 concernant la gestion des vulnérabilités et l’efficacité de vos contrôles ; ils peuvent alors nécessiter une stratégie documentée de traitement des risques et la mise en place de contrôles compensatoires plutôt qu’une réponse simple et claire.
Le risque caché : votre pile de dépendances
L'exposition ne se limite pas au code propre à Starlette. La dépendance qui mérite le plus d'attention est python-multipart, sur lequel repose en réalité l’analyse des formulaires de Starlette. Il comportait sa propre vulnérabilité de déni de service, CVE-2024-53981 (CVSS 4.0 : 8,7, Élevé), corrigée dans la version 0.0.18 – et Starlette n’a relevé sa version minimale à 0.0.18 qu’à partir de la version 0.42.0. Si vous êtes bloqué en dessous de cette version, il est fort probable que la version de votre analyseur, telle qu’elle a été résolue, soit antérieure au correctif. Jinja2 pour les modèles et itsdangerous pour la signature des cookies de session entrent dans la même catégorie : des composants optionnels qui font l’objet de leurs propres avis de sécurité et que de nombreuses équipes n’auditent jamais séparément.
AnyIO et typing-extensions constituent un problème distinct. Aucun des deux ne présente un risque CVE significatif, et typing-extensions n’est utilisé que sur les versions de Python antérieures à la 3.10 dans les versions récentes. Les anciennes versions de Starlette limitent les versions de ces paquets que vous pouvez résoudre. Cela ne les rend pas vulnérables, mais complique la correction : si un correctif pour un autre élément de votre arborescence nécessite une version plus récente que votre Starlette « épinglée » n’accepte pas, vous finissez par effectuer la mise à jour de Starlette de toute façon, selon le calendrier imposé par quelqu’un d’autre.
Cette opération pratique prend dix minutes. Exécutez pip list (ou consultez votre fichier de verrouillage) et vérifiez les versions résolues de python-multipart, jinja2et itsdangerous, et pas seulement la version de Starlette elle-même.
Vos options lorsque Starlette arrive en fin de vie
Votre version de Starlette est donc dépassée, ou en passe de l'être. Quelles sont les pistes réalistes qui s'offrent à vous pour aller de l'avant ?
Il en existe trois, et le choix de la solution la plus adaptée dépend de la taille de votre application, de la couverture des tests, de la version de Python, du calendrier de migration et de votre tolérance au risque. Deux d'entre elles impliquent une véritable planification, des coûts et des risques. La troisième, le support étendu, permet de bénéficier d'une couverture de sécurité provisoire lorsqu'une mise à niveau immédiate n'est pas envisageable.
Option 1 : Passer à une version prise en charge de Starlette 1.x
La solution recommandée par les développeurs est de passer à une version 1.x de Starlette actuellement prise en charge, afin de bénéficier d'une couverture de sécurité active et d'une ligne de versions correctement gérée à l'avenir.
Et Starlette 1.x est véritablement meilleure. Le projet s'est débarrassé des API obsolètes accumulées au fil des années, a adopté un système de numérotation sémantique stable et n'a cessé de publier des correctifs depuis : la version 1.0.1 gère les en-têtes lors de la construction de request.url, la version 1.1.0 rejette les chemins absolus dans StaticFiles.lookup_path, tandis que la version 1.3.1 applique la valeur max_fields et max_part_size dans l'analyseur de formulaires. Pour les équipes qui partent de zéro ou qui gèrent des bases de code actives, c'est clairement la bonne solution à long terme.
Mais mettre à niveau une application de production qui utilise encore une ancienne version 0.x implique de devoir gérer tout cela :
Décorateurs supprimés : le @app.route(), @app.websocket_route(), @app.exception_handler(), et @app.middleware() ont disparu. Les routes sont désormais gérées par Route et WebSocketRoute dans le fichier routes , et les gestionnaires sont transférés vers les exception_handlers et middleware de l'application. Dans une application volumineuse comportant de nombreux itinéraires et enregistrements de middleware, cela affecte un grand nombre de fichiers.
API de cycle de vie supprimées : la on_startup et on_shutdown , ainsi que la méthode décorateur @app.on_event() , la méthode add_event_handler()et Router.startup()/Router.shutdown() ont toutes été supprimées. Les applications qui les utilisent doivent migrer vers la interface « lifespan » .
Modifications apportées aux modèles : Jinja2Templates n'accepte plus **env_options (passer un environnement préconfiguré via env à la place), l'ancienne méthode TemplateResponse(name, context) a disparu, jinja2 doit désormais être installé pour pouvoir importer la classe, et l'autoescape est activé par défaut.
Modifications apportées à la gestion des sessions : Starlette 1.0 a ajouté un suivi des accès et des modifications apportées aux sessions dans SessionMiddleware. Rien ici ne devrait causer de dysfonctionnement, mais si votre application présente un comportement sensible en matière de sessions, intégrez les flux de session dans votre plan de tests de régression plutôt que de partir d'hypothèses.
Configuration requise : Starlette 1.x nécessite Python 3.10 ou une version ultérieure. La prise en charge de Python 3.9 a été supprimée à partir de la version 0.50.0 et celle de Python 3.8 à partir de la version 0.45.0. Si vous utilisez l’une ou l’autre de ces versions, vous devrez d’abord procéder à une mise à niveau de l’environnement d’exécution, ce qui aura des implications en matière de compatibilité pour l’ensemble de votre arborescence de dépendances. De plus, ces deux versions de Python sont elles-mêmes déjà en fin de vie, ce qui représente donc deux problèmes qui se chevauchent, et non un seul.
Complexité de la mise à niveau avec FastAPI : si vous utilisez FastAPI, la mise à jour ne se résume pas simplement à mettre à jour Starlette dans votre fichier de dépendances. FastAPI spécifie des plages de versions compatibles de Starlette, ce qui signifie que vous devez souvent mettre à jour les deux en même temps et vérifier qu’elles se comportent toutes deux comme prévu avec le code de votre application.
Pour une petite application ayant fait ses preuves, il s'agit d'un sprint ciblé. En revanche, pour un système plus vaste comportant de nombreux intergiciels, une gestion complexe des sessions et des modèles accumulés au fil des années, il faudra prévoir une planification minutieuse, des tests approfondis et tenir compte du risque réel de régressions subtiles sous la charge de production.
Option 2 : Migrer vers un autre framework
Certaines équipes, en voyant une version de la Starlette en fin de vie, se disent : « C'est peut-être le moment de revoir notre position. »
Si vous utilisez Starlette « à l'état brut », FastAPI mérite d'être pris en considération : il ajoute des fonctionnalités de validation et de sérialisation tout en s'appuyant sur la même base que celle sur laquelle vous vous appuyez déjà. Litestar est un autre framework ASGI moderne, doté d'une philosophie de conception différente. Pour les équipes qui envisagent une refonte plus large de leur architecture, il existe de réelles alternatives.
Mais ne nous faisons pas d’illusions sur ce qu’implique la migration vers un nouveau framework. Vous devrez peut-être réécrire les gestionnaires de routes en fonction de l’API du nouveau framework, refactoriser les middlewares et la gestion des exceptions (qui varient considérablement d’un framework à l’autre), mettre à jour votre infrastructure de test, vérifier que la configuration de votre serveur ASGI fonctionne toujours correctement, et maintenir le système existant opérationnel pendant le développement du nouveau.
Les avantages architecturaux à long terme peuvent justifier cet investissement. Mais le délai et le coût peuvent largement dépasser les estimations initiales, en particulier lorsque l'application présente de nombreux comportements spécifiques au framework. Et la période pendant laquelle la production continue de fonctionner sur l'ancienne version alors que la migration est en cours correspond exactement à la fenêtre de vulnérabilité que vous cherchiez à combler.
Option 3 : Assistance étendue par un tiers
Il existe une troisième solution à laquelle on ne s'intéresse pas assez : le support de sécurité prolongé proposé par des entreprises spécialisées dans ce domaine.
TuxCare propose une assistance tout au long du cycle de vie pour les versions de Starlette arrivées en fin de vie. Ainsi, vous n'êtes pas contraint de procéder à une migration pour laquelle vous n'êtes pas prêt, ni de laisser vos applications exposées pendant que vous planifiez celle-ci : vous continuez à utiliser votre version actuelle tout en bénéficiant d'une couverture continue en matière de correctifs de sécurité.
Le raisonnement est simple : vous gagnez en temps et en maîtrise. Du temps pour planifier une mise à niveau mûrement réfléchie, au moment qui correspond à votre feuille de route. La maîtrise de votre calendrier de migration, au lieu d’être subordonné à la publication d’une vulnérabilité CVE qui vous oblige à agir au pire moment possible.
Concrètement, donc :
Si vous utilisez une version 0.4x, que vous êtes déjà sous Python 3.10 ou une version ultérieure, que votre couverture de test est satisfaisante et que vous n'utilisez qu'une poignée de middlewares personnalisés, alors passez dès maintenant à la version 1.x actuelle. C’est un sprint, pas un projet.
Si vous utilisez une version 0.2x ou 0.3x avec Python 3.8 ou 3.9, alors effectuez d’abord la mise à niveau du runtime et utilisez le support étendu pour combler la faille de sécurité pendant cette opération.
Si vous vous êtes déjà engagé à migrer vers un autre framework, alors recourez à la prise en charge prolongée pour couvrir la période de migration plutôt que de rester exposé pendant deux trimestres.
Si la date limite de mise en conformité est dans quelques semaines et la migration dans quelques mois, alors le support prolongé est la seule option qui réponde à ces deux exigences, et vous effectuez la mise à niveau par la suite selon votre propre calendrier.
Le coût réel d'une mise à niveau précipitée de Starlette vers la fin de vie du produit
Voyons ce qui se passe lorsque des équipes procèdent à une migration précipitée d'une application ASGI en production parce que les alertes de fin de vie ont finalement atteint un seuil critique sur le tableau de bord de sécurité.
Imaginez une équipe SaaS de 40 personnes travaillant avec FastAPI 0.95 et Starlette 0.36, sous Python 3.9, avec 180 routes, quatre middlewares personnalisés et une échéance de mise en conformité dans trois semaines. Lorsque la mise à niveau doit être condensée dans ce délai, les problèmes prévisibles surgissent :
Augmentation de la charge de support : les changements comportementaux subtils qui n’étaient pas apparus lors des tests commencent à se manifester en production. Une API obsolète qui a finalement été supprimée, un cas limite de gestion des sessions qui se comporte désormais différemment, une interaction avec le middleware qui n’était pas couverte par votre suite de tests. Votre équipe d’assistance est submergée de tickets, dont la moitié est liée à la migration.
Instabilité du système : les problèmes de compatibilité asynchrone sont particulièrement difficiles à déboguer. Il se peut qu’une dépendance qui fonctionnait parfaitement avec votre version précédente d’AnyIO présente désormais de subtiles différences de synchronisation sous charge. Il se peut également qu’une chaîne de middleware se comporte différemment lorsque le cycle de vie de la requête change. Ce sont ces problèmes-là qui génèrent des alertes tard dans la nuit et des ingénieurs d’astreinte très mécontents.
Accumulation de dette technique : dans la précipitation pour se mettre en conformité, la refactorisation adéquate est reportée. Des solutions de compatibilité provisoires sont ajoutées, accompagnées de commentaires du type « on s’en occupera plus tard ». Six mois après la migration, vous êtes techniquement en version 1.x, mais vous exploitez une base de code truffée de solutions de contournement que personne n’a le temps de corriger.
Dépassements budgétaires : l'estimation initiale était de deux semaines. Cinq semaines plus tard, vous êtes toujours en train de traquer les régressions. Le prestataire appelé en renfort continue de facturer ses services. Les fonctionnalités ont été reportées. Le coût d'opportunité lié au fait que des ingénieurs seniors passent leur temps à déboguer des interactions asynchrones entre middlewares au lieu de développer de nouvelles fonctionnalités s'accumule rapidement.
La mise à niveau constitue la bonne solution à long terme. Une mise à niveau précipitée sous la pression de la conformité est un scénario d'échec bien précis et tout à fait prévisible. Ce ne sont pas deux choses identiques.
Assurer la sécurité de Starlette pendant que vous préparez la mise à niveau : le support à vie de TuxCare
C'est là que le service « Endless Lifecycle Support » (ELS) proposé par TuxCare pour Starlette change la donne.
TuxCare exerce cette activité depuis bien plus d'une décennie, en fournissant des correctifs de sécurité pour les systèmes d'exploitation, les environnements d'exécution, les bibliothèques et les frameworks d'applications en fin de vie, dans les environnements de production des entreprises.
En quoi l'approche de TuxCare est-elle différente ?
Couverture de la pile des dépendances : TuxCare ne se contente pas d’appliquer des correctifs à Starlette. La couverture s’étend aux dépendances directes et transitives de Starlette sans frais supplémentaires, ce qui est important étant donné que la source de problèmes la plus probable dans une pile ASGI est un analyseur de formulaires ou un moteur de modèles situé plusieurs couches plus bas.
Application automatisée des correctifs avec validation par des experts : TuxCare surveille les CVE 24 heures sur 24 via le NVD, les avis de sécurité des éditeurs et les avis de sécurité GitHub. Lorsqu’un CVE pertinent apparaît, les correctifs sont rétroportés à l’aide d’une automatisation algorithmique et assistée par IA, avec validation par des experts, puis testés pour vérifier leur intégrité, leur fonctionnalité et l’absence de régressions, signés et publiés dans les dépôts TuxCare. Pour plus de détails, consultez le livre blanc technique de TuxCare consacré à son processus de correction open source.
S'intègre à votre flux de travail existant : Les paquets ELS pour Starlette sont fournis via pip à partir des dépôts hébergés par TuxCare ; ils s’installent donc via le processus de gestion des paquets et le workflow CI/CD que vous utilisez déjà. Vous n’avez pas besoin de remanier votre pipeline ni de former à nouveau votre équipe.
Réponse conforme au SLA : les engagements en matière de livraison des correctifs et d'assistance sont définis dans le contrat de niveau de service applicable ; vous planifiez donc vos activités en fonction d'un calendrier contractuel plutôt que d'espérer que quelqu'un finisse par publier un portage en arrière.
Prévisibilité des coûts : une assistance prolongée peut s'avérer moins coûteuse que d'accélérer une migration complexe, une fois pris en compte le temps d'ingénierie facturé au tarif réel, les cycles de test, les honoraires des prestataires, les temps d'arrêt potentiels et les retards dans la mise en place des fonctionnalités. Il s'agit également d'un montant fixe pour une durée déterminée, ce qui est plus facile à justifier lors d'une discussion budgétaire qu'une estimation de migration à durée indéterminée. Demandez un devis et comparez-le à vos propres chiffres.
Conformité et transparence : chaque version est accompagnée d’informations indiquant quels composants ont été corrigés et quelles vulnérabilités (CVE) ont été résolues, ce qui vous permet de voir quels éléments de votre nomenclature logicielle ont déjà été traités. Cette documentation facilite la collecte de preuves dans le cadre des évaluations PCI DSS, des audits SOC 2 et des processus internes de gestion des vulnérabilités.
Comment démarrer
Si vous utilisez une version de Starlette en fin de vie et que vous souhaitez connaître la couverture actuellement disponible, TuxCare met à jour un suivi CVE en temps réel où vous pouvez voir quelles vulnérabilités ont déjà été corrigées.
Vous souhaitez avoir une vue d'ensemble des versions prises en charge, des tarifs et de la mise en œuvre ? Rendez-vous sur la page « Endless Lifecycle Support for Starlette » de TuxCare pour plus de détails, notamment sur les versions de Starlette actuellement prises en charge et sur la manière de demander une version qui ne figure pas encore dans la liste.
Ne laissez pas la fin de vie de Starlette mettre vos systèmes en danger
Starlette a connu un succès fulgurant. Il a jeté les bases du développement web asynchrone moderne en Python, est à la base de FastAPI, est utilisé par le SDK Python MCP et est téléchargé près de 10 millions de fois par jour. L'atteinte de la version 1.0.0 après près de huit ans constitue une véritable étape importante pour le projet, et la branche 1.x fait l'objet d'une maintenance active.
Mais si vous utilisez une ancienne version en production, qu’il s’agisse d’une version comprise entre 0.30 et 0.39 ou d’une version plus récente comprise entre 0.40 et 0.49, « ça fonctionne toujours » ne signifie pas pour autant « c’est toujours sécurisé ».
Cela ne signifie pas pour autant que vous deviez agir dans la précipitation. Vous disposez de véritables options. Vous pouvez planifier une mise à niveau mûrement réfléchie de la version actuelle de Starlette 1.x lorsque cela s'inscrit dans la feuille de route de votre équipe. Vous pouvez évaluer si l'adoption d'un autre framework se justifie d'un point de vue architectural. Ou bien vous pouvez recourir au support étendu pour garantir la sécurité et la conformité tout en prenant ces décisions selon votre propre calendrier, et non en fonction des exigences d'un audit de sécurité.
Les équipes qui gèrent bien cette situation identifient le risque dès le début, évaluent les options disponibles et font des choix mûrement réfléchis plutôt que réactifs, en fonction de leur architecture, de leurs ressources disponibles et de leurs délais de mise en conformité.
Si vous envisagez actuellement d'adopter une version de Starlette en fin de vie, cela vaut la peine de vous renseigner sur ce que propose TuxCare. Vous constaterez peut-être que sécuriser ce que vous avez déjà mis en place, tout en planifiant la mise à niveau que vous souhaitez réellement, constitue une meilleure étape suivante que de précipiter une migration pour laquelle vous n'êtes pas encore prêt.
Visitez le service de support à cycle de vie illimité de TuxCare pour les logiciels open source pour découvrir comment une assistance prolongée peut protéger les composants pris en charge de votre pile open source aussi longtemps que vous en avez besoin.
