Veraltete Software als Sicherheitsrisiko: Update oder Umbau?

Die Antwort zuerst: Update, solange es geht

Veraltete Software ist ein Sicherheitsrisiko, sobald ihre Laufzeit, ihr Framework oder ihre Bibliotheken keine Sicherheitsupdates mehr erhalten. Wenn sich alle Bestandteile noch auf unterstützte Versionen heben lassen, ist ein Update im Bestand der richtige Weg. Ein Umbau wird nötig, wenn einzelne Abhängigkeiten das Update blockieren. Dann bringt eine zeitlich begrenzte Abschirmung Zeit, und ein schrittweiser Ersatz der blockierenden Teile löst das Problem dauerhaft.

Dieser Artikel richtet sich an Entwicklungs- und IT-Leitungen, die eine selbst entwickelte oder beauftragte Anwendung betreiben. Er erklärt, woran Sie das Risiko erkennen, warum Updates an Abhängigkeiten scheitern und wie Sie zwischen Update, Abschirmung, schrittweisem Ersatz und Neubau wählen. Das Vorgehen beim schrittweisen Ersatz selbst beschreibt der Artikel Altsysteme schrittweise ablösen.

Warum das Ende des Supports das Risiko ausmacht

Jede Anwendung baut auf fremder Software auf: einer Laufzeit wie Java, .NET, PHP, Node.js oder Python, einem Framework und meist Dutzenden Bibliotheken. Die Hersteller dieser Bausteine pflegen jede Version nur für eine begrenzte Zeit. Danach erscheinen keine Sicherheitsupdates mehr, auch wenn neue Lücken bekannt werden. Genau ab diesem Zeitpunkt wird veraltete Software zum Sicherheitsrisiko, nicht erst, wenn sie technisch Probleme macht.

Die Zeiträume unterscheiden sich stark. Die folgende Tabelle zeigt die veröffentlichten Regeln einiger verbreiteter Laufzeiten und Frameworks, Stand 11. Oktober 2026:

Microsoft formuliert die Konsequenz deutlich: Die Nutzung von .NET-Versionen ohne Support könne Anwendungen, Daten und Umgebung gefährden, und von ihrer Nutzung werde dringend abgeraten. Microsoft: .NET Support Policy.

Das Risiko hängt dabei nicht nur an der Laufzeit. Die OWASP Top 10 führen in der Ausgabe 2025 unter A03:2025 Software Supply Chain Failures ausdrücklich Software auf, die verwundbar, nicht mehr unterstützt oder veraltet ist, einschließlich Betriebssystem, Anwendungsserver, Datenbank, Laufzeitumgebung und Bibliotheken. Die Empfehlung lautet, Plattform, Frameworks und Abhängigkeiten risikobasiert und zeitnah zu aktualisieren. OWASP Top 10:2025, A03.

Eine Anwendung ist also so aktuell wie ihr ältester Bestandteil. Ein aktuelles Framework auf einer Laufzeit ohne Support hilft wenig.

Bestandsaufnahme: Was genau ist veraltet?

Bevor Sie über Update oder Umbau entscheiden, würde ich den tatsächlichen Stand festhalten. Dafür reicht zunächst eine Liste mit vier Spalten: Bestandteil, eingesetzte Version, Supportstatus laut Hersteller, Datum der Prüfung.

Zu den Bestandteilen gehören:

• die Laufzeit und ihre Version,
• das Framework und seine Version,
• die direkten Bibliotheken aus der Abhängigkeitsdatei des Projekts,
• die indirekten Bibliotheken, die diese Bibliotheken ihrerseits mitbringen,
• Datenbank, Anwendungsserver und Betriebssystem der Umgebung.

Den Supportstatus prüfen Sie auf der Seite des jeweiligen Herstellers. Für bekannte Schwachstellen in den eingesetzten Versionen nennt OWASP die Quellen CVE, NVD und OSV, die laufend beobachtet werden sollten. OWASP Top 10:2025, A03.

