So sorgen Sie für Sicherheit, nachdem Django das Ende seiner Lebensdauer erreicht hat

Wichtigste Erkenntnisse

• Durch das Ende des Supports für Django sind Sie nicht nur in Django selbst, sondern auch in Abhängigkeiten wie sqlparse ungeschützten, nicht gepatchten Sicherheitslücken (CVEs) ausgesetzt, was die Einhaltung von PCI DSS, HIPAA und SOC 2 gefährden kann.
• Ein Sprung von Django 3.2 oder 4.2 auf 5.2 erfordert ein Upgrade der Python-Laufzeitumgebung und bringt kompatibilitätsbrechende Änderungen mit sich; daher ist eine sorgfältige Planung erforderlich und kein Sprint zur Einhaltung einer Frist.
• TuxCare ELS für Django sorgt dafür, dass Ihre nicht mehr unterstützte Version auf dem neuesten Stand bleibt und alle Anforderungen erfüllt, während Sie die Migration nach Ihrem eigenen Zeitplan durchführen.

Wenn Ihr Python-Anwendungsstack Django für die Webentwicklung umfasst – und die Wahrscheinlichkeit dafür ist groß –, sollten Sie sich mit dem EOL von Django vertraut machen, bevor ein Sicherheitsscanner oder ein Compliance-Audit Sie dazu zwingt, sich damit auseinanderzusetzen.

Seit fast zwei Jahrzehnten ist Django eines der Standard-Frameworks für die Entwicklung von Python-Webanwendungen. Sein „Batteries-included“-Modell vereint ORM, Authentifizierung, Admin-Oberfläche, Formularverarbeitung, Sicherheits-Middleware und andere zentrale Funktionen für Webanwendungen in einem einzigen Framework – genau deshalb setzen so viele Unternehmensteams in der Produktion nach wie vor darauf. Doch diese langfristige Stabilität birgt auch Risiken für den Lebenszyklus. Django 3.2 LTS erreichte im April 2024 das Ende seines Lebenszyklus, Django 4.2 LTS im April 2026, und Nicht-LTS-Versionen wie 4.0, 4.1, 5.0 und 5.1 werden bereits nicht mehr unterstützt. Für alle diese Versionen wurden die Sicherheitspatches vom Upstream eingestellt.

In diesem Artikel wird erläutert, was das Ende des Supports für Django in der Praxis bedeutet, warum die Sicherheitslückenstatistik diese Gefahr konkret macht und wie TuxCare ELS für Django Unternehmen dabei hilft, auf dem neuesten Stand zu bleiben und die Compliance-Anforderungen zu erfüllen, ohne eine überstürzte Migration erzwingen zu müssen, bevor ihre Teams dafür bereit sind.

Was ist Django und warum ist es nach wie vor so weit verbreitet?

Django ist ein hochentwickeltes Python-Web-Framework, das von der Django Software Foundation gepflegt wird. Seine Model-View-Template-Architektur (MVT) trennt Geschäftslogik, Datenzugriff und Darstellung voneinander, sodass Teams wartbare Webanwendungen entwickeln können, ohne die Infrastruktur neu implementieren zu müssen, die jede Webanwendung benötigt. Das Framework verfügt über ein integriertes ORM, ein Migrationssystem, ein Authentifizierungs-Backend, eine Admin-Oberfläche, Formularvalidierung, Schutz vor Cross-Site-Request-Forgery sowie Sicherheits-Middleware – ein umfassender Stack, der Django zum Standard-Python-Webframework für Unternehmen gemacht hat, die Wert auf Zuverlässigkeit und Vollständigkeit legen.

Django ist in den Python-Stacks von Unternehmen fest verankert. Es bildet die Grundlage für Content-Management-Plattformen, Portale für Finanzdienstleistungen, Behördensysteme und E-Commerce-Backends in Branchen, die seit einem Jahrzehnt oder länger auf Python setzen. Genau die Stabilität und Vollständigkeit, die Django attraktiv gemacht haben, tragen auch zu seiner Beständigkeit in der Produktion bei: Anwendungen, die auf einer gut verstandenen Django-Version basieren, kommen selten als Upgrade-Kandidaten in Frage, bis ein CVE-Scanner oder ein Compliance-Audit diesen Druck erzeugt. Genau darin liegt die Django-EOL-Falle.

Was ist der Django-Produktlebenszyklus?

