Was ist Backporting? Ablauf, Überlegungen, Tipps und mehr

Wichtigste Erkenntnisse

• Beim Backporting wird ein Fix aus einer neueren Version in die von Ihnen verwendete ältere Version integriert, ohne dass ein Upgrade auf die Upstream-Version erforderlich ist.
• Red Hat hat die Heartbleed-Sicherheitslücke in OpenSSL 1.0.1e behoben, ohne die Upstream-Version zu ändern, sodass Scanner, die ausschließlich nach der Versionsnummer suchen, diese Version dennoch als problematisch kennzeichnen.
• Überprüfen Sie einen Backport anhand des Distributionshinweises und des Paket-Changelogs, nicht anhand der Versionsnummer.
• Wenn der Standard-Support endet, hängen Fehlerbehebungen vom erweiterten Support, einem weitergeführten Fork oder Ihrem eigenen Team ab.

Ihr Scanner meldet, dass auf dem Server eine anfällige OpenSSL-Versionaus. Ihr Systemadministrator sagt, dass sie letzten Monat gepatcht wurde. Beide betrachten denselben Host und lesen dasselbe Paket, aber nur einer von ihnen hat Recht, was die Sicherheitslücke angeht. Dieser Streit ist ein Backporting-Problem. Ein Fix aus einer neueren Version wurde auf die noch laufende Version angewendet, und die Upstream-Versionsnummer hat sich nie geändert. In Enterprise-Linux-Umgebungen kann die Suche nach solchen Fehlalarmen mehr Zeit in Anspruch nehmen als die Behebung einiger echter Sicherheitslücken.

In diesem Artikel wird erläutert, was Backporting ist, warum die Versionsnummer nach der Einbindung eines Fixes unverändert bleibt, warum dies versionsbasierte Scanner verwirrt, wie man einen Fix selbst überprüfen kann und wer für die weiteren Backports sorgt, sobald ein Release das Ende seiner Lebensdauer erreicht hat.

Was ist Backporting?

Unter „Backporting“ versteht man, dass ein Fix für eine Sicherheitslücke aus einer neueren Version eines Softwarepakets entnommen und auf eine ältere Version angewendet wird, die noch im Einsatz ist. Die Sicherheitslücke wird behoben, ohne auf eine neuere Upstream-Version umzusteigen und damit alle damit nicht zusammenhängenden Änderungen mitzunehmen.

Was bedeutet „Backport“ aber konkret? Hier ist ein konkretes Beispiel: Die OpenSSL-Betreuer haben die Heartbleed-Sicherheitslücke in der Version 1.0.1g behoben. Die Kunden von Red Hat nutzten die Version 1.0.1e, und ein Upgrade auf 1.0.1g hätte alle anderen Änderungen mit sich gebracht, die zwischen diesen Versionen vorgenommen wurden. Daher hat Red Hat nur den Heartbleed-Fix in seine 1.0.1e-Codebasis zurückportiert und openssl-1.0.1e-16.el6_5.7 unter dem Sicherheitshinweis RHSA-2014:0376 aus. Gleiche Upstream-Funktionsbasis, gleiches Verhalten außerhalb des gepatchten Codepfads und kein Heartbleed mehr.

Das Backportieren von Sicherheitskorrekturen auf diese Weise ist seit zwei Jahrzehnten gängige Praxis bei den meisten Linux-Distributionen, darunter RHEL, Ubuntu, Debian, SUSE und deren Derivate. Führen Sie „dnf update“ auf einem RHEL-Host aus, und viele der bereitgestellten Korrekturen sind Backports.

Wussten Sie schon: Anhand des Felds „release“ am Ende lässt sich erkennen, ob es sich um einen Backport-Build handelt. In openssl-1.0.1e-16.el6_5.7ist 1.0.1e die Upstream-Version, und bei einem zurückportierten Update bleibt diese Angabe unverändert. Das 16.el6_5.7 ist die Paketversion der Distribution und ändert sich jedes Mal, wenn die Distribution einen überarbeiteten Build veröffentlicht.

So funktioniert das Backporting

Ein Betreuer identifiziert die Korrektur im Upstream, grenzt sie von allen anderen Änderungen ab, passt sie an eine Codebasis an, die sich inzwischen weiterentwickelt hat, testet sie auf Regressionen und veröffentlicht sie über den üblichen Update-Kanal unter Beibehaltung der Upstream-Versionsnummer.