Drei Zustände reichen für die Einordnung: unterstützt, nur noch Sicherheitsupdates und Ende des Supports erreicht. Dazu würde ich notieren, ob die Anwendung aus dem Internet erreichbar ist und welche Daten sie verarbeitet. Eine interne Anwendung mit Stammdaten ist anders zu bewerten als ein Kundenportal mit Rechnungsdaten. Beide brauchen einen Plan, aber nicht dieselbe Dringlichkeit.

Warum das Update scheitert: an den Abhängigkeiten, nicht am Framework

Viele Updates scheitern nicht am Framework selbst, sondern an den Bausteinen dazwischen. Der Grund liegt in der Versionierung. Nach der verbreiteten semantischen Versionierung kündigt eine neue Hauptversion inkompatible Änderungen an der Schnittstelle an; nur Neben- und Korrekturversionen bleiben abwärtskompatibel. Semantic Versioning. Ein Sprung auf die nächste Hauptversion eines Frameworks zieht deshalb oft Änderungen durch die gesamte Abhängigkeitskette.

Ein belegtes Beispiel ist der Wechsel von Spring Boot 2 auf Spring Boot 3. Spring Boot 3.0 setzt Java 17 voraus; Java 8 wird nicht mehr unterstützt. Zugleich wechselten die Jakarta-EE-Pakete von javax auf jakarta. Die Migrationsanleitung weist darauf hin, dass für nicht von Spring Boot verwaltete Abhängigkeiten zuerst eine kompatible Version gefunden werden muss und dass alte Java-EE-Abhängigkeiten weder direkt noch indirekt im Build verbleiben dürfen. Spring Boot 3.0 Migration Guide.

Aus solchen Regeln entstehen die typischen Blockaden, die ich in der Praxis als „Abhängigkeiten nicht aktualisierbar“ zusammenfasse:

• Eine Bibliothek wird nicht mehr gepflegt. Für das neue Framework gibt es keine passende Version, und niemand wird sie liefern.
• Eine Bibliothek wurde intern verändert. Eigene Korrekturen am fremden Code müssen bei jedem Update neu eingearbeitet werden; irgendwann unterbleibt das.
• Zwei Bibliotheken verlangen unvereinbare Versionen einer dritten. Das Projekt sitzt zwischen den Stühlen.
• Ein eigenes Modul hängt an internen Details des Frameworks, etwa an nicht dokumentierten Klassen, die in der neuen Version fehlen.

Jede dieser Blockaden lässt sich lösen. Entscheidend ist, wie viele es sind und wie eng die blockierten Teile mit dem Rest verwoben sind. Daraus ergibt sich die Wahl zwischen den vier Wegen.

Vier Wege im Vergleich

Update im Bestand

Das Update ist die erste Wahl, wenn es möglich ist. Es verändert nichts an Architektur und Fachlogik. Ich würde es in kleinen Schritten angehen: erst die Bibliotheken innerhalb der aktuellen Hauptversion aktualisieren, dann das Framework, dann die Laufzeit. Nach jedem Schritt laufen die Tests. Fehlen automatisierte Tests, ist deren Aufbau für die wichtigsten Abläufe der eigentliche erste Schritt. Ohne sie merken Sie Verhaltensänderungen erst im Betrieb.

Abschirmung auf Zeit

Wenn eine bekannte Lücke offen ist und das Update Wochen braucht, hilft eine Zwischenlösung. OWASP beschreibt dafür das virtuelle Patchen: eine vorgelagerte Schicht, die bekannte Angriffsmuster abfängt, bevor sie die Anwendung erreichen. OWASP nennt als Anwendungsfälle ausdrücklich Altcode ohne Herstellersupport und Situationen, in denen ein Patch lange auf sich warten lässt. Zugleich stuft OWASP das Verfahren als vorübergehende Hilfe ein, die Zeit für die eigentliche Korrektur im Quellcode verschafft. OWASP: Virtual Patching Best Practices.

Dazu gehört in der Praxis, den Netzzugang auf die Systeme zu beschränken, die die Anwendung wirklich brauchen. Beides ist eine Brücke, kein Ziel. Ich würde das Enddatum der Abschirmung von Anfang an festlegen.

Schrittweiser Ersatz

