Die versteckten Wartungskosten, BitRot!

Manchmal ist es für Kunden sehr schwer, die versteckten Kosten zu verstehen, die entstehen, wenn Sie maßgeschneiderte Software entwickeln. Mit versteckten Kosten meine ich ein Phänomen, das offenbar in unserer Branche wieder auftaucht: BitRot.

Was ist BitRot?

Früher wurde BitRot dadurch verursacht, dass die magnetischen Medien, auf denen wir unsere Computerprogramme gespeichert haben, manchmal ihre magnetischen Informationen verloren haben, was zu Problemen beim Zurücklesen der Daten führte. Seit die Industrie zu neuen Methoden der Datenspeicherung übergegangen ist, wie z.B. Solid-State-Laufwerke, ist das Problem zwar immer noch vorhanden, aber nicht mehr in erster Linie sichtbar. Wir haben Algorithmen, die unsere Daten so speichern, dass die verlorenen Daten wiederhergestellt werden können, und aus der Sicht des Endbenutzers scheint BitRot vollständig verschwunden zu sein.

Datenverschlechterung - Wikipedia

BitRot neu definiert

Obwohl das ursprüngliche Problem mehr oder weniger verschwunden ist, sehen wir uns nun mit einer völlig neuen Art und Weise konfrontiert, wie BitRot in unserer Branche wieder auftaucht. Sie mögen mir widersprechen, wenn ich den Namen BitRot für etwas anderes verwende, aber im Grunde manifestiert sich das Problem, mit dem wir konfrontiert sind, auf dieselbe Weise. Wenn wir die Software nicht anfassen, schreiben wir auch nur ein paar Wochen lang, und die Software verkommt!

Lassen Sie mich erklären, was hier vor sich geht.

BitRot ist heute das Problem, wenn wir unsere Software ein paar Tage oder Wochen lang nicht anfassen und die Software durch eine Reihe von Quellen verschlechtert wird. Lassen Sie mich einige der Probleme nennen, mit denen Sie konfrontiert werden, wenn Sie heute Software entwickeln.

Neue bekannte Schwachstellen

Eine bekannte Sicherheitslücke ist eine Schwachstelle in der von Ihnen geschriebenen Software oder in einer Software, die Sie zur Erstellung Ihrer Anwendung oder Website verwendet haben und die jemand ausnutzen kann. Sie werden sich vielleicht fragen, warum meine Software plötzlich ausnutzbar wird, obwohl ich sie nicht angerührt habe. Das liegt daran, dass die Angreifer jeden Tag schlauer werden. Sie finden neue innovative Wege, um Software auszunutzen. Da die geschriebene Software oft Unmengen von Code enthält, der nicht nur von Ihrem eigenen Unternehmen geschrieben wurde, sondern auch Open-Source-Komponenten enthält, ist die Chance, dass Ihre Software selbst angreifbar wird, ein erhebliches Risiko. Das bedeutet nicht sofort, dass Ihre Software auch ausgenutzt wird, aber die Wahrscheinlichkeit, dass Ihre Software ausnutzbar wird, steigt fast jeden Tag. Sie müssen dies im Auge behalten und Ihre Software aktualisieren oder ändern, um mit dem aktuellen Stand der Branche Schritt zu halten. Auch die Zahl der gefundenen Sicherheitslücken nimmt ständig zu. In der folgenden Grafik, die der NVD veröffentlicht[1], können Sie sehen, wie schnell sich dies beschleunigt. Ich habe eine Aufnahme des Diagramms hinzugefügt, die zeigt, wie viele bekannte Sicherheitslücken gefunden werden und dass die Rate der gefundenen Sicherheitslücken ständig steigt.

CVSS-Schweregradverteilung über die Zeit

NVD - CVSS-Schweregradverteilung im Zeitverlauf (nist.gov)

Updates der verwendeten Frameworks oder Pakete

Ihre Software wird selten von Grund auf neu entwickelt. Um Software zu erstellen, werden Sie ständig andere Softwarekomponenten verwenden. Je nachdem, mit welcher Technologie Sie Ihre Programme schreiben, verwenden Sie NuGet-Pakete (.NET), Maven-Pakete (Java), Node-Pakete (Node/Web-Entwicklung), RubyGems (Ruby-Entwicklung) usw. Diese Pakete werden von anderen erstellt und gewartet. Um auf das vorherige Thema zurückzukommen, müssen auch sie ihre Software pflegen, um sie frei von bekannten Sicherheitslücken zu halten. Außerdem wollen sie ständig neue Fähigkeiten und Funktionen bereitstellen. Das bedeutet, dass diese Pakete ständig neue Versionen erhalten, und es ist nicht leicht, mit diesen neueren Versionen Schritt zu halten.

Nehmen wir an, Sie erstellen eine einfache Hello World-Webanwendung mit .NET 6 und React. Sie können den Screenshot sehen, den ich bei der Erstellung der Anwendung in Visual Studio 2022 gemacht habe:

Neues ASP.NET mit React Projekt

Dies führt zu einer erstaunlichen Anzahl von Schwachstellen aus dem NodeJS-Ökosystem und 15 weiteren aus dem .NET-Ökosystem. Ausgehend von einer sauberen Vorlage (ich habe alles aktualisiert, bevor ich die Anwendung in Visual Studio erstellt habe), ergab dies bereits 23 bekannte Schwachstellen, von denen 9 auf der Stufe Hoch!

Analyse eines neuen Projekts mit Dependabot (GitHub)

Updates zu Compilern und Werkzeugen