Die Beibehaltung dieser Upstream-Versionsnummer ist ebenso bewusst gewählt wie die Korrektur selbst. Sie signalisiert, dass das Paket im Kern nach wie vor dieselbe Version ist, wobei die API und das allgemeine Verhalten außerhalb des gepatchten Codepfads erhalten bleiben. Lediglich die Versionskennung der Distribution ändert sich.

1. Die Ursache des Problems weiter oben ermitteln

Jemand meldet eine Sicherheitslücke, die Upstream-Betreuer schreiben einen Patch, und dieser fließt in eine neuere Version ein. Das Sicherheitsteam der Distribution muss die genaue Änderung oder die Reihe von Änderungen ermitteln, die die Sicherheitslücke behebt, und nicht nur die Version, in der sie enthalten ist.

Das ist schwieriger, als es klingt. Upstream-Projekte veröffentlichen Sicherheitskorrekturen nicht immer als einen einzigen, in sich geschlossenen Commit. Sie können auf drei Commits verteilt sein, in einer größeren Umstrukturierung gebündelt sein oder mit einer vagen Meldung zusammengeführt werden, bevor die CVE veröffentlicht wird. Sicherheitsteams überwachen Upstream-Repositorys, Mailinglisten und CVE-Feeds kontinuierlich, um solche Fälle zu erkennen.

Das Ergebnis dieses Schritts ist ein Patch, der manchmal aus mehreren Commits zusammengesetzt wird, sowie ein klares Verständnis dafür, welche Zeilen genau die Schwachstelle beheben und warum. Alles, was danach folgt, hängt davon ab, dass dies korrekt erfolgt – wenn man die Hälfte der Korrektur übersieht, liefert man ein Paket aus, das angeblich gepatcht ist, es aber nicht ist.

2. Isolieren Sie es von nicht damit zusammenhängenden Änderungen

Der Upstream-Fix kommt in dieser Version mit allem anderen vermischt daher: neue Funktionen, Refactorings, geänderte Standardeinstellungen, aktualisierte Abhängigkeiten. Der Betreuer filtert all das heraus.

Was übrig bleibt, sollte die minimale Änderung sein, die die Sicherheitslücke schließt – sonst nichts. Darin liegt der gesamte Nutzen des Backportings. Man erhält den Sicherheitspatch, ohne die neue Konfigurationssyntax, die die Ansible-Rolle unbrauchbar macht.

Insider-Tipp: In einigen Changelogs von Distributionen wird die Upstream-Version oder der Commit genannt, aus der bzw. dem ein zurückportierter Fix stammt. In diesem Fall gibt diese Angabe Aufschluss darüber, woher der Fix stammt, nicht darüber, was installiert ist. Ihr Paket bleibt auf seiner ursprünglichen Upstream-Version, und nur die Versionsnummer der Distribution ändert sich. Prüfer verwechseln diese beiden Aspekte häufig. Weisen Sie daher in Ihren Nachweisen einmal auf diesen Unterschied hin, dann müssen Sie ihn bei der Überprüfung nicht fünfmal erklären.

Auch die Isolierung erfordert Urteilsvermögen. Um zu entscheiden, welche Zeilen tatsächlich zum Fix gehören, muss man die Schwachstelle selbst verstehen – was eine höhere Hürde darstellt als das Anwenden eines Patches , der für den vorliegenden Code geschrieben wurde.

3. Passen Sie es an die ältere Codebasis an

Nun muss der Patch entsprechend umgeschrieben werden. Die Funktionssignaturen unterscheiden sich, die Datenstrukturen haben sich verändert, und Hilfsfunktionen sind im älteren Code möglicherweise noch nicht vorhanden. Eine Korrektur, die eine Funktion betrifft, deren Name vor zwei Releases geändert wurde, kann nicht unverändert übernommen werden.

Der Betreuer implementiert dieselbe Verteidigungslogik neu, wobei er auf die Möglichkeiten der älteren Codebasis zurückgreift. Wenn die beiden Baumstrukturen noch nicht allzu weit auseinander gedriftet sind, lässt sich das schnell erledigen. Wenn sie sich jedoch über Jahre hinweg auseinanderentwickelt haben, kann dies einen erheblichen Aufwand bei der Neuimplementierung bedeuten – und manchmal ist dies gar nicht möglich, was eine der tatsächlichen Grenzen darstellt, auf die weiter unten eingegangen wird.