Blockiert nur ein Teil der Anwendung das Update, etwa ein Berichtsmodul mit einer verwaisten Bibliothek, lässt sich dieser Teil als eigene Komponente herauslösen. Der Rest wird aktualisiert, die neue Komponente läuft auf aktuellen Versionen, und eine vereinbarte Schnittstelle trennt beides. Die Schritte dafür, von der fachlichen Abgrenzung über die Fassade bis zur Umschaltung und zum Rückweg, beschreibt der Artikel Altsysteme schrittweise ablösen. Wird die neue Komponente als eigener Dienst betrieben, gelten die dort genannten Voraussetzungen für Betrieb und Überwachung.

Neubau

Ein Neubau ist dann sinnvoll, wenn die Blockaden nicht an einzelnen Stellen sitzen, sondern überall, oder wenn die Fachabteilung den Prozess ohnehin anders abbilden will. Er ist zugleich der Weg mit der längsten Zeit ohne nutzbares Zwischenergebnis. Die alte Anwendung bleibt währenddessen mit ihren Lücken in Betrieb. Deshalb würde ich auch bei einem Neubau prüfen, ob sich der erste nutzbare Teil nicht doch vorziehen lässt.

Beispiel: Eine Auftragsanwendung auf Spring Boot 2.7

Das folgende Beispiel ist fiktiv und dient der Veranschaulichung.

Ein Unternehmen betreibt eine intern entwickelte Anwendung für die Auftragsbearbeitung. Sie läuft auf Java 8 und Spring Boot 2.7. Der Open-Source-Support für Spring Boot 2.7 endete laut Spring am 30. Juni 2023. Spring: Generations. Das Entwicklungsteam hat das Update auf Spring Boot 3 zweimal begonnen und abgebrochen.

Die Bestandsaufnahme ergibt drei Blockaden:

1. Die Laufzeit muss von Java 8 auf mindestens Java 17, was Spring Boot 3 voraussetzt. Das betrifft die Build-Umgebung und die Server, ist aber mit Herstellerdokumentation lösbar.
2. Eine Bibliothek zur Berichtserstellung existiert nur in einer Version mit javax-Paketen. Der Hersteller pflegt sie nicht mehr.
3. Ein Modul zur Preisberechnung nutzt interne Klassen des alten Frameworks, die in Spring Boot 3 nicht mehr existieren.

Für dieses Beispiel würde ich so entscheiden:

• Abschirmung sofort: Die Anwendung ist nur aus dem Firmennetz erreichbar. Der Zugang wird auf die Arbeitsplätze der Auftragsbearbeitung und auf das ERP beschränkt. Bekannte Lücken in den eingesetzten Versionen werden gegen CVE und NVD geprüft. Enddatum der Abschirmung: der Abschluss des Updates.
• Herauslösen des Berichtsmoduls: Die Berichtserstellung wird als eigene Komponente neu gebaut, auf Java 21 und einer gepflegten Bibliothek. Sie erhält die Auftragsdaten über eine kleine Schnittstelle. Der alte Berichtscode bleibt bis zur Abnahme erreichbar und wird dann entfernt.
• Umbau des Preismoduls im Bestand: Die Nutzung interner Framework-Klassen wird durch dokumentierte Schnittstellen ersetzt. Vorher entstehen Tests für die wichtigsten Preisfälle, damit das Ergebnis vergleichbar bleibt.
• Update des Kerns: Erst wenn beide Blockaden gelöst sind, folgt das Update der verbleibenden Anwendung auf Java 21 und Spring Boot 3.5. Ein späterer Wechsel auf Spring Boot 4 wird eingeplant, bevor der Support für 3.5 endet.

Das Ergebnis dieses Beispiels wäre keine neue Architektur. Es wäre eine aktualisierbare Anwendung mit einer herausgelösten Komponente. Ob sich das Vorgehen in Ihrer Situation lohnt, hängt davon ab, wie viele Blockaden es gibt und wie gut sie sich abgrenzen lassen. Aufwände in Personentagen lassen sich aus diesem Beispiel nicht ableiten.

Wann ein Update genügt und Sie keinen Umbau brauchen

