Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse:
- Software, deren Lebensdauer sich dem Ende zuneigt, ist in Unternehmenssystemen eine unvermeidliche Realität. Kritische Plattformen überdauern oft die Open-Source-Komponenten, auf die sie angewiesen sind, und diese Komponenten sammeln auch lange nach Ablauf des offiziellen Supports weiterhin Sicherheitslücken an.
- Der sichere Betrieb von Software, deren Lebenszyklus sich dem Ende zuneigt, erfordert kontinuierliche und komplexe Anstrengungen. Sie müssen Schwachstellen in verstreuten Datenbanken und komplexen Abhängigkeitsgraphen aufspüren und anschließend die Komponenten, die Ihr Team übernommen hat, patchen, neu kompilieren und testen – und das wiederholt über Jahre hinweg.
- Die langfristige Zuverlässigkeit von Open-Source-Software hängt nicht davon ab, dass keine Sicherheitslücken vorhanden sind, sondern von der Ausgereiftheit der Prozesse zu deren Behebung. Standardisierte Patching-Workflows und institutionelles Fachwissen – wie sie der „Endless Lifecycle Support“ von TuxCare bietet – ermöglichen eine beständige, zuverlässige Open-Source-Sicherheit über einen langen Zeitraum hinweg.
Die Software, die Sie heute entwickeln, wird wahrscheinlich noch Jahre, ein Jahrzehnt oder länger laufen. Kritische Systeme werden nicht einfach aus einer Laune heraus ersetzt. Sie werden gewartet, gepatcht und am Laufen gehalten, weil sie zu wichtig, zu teuer oder zu tief in andere Systeme integriert sind, um ersetzt zu werden.
Doch woran die meisten Teams während der Entwicklung nicht denken: Die Open-Source-Komponenten, auf denen Ihre Software basiert, werden nicht unbedingt genauso lange bestehen bleiben wie Ihre Software. Bibliotheken erreichen das Ende ihrer Lebensdauer. Frameworks erhalten keine Updates mehr. Sprach-Runtimes werden auf neuere Versionen umgestellt – ähnlich wie bei den Herausforderungen, die während der Umstellung nach dem Ende der Lebensdauer von Node.js auftraten. Diese Realität betrifft auch beliebte Frontend-Frameworks, und Teams suchen oft nach Möglichkeiten, einen next.js-EOL-Zyklus zu bewältigen, ohne ihre Produktions-Roadmaps zu stören. Und wenn das passiert, bleibt Ihnen nichts anderes übrig, als Produktionssysteme zu warten, die von Software abhängen, die offiziell von niemandem mehr unterstützt wird.
Die Sicherheitslücken verschwinden nicht, wenn der offizielle Support endet. Sie tauchen Jahr für Jahr immer wieder auf, verstreut über komplexe Abhängigkeitsgraphen.
Ein oder zwei Mal Abhilfe zu schaffen, ist machbar. Aber über einen Zeitraum von fünf oder zehn Jahren hinweg zuverlässig, wiederholt und korrekt Abhilfe zu schaffen? Nun, dafür braucht es etwas, das die meisten Unternehmen unterschätzen: einen ausgereiften, disziplinierten Patch-Prozess, der jedes Mal auf die gleiche Weise abläuft, unabhängig davon, wo die Schwachstelle auftritt oder wann sie entdeckt wird.
Wie es dazu kommt, dass Unternehmen Software nutzen, deren Lebenszyklus abgelaufen ist
Wenn Ihre Software fünf, sieben oder zehn Jahre lang im Einsatz bleibt, erreichen die darin enthaltenen Open-Source-Komponenten irgendwann ihr Lebensende – lange bevor Ihr System dies tut. Die Entwickler ziehen weiter, der offizielle Support wird eingestellt, und plötzlich nutzen Sie eine Lösung, für die keine Sicherheitsupdates mehr bereitgestellt werden. Das ist weder ein Fehler noch ein Zeichen für schlechte Planung. Es ist etwas, das in Unternehmensumgebungen, in denen Systemstabilität und kontrollierte Änderungen oberste Priorität haben, häufig vorkommt.
Und das kommt häufiger vor, als man denkt. Vielleicht nutzen Sie eine stabile Version, die seit Jahren im Einsatz ist und einwandfrei funktioniert. Möglicherweise haben Sie darauf aufbauend Integrationen entwickelt, deren Neugestaltung kostspielig wäre. Vielleicht haben Sie einen langwierigen Zertifizierungsprozess durchlaufen, den Sie nicht gerne wiederholen möchten. Oder die neueren Versionen bringen grundlegende Änderungen mit sich, die sich auf Ihr gesamtes System auswirken würden.
Auch wenn Ihre Systeme auf Langzeitbetrieb ausgelegt sind, verändert sich die Sicherheitslage ständig. Open-Source-Abhängigkeiten, die einst sicher waren und aktiv gepflegt wurden, sammeln zunehmend Schwachstellen an, die niemand beheben wird. Und viele dieser Probleme bleiben völlig verborgen. Sie liegen tief verborgen in den Schichten der Abhängigkeiten unterhalb der Komponenten, mit denen Sie tatsächlich interagieren.
Wenn Sie genauer erfahren möchten, inwiefern sich die Zeiträume für den Hersteller-Support von den Auslaufterminen der Endprodukte unterscheiden, lesen Sie unseren Leitfaden zum Thema „End of Life“ vs. „End of Support“.
Das Problem des Abhängigkeitsgraphen
Die meisten Teams betrachten die Open-Source-Komponenten, auf die sie angewiesen sind, als eine übersichtliche Liste in einer Manifestdatei. Doch jede dieser Bibliotheken bringt ihre eigenen Abhängigkeiten mit sich, und diese Abhängigkeiten wiederum haben ihre eigenen.
Selbst eine kleine Bibliothek kann auf eine Handvoll direkter Abhängigkeiten und eine lange Reihe transitiver Abhängigkeiten zurückgreifen, an die man gar nicht denkt. Und wenn eine Sicherheitslücke auftritt, kann sie überall sein: in der obersten Komponente, die man tatsächlich nutzt, in einer sekundären Bibliothek zwei Ebenen tiefer oder in einer tief verschachtelten Abhängigkeit, von der man noch nie etwas gehört hat.
Beachten Sie spring-boot-starter-web, eine gängige Wahl für Java-Webanwendungen. Durch das Hinzufügen dieser einzigen Abhängigkeit zu Ihrem Projekt werden automatisch über 25 transitive Abhängigkeiten: den gesamten Spring®-Framework-Stack, einen eingebetteten Tomcat-Server, Jackson für die JSON-Verarbeitung, mehrere Logging-Bibliotheken, Validierungsbibliotheken und vieles mehr.
Abbildung. Abhängigkeitsbaum von Spring® Boot Starter Web.
Sobald man sich also dazu verpflichtet, eine Open-Source-Komponente zu warten, ist man für deren gesamtes Abhängigkeitsnetzwerk verantwortlich. Eine Sicherheitslücke an irgendeiner Stelle dieses Netzwerks wird zu einem Problem, das man lösen muss. Und es gibt keinen einheitlichen Kanal, den man regelmäßig verfolgen kann, um zeitnah Informationen über Sicherheitslücken in all diesen zahlreichen Abhängigkeiten zu erhalten.
CVEs werden in Dutzenden verschiedener Sicherheitsdatenbanken, Mailinglisten und Projekt-Repositorys veröffentlicht. Ein kritisches Problem könnte in einer obskuren transitiven Abhängigkeit auftauchen, mit der Sie noch nie direkt zu tun hatten.
Sie müssen das gesamte Netzwerk kontinuierlich überwachen und dabei nicht nur die Komponenten verfolgen, die Sie direkt nutzen, sondern auch jede Abhängigkeit über mehrere Ebenen hinweg. Dabei müssen Sie auf neue Offenlegungen achten und feststellen, welche davon tatsächlich Auswirkungen auf Ihre spezifischen EOL-Versionen haben.
Was die Behebung einer Sicherheitslücke konkret beinhaltet
Wenn eine Sicherheitslücke irgendwo in diesem Abhängigkeitsgraphen auftritt, reicht es zur Behebung keinesfalls aus, einfach nur einen Patch zu installieren. Man muss die betroffene Komponente selbst aktualisieren und neu kompilieren, alle davon abhängigen Bibliotheken neu kompilieren, die gesamte Testsuite ausführen und sicherstellen, dass sich an der Integration oder der Paketierung nichts verändert hat.
Selbst wenn der Sicherheitspatch nur geringfügig ist und darauf ausgelegt ist, das bisherige Verhalten beizubehalten, ist eine Neuerstellung unvermeidlich. Nur so lässt sich ein Artefakt erstellen, dessen Bereitstellung Sie vertrauen können.
Manchmal kann man den Patch unverändert anwenden. In anderen Fällen wurde der Patch für eine neuere Version geschrieben und muss angepasst werden, damit er mit dem älteren Code und den älteren Versionen der Abhängigkeiten funktioniert, auf die Ihre „eingefrorene“ Komponente angewiesen ist. Wenn diese Anpassung nicht korrekt erfolgt, wird die Sicherheitslücke entweder nicht geschlossen oder die Kompatibilität mit den Systemen, die von dieser Komponente abhängen, beeinträchtigt.
Während eines fünfjährigen EOL-Supportzeitraums können Dutzende von Sicherheitslücken auftreten, von denen jede Maßnahmen entlang der gesamten Abhängigkeitskette der betroffenen Bibliothek nach sich zieht. Und da ständig neue Sicherheitslücken auftauchen, müssen Sie diesen Vorgang immer wieder durchlaufen, solange Sie an dieser EOL-Version festhalten. Jedes Mal ist derselbe Arbeitsablauf erforderlich: Patching, Neukompilierung, Testen, Validieren, Bereitstellung. Und jede Neukompilierung bringt ihre eigenen Herausforderungen mit sich.
Warum „eingefrorener Code“ nicht gleichbedeutend ist mit „eingefrorenen Builds“
Man könnte meinen, dass bei einem eingefrorenen Quellcode und festgelegten Abhängigkeiten ein erneuter Build immer zum gleichen Ergebnis führen sollte. In der Praxis funktioniert das jedoch nicht so.
Wenn Sie eine Anwendung fünf oder zehn Jahre lang betreuen, muss sich die Umgebung, in der Sie sie entwickeln, weiterentwickeln. Betriebssysteme erhalten Patches. Basis-Images werden aktualisiert. Compiler ändern sich. Zertifikatsketten werden rotiert. CI/CD-Tools werden aktualisiert. Container-Laufzeitumgebungen werden weiterentwickelt. Diese Aktualisierungen erfolgen aus guten Gründen, wie beispielsweise Sicherheit, Compliance und betrieblichen Erfordernissen, und sie finden unabhängig davon statt, ob sich Ihre EOL-Software ändert.
Jedes dieser Updates bringt kleine Änderungen in der Build-Umgebung mit sich, und diese Änderungen können sich im endgültigen Artefakt niederschlagen. Build-Tools entwickeln sich ebenso weiter wie alles andere. Ihre Algorithmen zur Abhängigkeitsauflösung und zur Paketierung von Artefakten ändern sich. Infolgedessen kann sich das Paketformat leicht verschieben oder die Metadaten anders strukturiert werden. Nichts davon verändert die eigentliche Funktionsweise der Komponente, aber es kann sich darauf auswirken, wie andere Bibliotheken mit ihr integriert werden oder wie Laufzeitumgebungen sie laden.
Die Welt dreht sich weiter, auch wenn Ihre EOL-Komponente stillsteht; daher muss jeder Neuaufbau denselben Grad an Validierung durchlaufen wie eine brandneue Version. Ein ausgereifter Patch-Prozess muss dies berücksichtigen – ebenso wie das sich im Laufe der Zeit wandelnde Team, das für die Wartung dieser Software verantwortlich ist.
Das Problem des Wissensverlusts
Wenn Sie Open-Source-Komponenten, deren Lebenszyklus abgelaufen ist (EOL), fünf bis zehn Jahre lang betreuen, arbeiten Sie mit Software, die nicht von Ihrem Team geschrieben wurde. Die ursprünglichen Betreuer haben das Projekt verlassen. Die Projekt-Community hat sich aufgelöst. Die Dokumentation – sofern überhaupt vorhanden – ist möglicherweise unvollständig, veraltet oder konzentriert sich eher auf neuere Versionen als auf die EOL-Version, die Sie betreuen.
Ihr Team übernimmt Komponenten, die es nicht selbst entwickelt hat, mit architektonischen Entscheidungen, die es nicht getroffen hat, und Abhängigkeiten, auf die es keinen Einfluss hatte. Um zu verstehen, wie man diese Komponenten sicher patcht, muss man sich in unbekannte Codebasen und Build-Prozesse einarbeiten, die vor Jahren von Personen entwickelt wurden, die man heute nicht mehr um Rat fragen kann.
Ohne dieses grundlegende Wissen wird jeder Patch-Zyklus schwieriger und mit größeren Risiken verbunden. Die Teams verbringen mehr Zeit mit der Fehlersuche als mit der Behebung, und die Wahrscheinlichkeit, dass subtile, funktionsbeeinträchtigende Änderungen eingeführt werden, steigt. Aus diesem Grund müssen ausgereifte Patch-Prozesse dem Wissensverlust durch umfassende Dokumentation und standardisierte Verfahren Rechnung tragen, die nicht davon abhängen, dass sich einzelne Mitarbeiter daran erinnern, wie die Dinge funktionieren.
Wie Prozessreife tatsächlich aussieht
Bei einem ausgereiften Patch-Prozess geht es nicht nur darum, Sicherheitslücken schneller oder sorgfältiger zu beheben. Es geht vielmehr darum, Systeme und Abläufe zu etablieren, die zuverlässig funktionieren – unabhängig davon, wann, wo oder wie oft Sicherheitslücken auftreten. Folgendes unterscheidet einen ausgereiften Betriebsablauf von einem reaktiven:
- Umfassende Überwachung über den gesamten Graphen hinweg. Ausgereifte Prozesse warten nicht darauf, dass Kunden CVEs melden. Sie überwachen aktiv die Schwachstellenlandschaft in jeder Schicht jedes von ihnen unterstützten Abhängigkeitsgraphen. Sie wissen, was sich hinter den von ihnen gewarteten Komponenten verbirgt, und erkennen Probleme frühzeitig.
- Standardisierte Verfahren für die Neuerstellung und Validierung. Jeder Patch löst denselben Workflow aus: Patch, Neuerstellung, Test, Validierung, Paketierung, Veröffentlichung. Der Ablauf bleibt unverändert, unabhängig vom Schweregrad der CVE oder der betroffenen Komponente. Diese Konsistenz macht den Prozess zuverlässig. Wenn man etwas hundert Mal auf dieselbe Weise macht, wird man darin gut. Wenn man jedes Mal improvisiert, übersieht man Dinge.
- Gründliche Kompatibilitätstests. Ausgereifte Prozesse stellen nicht nur sicher, dass die gepatchte Komponente isoliert funktioniert, sondern auch, dass sie sich korrekt in alle anderen Bibliotheken integriert, die davon abhängig sind. Sie berücksichtigen Umgebungsabweichungen und testen unter den Bedingungen, unter denen Kunden tatsächlich arbeiten, und nicht nur unter den idealen Laborbedingungen.
- Vorhersehbarer Rhythmus und Kommunikation. Kunden, die auf EOL-Software vertrauen, müssen sicher sein können, dass Sicherheitsprobleme konsequent behoben werden. Ausgereifte Prozesse legen klare SLAs fest, sorgen für transparente Kommunikation darüber, was wann gepatcht wurde, und stellen Updates über zuverlässige Kanäle bereit.
- Organisationswissen und Dokumentation. Wenn man über Jahre hinweg Dutzende von EOL-Komponenten wartet, kann man sich nicht auf einzelne Helden verlassen, die zufällig wissen, wie man eine bestimmte Bibliothek neu erstellt. Ausgereifte Prozesse dokumentieren alles: Build-Verfahren, Testanforderungen, bekannte Macken und Fallstricke bei der Integration. Dieses Wissen bleibt auch dann erhalten, wenn sich die Teammitglieder ändern.
Warum Perfektion im Prozess die langfristige Zuverlässigkeit bestimmt
Man kann einen perfekten Patch schreiben – mit minimalen Änderungen, unter Beibehaltung des bisherigen Verhaltens und gründlich getestet – und dennoch Probleme verursachen, wenn der damit verbundene Prozess schlampig ist. Möglicherweise übersieht man eine transitive Abhängigkeit, die ebenfalls aktualisiert werden musste. Der Neuaufbau könnte eine Änderung an der Paketierung mit sich bringen, die nachgelagerte Integrationen beeinträchtigt. Oder man behebt zwar eine CVE, übersieht aber die beiden anderen, die in derselben Woche an verschiedenen Stellen im Graphen aufgetaucht sind.
Das Schwierige am langfristigen Open-Source-Support besteht nicht nur darin, gute Patches zu schreiben. Es geht vielmehr darum, die Disziplin aufzubringen, diese über Jahre hinweg – trotz ständig neu aufgedeckter Sicherheitslücken – zuverlässig, wiederholt und fehlerfrei bereitzustellen. Bei einem Support über fünf Jahre nach Ablauf der Supportfrist kann dies fünfzig oder mehr Patches in einem komplexen Abhängigkeitsnetzwerk bedeuten. Unternehmen, die versuchen, dies reaktiv zu bewältigen, überlasten ihre Teams und liefern unzuverlässige Patches. Unternehmen, die in die Reife ihrer Prozesse investieren, sorgen für konsistente Sicherheit ohne Chaos.
Diese Disziplin lässt sich nur durch ausgereifte Prozesse erreichen: standardisierte Arbeitsabläufe, umfassende Überwachung, strenge Validierung und institutionelles Wissen, das über einzelne Mitarbeiter hinaus Bestand hat. Der Endless Lifecycle Support von TuxCare baut genau auf dieser Grundlage auf. Unser über Jahrzehnte verfeinerter Patching-Prozess bewältigt die gesamte Komplexität der langfristigen EOL-Wartung – von der Überwachung komplexer Abhängigkeitsgraphen bis hin zur Bereitstellung validierter, kompatibilitätserhaltender Patches, solange Ihre Systeme diese benötigen.
Prozessperfektion bedeutet, dass man jedes Mal, wenn eine CVE auftaucht (und das wird immer wieder passieren), auf dieselbe Weise reagiert. Der Patch wird korrekt installiert. Das ist es, was echte Open-Source-Zuverlässigkeit auf lange Sicht ausmacht: nicht das Fehlen von Schwachstellen, sondern das Vorhandensein von Prozessen, die ausgereift genug sind, um mit ihnen umzugehen – ganz gleich, wie viele davon auftauchen oder wo sie sich verstecken.