Ein Beispiel: Eine in sich geschlossene Korrektur, die eine Bereichsprüfung hinzufügt, lässt sich in der Regel problemlos portieren. Eine Korrektur, die eine Race Condition durch eine Änderung des Sperrmodells behebt, ist wesentlich schwieriger, da der ältere Code möglicherweise nicht über die Sperrprimitive verfügt, auf die die Korrektur angewiesen ist. Der Betreuer muss das gleiche Sicherheitsproblem dann auf andere Weise lösen.

Deshalb ist die Frage „Wer kümmert sich um Ihre Backports?“ eine echte Beschaffungsfrage und keine Marketingfloskel. Die Kompetenz des Teams, das diese Arbeit übernimmt, entscheidet darüber, ob Ihr „gepatchtes“ System auch wirklich gepatcht ist.

4. Überprüfen Sie, ob sich das Verhalten nicht ändert

Das gepatchte Paket wird kompiliert und anhand zweier Kriterien getestet: Der Fehler wurde behoben, und die Korrektur hat keine unbeabsichtigten Regressionen verursacht.

Die zweite Hälfte ist die größere Herausforderung. Hier werden Regressions-Testsuiten, ABI-Kompatibilitätsprüfungen und Integrationstests durchgeführt, denn der Sinn eines Backports besteht ja gerade darin, dass er den normalen Patch-Zyklus durchlaufen kann, anstatt zu einem Migrationsprojekt zu werden. Wer dieses Versprechen auch nur einmal bricht, verliert das Vertrauen der Kunden in den Update-Kanal.

Unternehmensdistributionen legen großen Wert auf die ABI-Kompatibilität von Bibliothekspaketen, damit bei einem Backport nicht unbemerkt ein Symbol geändert wird, von dem die kompilierte Anwendung eines Kunden abhängt. RHEL beispielsweise veröffentlicht explizite Zusagen zur API- und ABI-Kompatibilität für seine Releases. Diese Disziplin ist ein wesentlicher Grund dafür, dass Releases mit langfristigem Support ein Jahrzehnt lang nutzbar bleiben.

Achtung: Ein Backport, der hinsichtlich dieser Sicherheitslücke validiert wurde, ist nicht unbedingt auch für Ihre Anwendung validiert. Regressionstests des Anbieters beziehen sich auf das Paket selbst. Führen Sie Ihre eigenen Smoke-Tests auf dem kritischen Pfad durch.

5. Die Upstream-Version unverändert mitliefern

Das Paket wird über das normale Repository bereitgestellt. Die Upstream-Version bleibt unverändert, lediglich das Release-Suffix der Distribution ändert sich.

openssl-1.0.1e-16.el6_5.4 wird zu openssl-1.0.1e-16.el6_5.7. Für Ihren Paketmanager ist dies ein routinemäßiges Update. Für einen versionsbasierten Scanner, der „1.0.1e“ mit einer Upstream-CVE-Datenbank vergleicht, in der steht „behoben in 1.0.1g“, sieht es so aus, als hätten Sie gar nichts getan.

Diese Diskrepanz ist eine bewusste Kompatibilitätsentscheidung mit einer bekannten Nebenwirkung bei der Fehlermeldung und stellt eine der häufigsten Ursachen für falsch-positive Sicherheitslückenmeldungen in Linux-Umgebungen dar.

Backporting vs. Upgrade

Beide beheben den Fehler. In fast allen anderen Punkten unterscheiden sie sich.

	Backporting	Aktualisierung
Was Sie erhalten	Gezielte Fehlerbehebungen, ohne auf eine neuere Upstream-Version umzusteigen	Die Korrekturen sowie die neuen Funktionen, geänderte Standardeinstellungen und angepasste APIs
Auswirkungen auf die Stabilität	Entwickelt, um das bisherige Verhalten beizubehalten	Das Verhalten kann sich ändern, daher sind Tests erforderlich
Eine Mühe für dich	Regelmäßige Paketaktualisierung	Kompatibilitätsprüfungen, Konfigurationsmigration, mögliche Codeänderungen
Bruchgefahr	Weniger als ein umfangreiches Upgrade, aber nicht gleich Null	Mäßig bis hoch, je nach Versionsunterschied
Wer erledigt die Arbeit?	Distributor oder Supportanbieter	Ihr Team
Wie lange es hält	Bis derjenige, der die Backports pflegt, damit aufhört	Bis die neu aktualisierte Version ihr eigenes EOL erreicht