Django folgt einem vorhersehbaren, zeitbasierten Release-Zyklus. Feature-Releases erscheinen etwa alle acht Monate. Jedes Release erhält insgesamt sechzehn Monate lang Sicherheitspatches: acht Monate voller Support, gefolgt von acht Monaten reiner Sicherheitswartung. Eine Ausnahme bildet die Long-Term-Support-Kennzeichnung: Das finale Release jedes Hauptversionszweigs erhält drei volle Jahre Sicherheits-Support. Zu wissen, welche Releases den LTS-Status tragen, ist entscheidend, um das Django-EOL-Risiko in Ihrem gesamten Stack genau einzuschätzen, da Nicht-LTS-Versionen viel schneller das Ende ihrer Lebensdauer erreichen, als Teams typischerweise erwarten.

Django 4.2 LTS, die vorherige Version mit langfristigem Support, erreichte am 7. April 2026 das Ende ihrer Lebensdauer. Django 3.2 LTS erreichte das Ende seiner Lebensdauer im April 2024. Die dazwischen liegenden Nicht-LTS-Versionen (4.0, 4.1, 5.0, 5.1) haben alle bereits früher das Ende ihrer Lebensdauer erreicht, und für einige gibt es seit Jahren keine Upstream-Patches mehr. Jede Organisation, die noch eine dieser Versionen einsetzt, nutzt Software, für die die Django Software Foundation keine Korrekturen mehr bereitstellt, unabhängig davon, welche Probleme entdeckt werden.

Das EOL von Django gilt bedingungslos. Das Django-Projekt bietet keinen kommerziellen erweiterten Support, keine reinen Sicherheits-Wartungsmodi und keine Patch-Backports für frühere Versionen an. Wenn eine Django-Version das Ende ihrer Lebensdauer erreicht, endet der Upstream-Support vollständig – genau diese Lücke soll TuxCare ELS für Django schließen. Das bedeutet, dass jede nach dem Ende der Lebensdauer bekannt gegebene CVE eine dauerhafte, ungepatchte Sicherheitslücke darstellt, es sei denn, ein Anbieter wie TuxCare führt Backports von Korrekturen durch.

CVE-Verlauf: Was die Schwachstellenliste verrät

Das Ende des Lebenszyklus (EOL) von Django bedeutet nicht, dass in den nicht mehr unterstützten Versionen keine Sicherheitslücken mehr entdeckt werden; es bedeutet lediglich, dass diese nicht mehr behoben werden. Das ORM von Django ist ausdrucksstark und leistungsfähig, was jedoch auch bedeutet, dass Fehler bei der Verarbeitung von Benutzereingaben direkt zu SQL-Injection führen können. Die beiden unten aufgeführten CVEs sind im NVD bestätigt und stellen die primäre direkte Sicherheitslücke dar, die das EOL von Django für Unternehmen mit sich bringt, die nicht mehr unterstützte Versionen in der Produktion einsetzen. Sie können den Status der CVEs, die EOL-Django-Versionen betreffen, sowie die verfügbaren Korrekturen über den TuxCare CVE Tracker verfolgen.

CVE-2022-28346: SQL-Injection in Spaltenaliasen von QuerySets

CVE-2022-28346 (NVD CVSS 3.1: 9,8 – Kritisch) ist eine SQL-Injection-Schwachstelle in Djangos ORM, die die Methoden `QuerySet.annotate()`, `aggregate()` und `extra()` betrifft. Wenn Spaltenaliase mittels Wörterbucherweiterung festgelegt werden und ein manipuliertes Wörterbuch als `**kwargs` übergeben wird, validiert oder maskiert Django die Spaltenaliaswerte nicht ausreichend, bevor sie in die generierte SQL-Abfrage interpoliert werden. Ein Angreifer, der den Inhalt des Wörterbuchs beeinflussen kann, kann beliebigen SQL-Code in den Spaltenalias-Teil der Abfrage einschleusen und so Djangos normale Schutzmechanismen für parametrisierte Abfragen umgehen.

CVE-2022-28346 wurde am 11. April 2022 bekannt gegeben; Patches wurden für Django 2.2.28, 3.2.13 und 4.0.4 veröffentlicht. Organisationen, die zum Zeitpunkt der Bekanntgabe Versionen einsetzten, deren Lebensdauer bereits abgelaufen war, erhielten keinen Upstream-Patch. Für die Schwachstelle gibt es einen öffentlich zugänglichen Proof-of-Concept, und sie stellt weiterhin eine konkrete, ausnutzbare Sicherheitslücke auf jeder nicht gepatchten Django-Installation dar.