Dann gibt es noch die Abhängigkeiten von Visual Studio 2022, für das es mindestens einmal im Monat Updates gibt. Wir haben eine Abhängigkeit vom .NET Framework, das mindestens alle zwei Jahre aktualisiert wird und eine neue stabile Version hat, die maximal 3 Jahre lang unterstützt wird. Ganz zu schweigen von all den kleinen Updates, die zur Behebung von Fehlern und Schwachstellen kommen können. Und schließlich haben wir eine Abhängigkeit von den NodeJS-Tools übernommen, die ebenfalls mehrmals im Jahr aktualisiert werden. Diese Tools neigen ebenfalls zu bahnbrechenden Änderungen. Sie müssen sie ständig auf dem neuesten Stand halten, denn auch sie können bekannte Sicherheitslücken enthalten, die Ihre Entwicklungsumgebung gefährden könnten!

Neuere Versionen der Sprachen und Frameworks

Schließlich gibt es auch Abhängigkeiten von den Sprachen, die wir verwenden. In diesem Beispiel habe ich React verwendet, das auf Javascript/Typescript basiert, und C#10 für die .NET-Codebasis. C# wird in einem jährlichen Zyklus aktualisiert, und wenn Sie sich

bei den Versionen von Node, dann sehen Sie, dass Sie diese alle sechs Monate aktualisieren müssen:

Veröffentlichungen - Node.js (nodejs.org)

Diese Sprach- und Framework-Updates können erheblich sein, wenn Sie sich den Arbeitsaufwand ansehen, der mit der Nutzung der neuen Funktionen verbunden ist. Wenn Sie sie nicht nutzen, verschlechtert sich Ihre Codebasis aus Sicht der Wartbarkeit, da die Branche neue Wege zur Nutzung der Sprach- und Framework-Funktionen beschreitet. Neue Teammitglieder in einem Projekt werden es schwer haben, alte Programmierstile und Ineffizienzen zu übernehmen, wenn Sie nur sicherstellen, dass der Code kompilierbar ist.

Wie können wir dieses Problem entschärfen?

Zuallererst ist es wichtig, dass Sie sich Zeit nehmen, um alles sauber zu halten. Das bedeutet, dass Sie ein bestimmtes Zeitbudget für die Aktualisierung Ihrer Pakete einplanen und sich die Zeit nehmen, auf neuere Minor- oder Major-Versionen von Paketen zu aktualisieren, die verfügbar sind. Es gibt kein Patentrezept für die Lösung dieses Problems, aber sich die Zeit dafür zu nehmen, ist ein Schritt in die richtige Richtung.

Zweitens können Sie einiges davon automatisieren, wenn Sie z.B. GitHub als DevOps-Plattform verwenden. Hier haben Sie die Möglichkeit, eine Funktion namens Dependabot zu aktivieren, die Sie darüber informiert, dass Ihre Pakete veraltet sind oder bekannte Sicherheitslücken enthalten. Wenn er weiß, dass die Schwachstelle mit einer neuen Paketversion entschärft werden kann, erstellt er sogar eine Pull-Anfrage für Sie. Sie müssen diese jedoch noch überprüfen und den PR genehmigen, damit er Teil der Hauptcodebasis wird. Es gibt auch Tools, die sich in die meisten DevOps-Plattformen integrieren lassen, um automatische Updates für Sie zu verwalten, z.B. Renovate[1].

Und die letzte Prüfung ist: Wann nehme ich die Abhängigkeit? Seien Sie sich der Tatsache bewusst, dass die Übernahme der Abhängigkeit zusätzliche Wartungskosten verursacht. Wenn Sie selbst etwas bauen, entstehen ebenfalls erhebliche Kosten, aber das sollte eine Entscheidung sein, die Sie treffen, und nicht nur eine Voreinstellung, die Sie immer akzeptieren. Seien Sie sich des Kompromisses bewusst und dass eine Abhängigkeit auch Kosten verursacht.

Fazit

Die Software, die Sie erstellen, befindet sich in einem ständigen Verfallsprozess, und Sie müssen einen erheblichen Teil Ihrer Zeit dafür aufwenden, die Dinge immer wieder zu aktualisieren und auf den neuesten Stand zu bringen. Das Warten auf Ihre Aktualisierungen kostet Sie deutlich mehr Zeit als die ständige Aktualisierung. Das Sprichwort "Wenn es weh tut, mach es öfter" gilt hier und macht die Kadenz der Softwarebereitstellung berechenbarer und sicherer. Machen Sie also die Aktualisierung von Paketen, Frameworks und Sprachen zu einem Teil des normalen Wartungszyklus!

Die eigentliche Herausforderung besteht darin, unsere Kunden für dieses Problem zu sensibilisieren und Wege zu finden, sie darauf aufmerksam zu machen, dass sie ihre Software pflegen müssen. Sie können Software nicht ein paar Wochen lang unangetastet lassen, denn in der Zwischenzeit wird die Software veraltet und angreifbar. Und nicht zuletzt wird es jeden Tag komplizierter, sie wieder auf den neuesten Stand zu bringen.

[1] Docs renovatebot.com/

 

Strategien zur Anwendungsmodernisierung für IT-Führung und Innovation

Anwendungsmodernisierung ist ein heißes Thema, aber wussten Sie, dass nur 21% der Bemühungen sind erfolgreich? Was macht es also so schwer, es durchzuziehen? Und wie können Sie sicherstellen, dass Sie sich auf den Erfolg vorbereiten? Lesen Sie unser eBook und erfahren Sie, wie Sie sich auf die Modernisierung vorbereiten und sie erfolgreich umsetzen können. eBook herunterladen