Ein Upgrade kann neben der benötigten Korrektur auch eine umfassendere Absicherung, sicherere Standardeinstellungen und architektonische Verbesserungen mit sich bringen. Durch Backporting erhalten Sie die spezifische Korrektur mit möglichst wenigen Begleitänderungen. Dieser Kompromiss ist ein wichtiger Grund dafür, dass bei Versionen mit langfristigem Support gezielte Wartungsmaßnahmen gegenüber häufigen Rebases bevorzugt werden.

Die Situation kehrt sich um, wenn die Versionslücke groß genug wird. Eine Backport-Kette, die ein Paket acht Jahre lang zusammengehalten hat, birgt eine Menge angesammelter Abweichungen, und ab einem bestimmten Punkt kann eine Migration die praktischere Option sein. Die Frage ist, ob man den Zeitpunkt selbst wählen kann, und unser Vergleich zwischen „End of Life“ und „End of Support“ beleuchtet, welche Faktoren diese Entscheidung beeinflussen.

Warum Scanner zurückportierte Korrekturen markieren

Einige versionsbasierte Scanner vergleichen die erkannte Paketversion mit den CVE-Korrekturversionen des Upstream-Projekts. Ihr Paket trägt die Versionsnummer 1.0.1e. Laut Datenbank wurde Heartbleed in Version 1.0.1g behoben. Der Scanner meldet daher, dass Ihr System anfällig ist. Wenn diese Einschätzung ausschließlich auf der Versionsangabe beruht, handelt es sich um einen Fehlalarm, da der Scanner die rückportierte Korrektur nicht berücksichtigt hat. Genau dieses Verhalten wird in der Sicherheitsdokumentation von Red Hat selbst angesprochen.

Hier ist das durchgerechnete Beispiel von Anfang bis Ende.

Was jede Partei sieht	Wert
Ihr installiertes Paket	openssl-1.0.1e-16.el6_5.7
Upstream-Korrekturversion für CVE-2014-0160	1.0.1g
Einfaches Scanner-Urteil	Gefährdet
Aktueller Status	Behoben über RHSA-2014:0376

Überprüfen Sie es selbst, beginnend mit dem Changelog. Überprüfen Sie das installierte Paket auf die CVE:

rpm -q –changelog openssl | grep CVE-2014-0160

Wenn die CVE-Nummer angezeigt wird, ist das ein deutlicher Hinweis darauf, dass der Fix enthalten ist, und im Sicherheitshinweis der Distribution lässt sich dies bestätigen. Die gleiche Überprüfung funktioniert auch bei einer RPM-Datei, die noch nicht installiert ist:

rpm -qp kernel-3.10.0-862.11.6.el7.x86_64.rpm –changelog | grep CVE-2017-12190

Unter Debian und Ubuntu entspricht dies dem Debian-Changelog:

zcat /usr/share/doc/openssl/changelog.Debian.gz | grep CVE-2014-0160

Swap in whatever package you’re checking. Most Debian and Ubuntu packages ship this file at /usr/share/doc/<package>/changelog.Debian.gz. Don’t confuse it with changelog.gz, which is normally the upstream changelog. Debian’s own package changes, backports included, are recorded in changelog.Debian.gz. Minimal and container images often strip /usr/share/doc entirely, and in that case apt changelog <package> fetches the changelog from the archive instead.

Überprüfen Sie drei Quellen, da diese unterschiedliche Fragen beantworten. Der Sicherheitshinweis der Distribution ist die maßgebliche Quelle dafür, welcher Paket-Build eine bestimmte CVE behebt, und Red Hat, Canonical sowie Debian veröffentlichen alle CVE-spezifische Seiten, auf denen die genauen behobenen Paketversionen aufgeführt sind. Die Metadaten und das Changelog des installierten Pakets geben Auskunft darüber, was tatsächlich auf dem Host vorhanden ist, und nennen in der Regel die CVEs, die durch den Build behoben werden – daher eignen sie sich für eine schnelle erste Überprüfung. Maschinenlesbare Feeds sind für Ihre Tools gedacht. Formate wie OVAL und – sofern vom Anbieter veröffentlicht – VEX- oder CSAF-Daten ermöglichen es Scannern, die distributionsspezifische Bewertung zu nutzen, anstatt anhand einer Versionszeichenfolge zu raten. Wenn Ihr Scanner diese Formate unterstützt, sollten Sie sie aktivieren.