CVE-2024-42005: SQL-Injection über JSONField in QuerySet.values()

CVE-2024-42005 (CVSS 3.1: 9,8 – Kritisch gemäß Django-Sicherheitshinweis) ist eine SQL-Injection-Schwachstelle in Djangos ORM, die die Methoden `QuerySet.values()` und `values_list()` bei Modellen betrifft, die ein `JSONField` enthalten. Durch das Erstellen spezifischer JSON-Objektschlüssel und deren Übergabe als *arg-Parameter an diese Methoden kann ein Angreifer Django dazu bringen, den bösartigen Schlüssel ohne ordnungsgemäße Bereinigung als Spaltenalias zu verwenden und so beliebiges SQL in die generierte Abfrage einzuschleusen. Der Angriff erfolgt über das Netzwerk, erfordert keine Authentifizierung und weist eine geringe Komplexität auf.

CVE-2024-42005 wurde am 6. August 2024 bekannt gegeben; Patches wurden für Django 4.2.15 und 5.0.8 veröffentlicht. Django 3.2 LTS hatte zum Zeitpunkt der Bekanntgabe bereits sein End-of-Life-Datum im April 2024 überschritten, und Django 4.0 sowie 4.1 waren seit April 2023 bzw. Dezember 2023 nicht mehr unterstützt. Django hat diese EOL-Versionen weder getestet noch gepatcht. Organisationen, die diese Django-EOL-Versionen einsetzen, sind von dieser kritischen SQL-Injection-Sicherheitslücke mit einem CVSS-Wert von 9,8 betroffen, ohne dass es einen offiziellen Behebungsweg seitens des Django-Projekts gibt.

Das Abhängigkeitsrisiko: sqlparse

Django benötigt zwei direkte Laufzeitabhängigkeiten: asgiref und sqlparse. sqlparse enthält CVE-2024-4340 (CVSS 7.5 High), eine Denial-of-Service-Schwachstelle, die ausgelöst wird, wenn sqlparse.parse() eine tief verschachtelte Liste verarbeitet, was einen RecursionError verursacht, der den Parser zum Absturz bringt. Der Fix wurde in sqlparse 0.5.0 veröffentlicht. Unternehmen, die ältere, nicht mehr unterstützte Django-Versionen verwenden, sind möglicherweise auch an sqlparse-Versionen gebunden, die vor diesem Fix veröffentlicht wurden, was die Angriffsfläche, die TuxCare ELS für Django abdeckt, noch vergrößert.

Einhaltung von Vorschriften und gesetzlichen Bestimmungen

Die PCI-DSS-Anforderung 6.3.3 schreibt vor, dass Schwachstellen mit einem CVSS-Wert von 7,0 oder höher innerhalb eines Monats nach ihrer Veröffentlichung behoben werden müssen. CVE-2022-28346 mit einem CVSS-Wert von 9,8 ist seit April 2022 bekannt, und CVE-2024-42005 mit einem CVSS-Wert von 9,8 ist seit August 2024 bekannt. Unternehmen, die Django-EOL-Versionen ohne Patch-Vereinbarung einsetzen, verstoßen in einigen Fällen bereits seit Jahren gegen diese Behebungsfristen. Der Einsatz bekanntermaßen anfälliger, ungepatchter Web-Framework-Komponenten in Anwendungen, die PHI verarbeiten, erfüllt nicht die Anforderungen der HIPAA-Sicherheitsvorschrift zum Schutz vor vernünftigerweise zu erwartenden Bedrohungen. SOC 2 Typ II-Prüfer stufen nicht unterstützte Bibliotheksversionen als Kontrollschwächen ein. Mit ELS für Django können Unternehmen diese Compliance-Verpflichtungen erfüllen, während die Migration nach ihrem eigenen Zeitplan geplant und durchgeführt wird.

Die Risiken einer überstürzten Django-Migration

Der Druck, auf die Ergebnisse zum Ende der Lebensdauer von Django zu reagieren, ist groß. Tools zur Analyse der Softwarezusammensetzung liefern Ergebnisse. Sicherheitsprüfer stellen gezielte Fragen. Compliance-Fristen lassen sich nicht aufgrund von Kapazitätsengpässen in der Entwicklung verschieben. Die Teams, die gut mit dem Ende der Lebensdauer von Django umgehen, sind diejenigen, die den Unterschied verstehen zwischen der Reaktion auf Risiken und der Schaffung neuer Risiken durch überstürztes Handeln.

