Alt ist Software erst, wenn niemand mehr patcht

Wir aktualisieren gerade unsere eigene Software. Zwei Vorgänge, zwei völlig verschiedene Hausnummern.

Der kleine Sprung

Im Frontend geht es von Angular 21.1 auf 21.2. Gleiche Hauptversion, überschaubare Arbeit, kein Umbau.

Zwischen diesen beiden Ständen liegen drei veröffentlichte XSS-Schwachstellen. Zwei davon sind hoch eingestuft, mit CVSS-Werten von 8.6 und 8.1. Eine davon wurde erst Anfang August bekannt.

Ob unsere Anwendung darüber tatsächlich angreifbar war, ist eine andere Frage. Zwei der drei Lücken hängen an einer Angular-Funktion, die wir gar nicht einsetzen. Nach heutigem Stand waren sie bei uns also nicht ausnutzbar.

Wir haben trotzdem aktualisiert.

Der Grund ist unspektakulär: Diese Frage sauber zu beantworten kostet mehr Zeit als das Update selbst. Wer für jede gemeldete Lücke erst prüft, ob sie ihn betrifft, hat am Ende mehr Aufwand als der, der einfach patcht.

Der große Sprung

Im Backend steht Spring Boot 3.5 auf 4.1 an. Das ist kein Vormittag.

Bei einem Wechsel der Hauptversion wird Code angefasst. Schnittstellen fallen weg, Verhalten ändert sich, und der Sprung zieht andere Bibliotheken mit, die damit eigentlich nichts zu tun hatten. Solche Migrationen wollen geplant, getestet und abgesichert sein.

Beides heißt Wartung. Der Aufwand liegt trotzdem in völlig verschiedenen Größenordnungen.

Diese Unterscheidung ist der Kern des Themas. Es gibt einen billigen Weg und einen teuren Weg, Software sicher zu halten. Wer regelmäßig aktualisiert, geht fast immer den billigen.

Warum die Updates häufiger kommen

Die Zahl der Sicherheitsupdates von Plattform- und Framework-Herstellern ist spürbar gestiegen. Das hat einen unbequemen Grund.

Angreifer und Hersteller haben dasselbe Werkzeug bekommen. Beide lassen inzwischen Modelle über Code laufen und suchen nach Schwachstellen. Was früher mühsame Handarbeit war, läuft heute in großem Maßstab.

Der entscheidende Unterschied liegt darin, was danach passiert.

Der Angreifer ist fertig, sobald er die Lücke gefunden hat. Der Hersteller fängt an dieser Stelle erst an. Er muss einen Patch bauen, ihn testen, ihn für mehrere Versionszweige zurückportieren und ausliefern. Und dann muss der Kunde ihn auch noch einspielen.

Diese Asymmetrie ist der eigentliche Treiber. Nicht die Technik, sondern die Reihenfolge der Arbeit.

Was das für ältere Software bedeutet

Für uns bedeutet die höhere Frequenz vor allem eines: mehr Wartung. Unangenehm, aber beherrschbar.

Für einen Betrieb, dessen Version der Hersteller nicht mehr pflegt, bedeutet es etwas anderes. Ihm steht der kleine Weg gar nicht offen. Für seinen Stand erscheint kein Patch mehr, weil dieser Versionszweig aus der Pflege heraus ist.

Jede neue Lücke ist dort sofort der große Weg. Also Migration, Umbau oder Ablösung.

Das ist keine Frage von Disziplin. Es ist Arithmetik. Wer auf einem gepflegten Stand bleibt, zahlt kleine Beträge in kurzen Abständen. Wer aus der Pflege fällt, zahlt einmal viel, und zwar dann, wenn es gerade nicht passt.

Wenn es den Hersteller nicht mehr gibt

Der schwierigste Fall ist ein anderer. In vielen Betrieben läuft Software, deren Hersteller nicht mehr erreichbar ist. Die Firma existiert nicht mehr, der Entwickler ist im Ruhestand, oder der Kontakt ist über die Jahre eingeschlafen.

Diese Betriebe können nicht einmal entscheiden, ob sie patchen wollen. Es gibt niemanden, der patcht.

Solange die Software läuft, fällt das nicht auf. Auffallen tut es an dem Tag, an dem etwas passiert. Und dann ist die erste Frage nicht, wie man die Lücke schließt. Sondern wer das überhaupt könnte.

Wie wir damit umgehen

Bei spiritdev gehört die Pflege der eingesetzten Frameworks zum laufenden Betrieb, nicht zu den Sonderprojekten. Das ist der Grund, warum unser eigener Frontend-Sprung ein Vormittag war und keine Migration.

Bei Bestandssystemen, deren Versionsstand nicht mehr gepflegt wird, gehen wir schrittweise vor. Bestandsanalyse, dann die Ablösung Modul für Modul, während der Betrieb weiterläuft. Wie das konkret aussieht, haben wir in Die Software, die nur noch einer versteht beschrieben.

Software war früher alt, wenn sie sich alt anfühlte. Wenn die Oberfläche aus der Mode kam oder die Bedienung umständlich wurde.

Heute ist Software alt, wenn niemand mehr Patches dafür baut. Und dieser Zeitpunkt kommt inzwischen schneller, als die meisten Betriebe ihre Software abschreiben.