Die strukturelle Lösung besteht darin, dass das Tool den tatsächlichen Patch-Status ermittelt, anstatt sich allein auf den Abgleich mit der Upstream-Version zu verlassen.TuxCare Radar wurde entwickelt, um diese spezifische Lücke in Verbindung mit Ihren bestehenden Scannern zu schließen. Es erkennt Backports von Distributionen, rebootless Patches von KernelCare und ELS-Updates, sodass ein gepatchter Host als gepatcht gemeldet wird und die entsprechenden Nachweise exportiert werden können, wenn jemand einen Nachweis verlangt.

Profi-Tipp: Bevor Sie eine Feststellung gegenüber einem Prüfer anfechten, exportieren Sie die Zeile aus dem Changelog und die URL des Distributor-Hinweises gemeinsam. „Die CVE ist im Changelog des Pakets aufgeführt und der Hinweis des Anbieters bestätigt diesen Build“ beendet die Diskussion. „Vertrauen Sie mir, es wurde zurückportiert“ tut dies nicht.

Wer portiert Korrekturen zurück, und wie lange?

Diese Arbeit wird in der Regel von drei Gruppen übernommen: Upstream-Projekte mit unterstützten stabilen Zweigen, Sicherheitsteams von Distributionen und Anbieter mit erweitertem Support. Gerade bei den Übergaben zwischen diesen Gruppen entstehen Schwachstellen in den IT-Umgebungen.

Upstream-Projekte pflegen in der Regel eine kleine Anzahl unterstützter Zweige, zu denen manchmal auch ein länger gültiger LTS-Zweig gehört, und übernehmen dort ausgewählte Korrekturen. Sobald ein Zweig aus diesem Unterstützungszeitraum herausfällt, wird die Pflege eingestellt.

Die Sicherheitsteams der Distributionen portieren diese Patches in die von ihnen ausgelieferten Versionen, und zwar für die gesamte Dauer des Supportzeitraums. Aktuelle RHEL-Hauptversionen erhalten zehn Jahre „Full Support“ und „Maintenance Support“, und Red Hat bietet darüber hinaus eine erweiterte Supportdauer an. RHEL 7 nutzt das ältere ELS-Add-on, während RHEL 8.10 und spätere Versionen auf „Extended Life Cycle Premium“ umgestellt werden. Ubuntu LTS erhält fünf Jahre Standard-Sicherheitswartung, bis zu zehn Jahre mit Ubuntu Pro und bis zu 15 Jahre mit dem kostenpflichtigen „Legacy“-Add-on von Canonical.

Anbieter von erweiterten Supportleistungen übernehmen danach die Betreuung – allerdings nur, wenn Sie den Support erwerben. Manchmal handelt es sich dabei um ein kostenpflichtiges Programm des ursprünglichen Anbieters, manchmal um ein Angebot eines Drittanbieters.

Die Termine stehen fest und sind für viele Produktionssysteme bereits abgelaufen. Der Stand entspricht dem Stand von September 2026:

Veröffentlichung	Ende des Standard-Supports	Aktueller Status
Python 2.7	1. Januar 2020	Keine Sicherheitskorrekturen
Ubuntu 16.04	30. April 2021 (ESM lief im Mai 2026 aus)	Nur kostenpflichtiges „Legacy“-Add-on, bis Mai 2031
CentOS Linux 8	31. Dezember 2021	Keine Upstream-Aktualisierungen
PHP 7.4	28. November 2022	Keine Sicherheitskorrekturen
Ubuntu 18.04	31. Mai 2023 (Ubuntu Pro ESM bis Mai 2028)	Nur ESM
PHP 8.0	26. November 2023	Keine Sicherheitskorrekturen
CentOS Linux 7	30. Juni 2024	Keine Upstream-Aktualisierungen
RHEL 7	30. Juni 2024 (Red Hat ELS bis Mai 2029)	Nur kostenpflichtiger erweiterter Support
Ubuntu 20.04	31. Mai 2025 (Ubuntu Pro ESM bis Mai 2030)	Nur ESM
PostgreSQL 13	13. November 2025	Keine Sicherheitskorrekturen
PHP 8.1	31. Dezember 2025	Keine Sicherheitskorrekturen

Sobald eine Version diese Grenze überschreitet, werden über den Standard-Update-Kanal keine Fehlerbehebungen mehr bereitgestellt. Der Schutz ab diesem Zeitpunkt hängt von einem kostenpflichtigen Programm für erweiterten Support ab – sei es vom ursprünglichen Anbieter oder von einem Drittanbieter – oder von der internen Wartung.