Was passiert, wenn man es überstürzt?

Wenn Teams die Django-Migration in einen unrealistischen Zeitplan pressen, weil sie unter dem Druck von Compliance- oder Sicherheitsbefund stehen, laufen die Dinge meist auf vorhersehbare Weise schief:

Erhöhte Support-Belastung: Mit jeder neuen Hauptversion von Django werden veraltete Funktionen entfernt, die sich möglicherweise über Jahre hinweg unbemerkt im Code angesammelt haben. Wenn Warnungen vor der Veralterung ignoriert wurden, führten die Entfernungen zu kompatibilitätsbrechenden Änderungen, die erst nach der Bereitstellung zutage traten. Support-Teams werden sofort mit Tickets über fehlerhafte Ansichten, fehlgeschlagene Formularübermittlungen und ORM-Abfragefehler überhäuft, die bei den verkürzten Tests nicht entdeckt wurden.

Systeminstabilität: Das ORM-Verhalten von Django ändert sich zwischen den Hauptversionen auf subtile Weise, die in Unit-Tests nicht immer erkennbar ist. Abfrageergebnisse, die sich aufgrund von Unterschieden in der Sortierung, dem Aggregationsverhalten oder der Verarbeitung von JSON-Feldern ändern, können Fehler auf der Datenebene verursachen, die sich erst unter Produktionslast oder bei bestimmten Datenmustern zeigen – Fehler, die schwer zu reproduzieren und kostspielig zu diagnostizieren sind.

Anhäufung technischer Schulden: In der Eile, die Compliance-Anforderungen zu erfüllen, nehmen Teams Abkürzungen. Veraltete Muster, die eigentlich hätten umgestaltet werden sollen, werden mit Kompatibilitäts-Shims geflickt. Einstellungen, deren Verhalten sich zwischen den Versionen geändert hat, werden auf nicht dokumentierte Weise überschrieben. Das Django-EOL-Problem wird durch diese Workarounds nur aufgeschoben, nicht gelöst, und die aufgelaufenen Schulden verteuern später eine ordnungsgemäße Migration.

Ungeplante Kosten: Notfall-Entwicklungsstunden, verzögerte Feature-Veröffentlichungen und die Opportunitätskosten, die entstehen, wenn Ihre besten Entwickler Migrationskompatibilitätsprobleme beheben, anstatt neue Funktionen zu entwickeln, summieren sich schnell – in der Regel auf einen Betrag, der die Kosten für erweiterte Supportleistungen während des gesamten Migrationsplanungszeitraums übersteigt.

Die erforderliche Python-Version

Für die Migration auf Django 5.2 LTS ist Python 3.10 oder höher erforderlich. Unternehmen, die Django 3.2 einsetzen, verwenden möglicherweise Python 3.6, 3.7 oder 3.8, wobei alle diese Versionen ihr offizielles Lebensende bereits überschritten haben. Organisationen, die Django 4.2 einsetzen, verwenden möglicherweise Python 3.8 oder 3.9. Das bedeutet, dass eine vollständige Behebung des Django-EOL für viele Organisationen eine schrittweise Migration sowohl der Python-Laufzeitumgebung als auch des Django-Frameworks erfordert, einschließlich der damit verbundenen Überprüfung der Kompatibilität aller Abhängigkeiten. Teams, die die Migration als „Django-Upgrade“ planen und dann erst mitten im Projekt die Python-Voraussetzung entdecken, sind diejenigen, die mit den größten unerwarteten Zeitplanüberschreitungen konfrontiert sind.

Möglichkeiten für Sicherheit und die Einhaltung von Vorschriften

Unternehmen, die Django-Versionen nutzen, deren Support ausläuft, haben drei Möglichkeiten. Zwei davon sind mit erheblichem technischem Aufwand, operativen Risiken und längeren Zeitplänen verbunden. Die dritte Möglichkeit löst das Problem sofort, während Ihre Teams die Migration sorgfältig planen.

Option 1: Umstellung auf Django 5.2 LTS