Ein Umbau ist nicht immer nötig. In diesen Fällen würde ich ihn ausdrücklich nicht empfehlen:

• Alle Abhängigkeiten haben kompatible Versionen. Dann ist das Update Routinearbeit für das eigene Team. Ein externer Entwickler bringt wenig.
• Die Anwendung wird ohnehin in absehbarer Zeit abgeschaltet. Dann reicht eine Abschirmung bis zum Abschalttermin. Der Termin muss allerdings verbindlich sein.
• Es fehlen Tests, aber keine Versionen. Dann ist der erste Schritt Testabdeckung, nicht Architektur.
• Nur die Umgebung ist alt, etwa Betriebssystem oder Datenbank, die Anwendung selbst aber aktuell. Dann liegt die Aufgabe beim Betrieb.

Für Unternehmen im Anwendungsbereich der NIS-2-Richtlinie kann es einen zusätzlichen Anlass geben: Artikel 21 Absatz 2 Buchstabe e verlangt von wesentlichen und wichtigen Einrichtungen Maßnahmen zur Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich des Umgangs mit Schwachstellen. Ob Ihr Unternehmen in den Anwendungsbereich fällt, klärt die Richtlinie und ihre nationale Umsetzung: Richtlinie (EU) 2022/2555, Artikel 21.

Updates dauerhaft möglich halten

Wer einmal eine Blockade gelöst hat, sollte die nächste verhindern. Dafür würde ich zwei Regeln vereinbaren.

Abhängigkeiten laufend aktualisieren statt in Sprüngen. Werkzeuge wie Dependabot prüfen die Abhängigkeitsdateien eines Projekts auf neuere Versionen und öffnen dafür automatisch Pull Requests. GitHub dokumentiert dafür die Konfiguration über eine Datei dependabot.yml, eine standardmäßige Wartezeit von drei Tagen nach einer Veröffentlichung und getrennte Sicherheitsupdates für Abhängigkeiten mit bekannten Schwachstellen, für die diese Wartezeit nicht gilt. GitHub: Dependabot version updates. Vergleichbare Werkzeuge gibt es für andere Plattformen. Viele kleine Updates sind leichter zu prüfen als ein großes nach drei Jahren.

Keine eigenen Änderungen an fremden Bibliotheken. Wenn eine Bibliothek nicht passt, gehört die Anpassung in eine eigene Schicht davor, nicht in deren Code. Lässt sich das nicht vermeiden, wird die Änderung dokumentiert und dem Projekt der Bibliothek angeboten.

Beide Regeln kosten laufend etwas Zeit. Sie sparen die Wochen, die ein blockiertes Update später verschlingt.

Der nächste Schritt

Wenn Ihre Bestandsaufnahme eine oder mehrere Blockaden zeigt, die sich nicht mit Bordmitteln lösen lassen, beschreibt die Seite Software-Modernisierung für bestehende Teams, wie ich Ihr Entwicklungsteam dabei unterstützen kann: Blockaden eingrenzen, den ersten Teil herauslösen und das Update des Kerns möglich machen. Das Team behält dabei die Verantwortung für seine Anwendung.

Wenn Sie noch nicht wissen, ob Ihr Fall ein Update oder einen Umbau braucht, ist das Erstgespräch der kleinste sinnvolle Schritt. Bringen Sie die Liste aus der Bestandsaufnahme mit.

Quellen und Einordnung

Supportregeln und Enddaten stammen von den Herstellerseiten von PHP, Node.js, Microsoft, Spring, Python und Adoptium, abgerufen am 11. Oktober 2026. Die Einordnung veralteter Komponenten folgt den OWASP Top 10:2025 und den OWASP-Hinweisen zum virtuellen Patchen. Die Aussagen zur Versionierung und zum Spring-Boot-3-Wechsel stützen sich auf semver.org und die Migrationsanleitung des Spring-Boot-Projekts. Die Auftragsanwendung im Beispiel ist eine eigene Veranschaulichung und kein Kundenprojekt. Enddaten ändern sich; prüfen Sie sie vor einer Entscheidung erneut beim Hersteller.