Der „Endless Lifecycle Support“ (ELS) von TuxCare deckt diesen Zeitraum ab. ELS stellt auch nach Ablauf des regulären Supports weiterhin zurückportierte Sicherheitspatches für Betriebssysteme, Laufzeitumgebungen, Sprachumgebungen und Anwendungen bereit – und zwar über denselben Paketmanager, der bereits im Einsatz ist.

Siehe die vollständige Liste der unterstützten Technologien. Um einen genaueren Einblick in den Patching-Prozess zu erhalten, bietet dieses Whitepaper, das den Prozess ausführlich erläutert.

Herausforderungen und Grenzen beim Backporting

Die Codebasen driften auseinander. Mit jedem Jahr, das vergeht, unterscheidet sich der ältere Codezweig immer stärker vom neueren. Ein Patch, der im zweiten Jahr problemlos angewendet werden konnte, muss im siebten Jahr möglicherweise weitgehend neu implementiert werden, sodass die Arbeit genau dann schwieriger und langwieriger wird, je älter der Code wird.

Auch die Tests werden aufwendiger. Jeder neue Backport muss anhand einer Codebasis validiert werden, die möglicherweise bereits jahrelange frühere Backports und andere nachgelagerte Änderungen enthält, und diese Änderungen können Wechselwirkungen zeigen. Je mehr Änderungen sich in einem Zweig ansammeln, desto umfangreicher müssen die Regressionstests sein.

Manche Fehlerbehebungen lassen sich überhaupt nicht direkt zurückportieren. Wenn der Upstream-Entwickler eine Schwachstelle durch eine Änderung der Architektur behebt – beispielsweise durch ein neues Speichermodell, ein neu gestaltetes Berechtigungssystem oder einen neu geschriebenen Parser –, gibt es möglicherweise keinen eigenständigen Patch, der angepasst werden könnte. Dem Anbieter bleiben dann zwei Möglichkeiten: entweder eine maßgeschneiderte Abhilfemaßnahme, die mit anderen Mitteln das gleiche Sicherheitsergebnis erzielt, oder eine ehrliche Erklärung, dass die Schwachstelle in diesem Zweig nicht behebbar ist. Beides ist legitim. Schweigen hingegen nicht.

Und ein Backport ist per Definition begrenzt. Er behebt die jeweilige Schwachstelle. Er bringt jedoch nicht die allgemeine Absicherung, die sichereren Standardeinstellungen oder die entfernten veralteten Codepfade mit sich, die eine neue Hauptversion möglicherweise enthält. Eine ältere Version kann eine Korrektur für jede CVE enthalten, die ihr Betreuer behoben hat, und dennoch veralteten Code und Sicherheitsbeschränkungen beibehalten, die in neueren Versionen inzwischen entfernt oder überarbeitet wurden.

Die Qualität des Backportings hängt vollständig davon ab, wer die Patches pflegt. Das ist ein entscheidendes Kriterium bei der Auswahl einer Distribution oder eines Anbieters mit erweitertem Support. Erkundigen Sie sich daher nach den Bearbeitungszeiten für Backports, den Vorgehensweisen bei Regressionstests und danach, was geschieht, wenn ein Fix nicht portiert werden kann. Diese Antworten sind wichtiger als eine Liste der Funktionen und fließen direkt in die Art und Weise ein, wie Sie Ihr Schwachstellenmanagement betreiben und Richtlinien zur Priorisierung von Schwachstellen festlegen.

Mit TuxCare auch nach dem EOL weiterhin Backports erhalten

Backporting bietet Ihnen nur so lange Schutz, wie es noch durchgeführt wird. Wenn der Standard-Support endet, werden über den normalen Update-Kanal keine Fehlerbehebungen mehr bereitgestellt, es sei denn, es besteht ein erweiterter Support. Das System läuft weiter und es tauchen weiterhin CVEs auf – ab diesem Zeitpunkt hängt der Schutz von einer Migration oder einem Anbieter für erweiterten Support ab.

Der „Endless Lifecycle Support“ von TuxCare stellt auch lange nach Ablauf des regulären Upstream- oder Hersteller-Supports weiterhin Sicherheitspatches für Betriebssysteme, Laufzeitumgebungen, Sprachumgebungen und Anwendungen bereit, deren Lebenszyklus bereits beendet ist.

Sehen Sie sich an, wie der Versicherungsschutz für Ihre Stack-Lösung aussiehtoder stellen Sie uns eine Frage zu einer bestimmten End-of-Life-Version.

FAQs