Die langfristige Lösung besteht in der Migration auf Django 5.2 LTS, die aktuelle Version mit langfristigem Support, für die bis April 2028 aktive Sicherheitspatches vom Upstream-Entwickler bereitgestellt werden. Dadurch wird das Risiko eines Django-EOL-Szenarios beseitigt, da auf aktiv gepflegte Upstream-Software umgestellt wird. Die Migration ist mit einem erheblichen technischen Aufwand verbunden. Django 5.2 erfordert Python 3.10 oder höher, sodass Unternehmen, die noch ältere Python-Laufzeitumgebungen verwenden, diese aktualisieren müssen, bevor die Django-Migration beginnen kann. Abgesehen von der Laufzeitumgebungsvoraussetzung werden in jeder Hauptversion zwischen Ihrer aktuellen Version und 5.2 Funktionen entfernt, die in früheren Versionen als veraltet markiert wurden. Für ein Team, das von 3.2 auf 5.2 umsteigt, bedeutet dies, dass drei Generationen von Entfernungen berücksichtigt werden müssen. Anwendungen mit benutzerdefinierter Middleware, benutzerdefinierten Template-Backends oder nicht trivialer ORM-Nutzung sollten diese Migration in Quartalen und nicht in Wochen planen.

Option 2: Django durch ein alternatives Framework ersetzen

Manche Unternehmen nehmen das Ende der Lebensdauer (EOL) von Django zum Anlass, Alternativen zu prüfen. FastAPI, Flask und Starlette sind aktiv gepflegte Python-Web-Frameworks mit unterschiedlichen Architekturmodellen. Wenn sich die Anforderungen einer Anwendung in Richtung Microservices oder API-First-Design entwickelt haben, kann ein Framework-Wechsel den architektonischen Zielen entsprechen. Eine vollständige Framework-Migration ist mit größeren Umstellungen verbunden als ein Upgrade innerhalb des Frameworks; jede Ansicht, jedes Formular, jeder ORM-Aufruf und jede Middleware muss im Modell des neuen Frameworks neu implementiert werden. Weder ein Framework-Wechsel noch ein Standard-Upgrade sind eine schnelle Lösung für eine unmittelbar festgestellte Nichtkonformität mit dem Django EOL. Beide sind langfristig gangbare Wege für Teams, die in der Lage sind, sie sorgfältig umzusetzen.

Option 3: Lebenslanger Support durch TuxCare (empfohlene Vorgehensweise)

Der „Endless Lifecycle Support“ von TuxCare für Django ist die Lösung, mit der Sie die Sicherheit gewährleisten können, ohne eine Migration durchführen zu müssen, auf die Ihr Team noch nicht vorbereitet ist. Anstatt ein störendes Upgrade Ihrer Django-Anwendung und ihrer Abhängigkeiten zu erzwingen, nutzen Sie weiterhin Ihre aktuelle Django-Version mit fortlaufender Sicherheitspatch-Abdeckung, die als Drop-in-Paket-Updates über Ihren bestehenden pip-Workflow bereitgestellt wird. Genau dafür ist ELS für Django konzipiert: für die Lücke zwischen dem Ende des offiziellen Supports und dem Zeitpunkt, an dem Ihr Unternehmen eine geplante, kontrollierte Migration nach eigenem Zeitplan tatsächlich abgeschlossen hat.

Die einfache Lösung: TuxCare ELS für Django EOL

TuxCare bietet „Endless Lifecycle Support“ für Django-Versionen, deren Support ausläuft, und sorgt dafür, dass Ihre aktuelle Django-Bereitstellung durch Sicherheitspatches abgesichert bleibt, die über Ihren bestehenden pip-Workflow bereitgestellt werden. TuxCare hat im gesamten Open-Source-Ökosystem bereits über 220.000 Sicherheitspatches bereitgestellt.

Vollständige Abdeckung des Abhängigkeitsbaums: TuxCare ELS für Django deckt nicht nur das Django-Paket selbst ab, sondern auch dessen gesamte Laufzeit-Abhängigkeiten, einschließlich sqlparse und dessen bekannter CVE-Sicherheitslücke (CVE-2024-4340, CVSS 7.5 High). Schwachstellenscanner machen keinen Halt vor Paketgrenzen, ebenso wenig wie die Abdeckung von TuxCare. Die gesamte Patch-Fläche wird ohne zusätzliche Kosten abgedeckt.

Optimierter, automatisierter Patching-Prozess: TuxCare überwacht das NVD, Django-Sicherheitshinweise, GitHub-Sicherheitsfeeds und die Offenlegungskanäle der Anbieter – also alle Quellen, über die Schwachstellen in Django und seinen Abhängigkeiten bekannt gegeben werden. Wenn eine CVE identifiziert wird, übernehmen algorithmische Tools und KI-gestützte Automatisierung das Backporting von Sicherheitskorrekturen auf die unterstützte Version, und Sicherheitsexperten validieren jeden Patch, bevor er ausgeliefert wird. Jedes Update durchläuft Integritäts-, Funktions- und Regressionstests, bevor es Ihre Repositorys erreicht. Ausführliche technische Details finden Sie im Whitepaper „Open Source Patching Process“ von TuxCare .

Nahtlose Integration: Unabhängig davon, ob Sie Django derzeit direkt über pip oder über einen privaten Paket-Mirror installieren, können Sie Ihre Update-Quelle mit minimalen Änderungen an Ihrem bestehenden Workflow auf das sichere Repository von TuxCare umstellen. Es sind keine Änderungen an Ihrer CI/CD-Pipeline, Ihrem Deployment-Prozess oder der Arbeitsweise Ihrer Teams erforderlich. Die gepatchten Django-Pakete sind Drop-in-Ersatzpakete mit derselben API, derselben Konfiguration und demselben Laufzeitverhalten, in die Sicherheitskorrekturen zurückportiert wurden.

Schnelle Reaktion mit SLA-Garantie: Wenn neue Sicherheitslücken bekannt werden, die Django-Versionen betreffen, deren Support ausgelaufen ist – sei es in Django selbst, in sqlparse oder in asgiref –, liefert TuxCare Patches, die durch Service-Level-Vereinbarungen abgesichert sind. Sicherheitslücken mit hohem und kritischem Schweregrad (CVSS 7.0 und höher) werden innerhalb von 14 Tagen nach ihrer Veröffentlichung behoben.

Kostengünstige Sicherheitskontinuität: Die Kosten für TuxCare ELS betragen nur einen Bruchteil dessen, was eine Notfallmigration kostet, wenn diese aufgrund einer Compliance-Frist erzwungen wird. Sie planen eine wohlüberlegte Migration auf Django 5.2 LTS, wenn dies den Kapazitäten Ihres Teams entspricht, einschließlich der Zeit, um die Python-Laufzeitvoraussetzungen zu erfüllen, die Kompatibilität von Drittanbieter-Paketen zu überprüfen und das Verhalten in jedem Anwendungspfad zu validieren. Oder Sie nutzen ELS, um vollständige Sicherheit und Compliance zu gewährleisten, während Sie diese Entscheidungen nach Ihrem eigenen Zeitplan treffen – und nicht nach dem eines Compliance-Prüfers.

Lassen Sie nicht zu, dass das Ende der Lebensdauer von Django Ihre Anwendungen gefährdet

Das Ende des Supportzeitraums (EOL) für Django bedeutet nicht, dass Ihre Anwendung automatisch gefährdet ist. Es bedeutet vielmehr, dass das Django-Projekt keine Patches mehr für Sie bereitstellt, falls eine kritische Sicherheitslücke die von Ihnen verwendete Version betrifft. Jede neue CVE, die nach Ablauf des Supportzeitraums bekannt wird, verlängert das Sicherheitsrisiko – und ohne einen rückportierten Fix bleibt dieses Risiko bestehen.

Die richtige Vorgehensweise hängt vom Zeitplan, der Risikobereitschaft und den technischen Kapazitäten Ihres Unternehmens ab. Wenn Sie jetzt auf Django 5.2 LTS umsteigen können – einschließlich aller erforderlichen Python-Laufzeit-Upgrades –, ist dies langfristig der beste Weg. Sollte Ihre Django-Anwendung jedoch zu komplex sein, um unter Zeitdruck sicher migriert zu werden, bietet Ihnen TuxCare ELS für Django weiterhin Sicherheitsschutz, während Ihr Team das Upgrade sorgfältig plant und durchführt.

Wenn das Ende des Supports für Django derzeit auf Ihrer Sicherheits-Agenda steht, besuchen Sie Endless Lifecycle Support für Django , um zu erfahren, wie erweiterter Support Ihre Python-Anwendungen schützen kann, oder entdecken Sie TuxCares umfassendes Endless Lifecycle Support für Open-Source-Software , um Ihren gesamten Open-Source-Stack abzudecken.

Zusammenfassung

Artikel Name

ELS für Django: Auch nach dem EOL sicher bleiben – TuxCare

Beschreibung

Verwenden Sie eine Django-Version, deren Lebenszyklus bald endet? Mit TuxCare ELS für Django bleiben Ihre Python-Anwendungen auf dem neuesten Stand und konform, ohne dass eine überstürzte Migration erforderlich ist.

Autor

Muzzammil Hasann

Name des Herausgebers

TuxCare

Logo des Herausgebers