Startseite > Distribution > Der Ausweg aus der »Dependency Hell«

Software-Obsoleszenz

Der Ausweg aus der »Dependency Hell«

5. November 2023, 11:00 Uhr | Heinz Arnold

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

»In den Unternehmen fehlen oft Obsoleszenzbeauftragte«

Handelt es sich um Open-Source-Software, dann werden bei der Community Bug-Fixes angefordert, oder die Inhouse-Software-Abteilung arbeitet sich in den Source-Code ein, wie Steinleitner erklärt: »Dann heißt es warten, bis etwas zurückkommt – solange habe ich den Fehler und der Obsoleszenz-Fall ist eingetreten.«

Dazu gibt er ein bekanntes Beispiel, das vor einiger Zeit auftrat: »Log4Jj« ist ein Open-Source-Framework für das Logging von Anwendungsmeldungen in Java, das für die Aufzeichnung von Messages entwickelt wurde. Es ist einfach zu nutzen und wird sehr häufig benutzt. Dort wurde am 10. 12. 2021 ein sicherheitsrelevanter Fehler entdeckt. Es handelte sich um ein sogenanntes Zero-Day-Exploit: Hacker haben eine Schwachstelle entdeckt, die bisher nur ihnen bekannt war, um sie für ihre Zwecke auszunutzen. Die Anwender und Entwickler der Software erhalten erst dann Kenntnis von der Schwachstelle, wenn entsprechende Angriffe bekannt werden. Auch der Hersteller erhält nur über diesen Weg Kenntnis von der Schwachstelle und konnte noch keinen Patch bereitstellen, um die Nutzer vor den Angriffen zu schützen. Daher der Begriff Zero-Day-Exploit.

Am 16. 12. berichtete das belgische Militär von Angriffen über diese Sicherheitslücke. Am 17. 12. musste das ebenfalls angegriffene deutsche Finanzministerium seine Website herunterfahren. »Es war sehr schwer herauszufinden, wo Log4Jj überall drinsteckte, und das Desaster war da, viele Komplettabschaltungen waren die Folge. Das nenne ich Software-Obsoleszenz«, so Steinleitner. Das Gemeine an Log4j: Auch wenn der Code, den ein Unternehmen selber geschrieben hat, Log4j nicht benutzt, besteht dennoch eine hohe Wahrscheinlichkeit, dass andere Libraries oder Frameworks dies tun. Zwar gibt es von vielen Unternehmen Patches, aber einige Unternehmen haben immer noch nicht reagiert. Andere dürften der Meinung sein, dies getan zu haben, doch in ihren Systemen verstecken sich bislang unbemerkt dennoch einige ungepatchte Softwareteile.

Es kann auch aus verschiedenen Gründen vorkommen, dass eine Softwaregruppe im Open-Source-Projekt sich plötzlich nicht mehr um ein bestimmtes Modul kümmert. Dann wird es für alle Anwender brenzlig. »Jetzt müssen sie wissen, wo überall das betreffende Modul drinsteckt – das ist Software-Obsoleszenz!«, so Steinleitner.
Steinleitner kann mit einem weiteren Beispiel aufwarten: Es geht um »Babel«, einen JavaScript-Transcompiler, der für HTML in allen Browser-Versionen gebraucht wird. »Babel wurde von sechs Personen gepflegt, die pro Jahr dafür rund 330.000 Dollar benötigten. Normalerweise kommt das Geld über Sponsoren regelmäßig zusammen. 2021 konnten aber nur 150.000 Dollar eingesammelt werden.

Dennoch haben Entwickler weitergemacht. Aber was passiert, wenn einige sich etwa aus wirtschaftlichen Gründen kurzfristig verabschieden müssen?«, fragt Steinleitner. »Das ist die Abhängigkeits-Hölle der Software, denn dann kommt eine riesige Welle von Problemen auf einen zu, wenn man die Abhängigkeiten nicht kennt. Die SBOMs sind genau dazu da, dies zu vermeiden.« Denn zwar kann die SBOM auch nicht davor bewahren, dass solche Dinge passieren, aber die Reaktionszeit liegt dann wesentlich niedriger und keiner muss in Panik ausbrechen.

Was zu tun wäre

Doch was soll ein Unternehmen machen, das die Wichtigkeit erkannt hat und jetzt eine Organisation dafür aufbauen will? Das kann im Wesentlichen analog zum Aufbau des normalen Obsoleszenzmanagements geschehen. Eine interne Organisation mit entsprechenden Prozessen muss etabliert werden, die genau plant, was zu geschehen hat, falls etwas passiert.

Die Prozesse in der Software-Entwicklungsabteilung werden ergänzt, um die SBOMs zu erstellen und zu pflegen. Außerdem müssen die Prozesse sicherstellen, dass in der SBOM proaktiv die zugekauften und die Open-Source-Module eingepflegt werden. Der Obsoleszenzbeauftragte veranlasst dann die Behebung eventuell auftretender Fehler nach den zuvor festgelegten Schemata.

Und wie sieht eine SBOM genau aus und wie kann sie erstellt werden? »Dazu gibt es Tools, die bereits sehr gut unterstützen«, antwortet Steinleitner. Dazu zählen zum Beispiel SPDX, CycloneDX und SWID, womit sich eine SBOM gut aufbauen lässt.

In einer SBOM sollten folgende Dinge festgehalten werden: Source-Code, Libraries, Scripts, externe Applikationen, Container und Frameworks. Wenn diese Elemente in einer Standard-Vorlage – möglichst maschinenlesbar – vorliegen, ist schon viel gewonnen. Für jedes Stück Software müssen außerdem die Abhängigkeiten ermittelt werden, um sie in dieser Formatvorlage abbilden zu können. Alles muss immer auf dem aktuellen Stand gehalten und in Hinblick auf die Abhängigkeiten neu generiert werden. »Wer das sorgfältig pflegt, hat immer den aktuellen Überblick, um bei Fehlern schnell reagieren zu können.«

Auf diese Weise gibt die SBOM Auskunft über die einzelnen Module, wo sie herkommen und wo sie sich überall finden. Außerdem müssen die Ressourcen für Änderungen und Anpassungen sowie die Dokumentationen für Test und Qualifizierung vorgehalten werden.

In einer internen Design-Guideline wird festgehalten, welche Software benötigt wird, welche Quellen erlaubt sind etc. Das ist der proaktive Teil, man plant, was sich wie auswirkt. Darüber hinaus muss bekannt sein, wer die Software wartet und pflegt. Für die zugekauften Module muss die Vertragsseite mit den jeweiligen Lieferanten abgesichert sein. Außerdem muss für die Unterstützung der Open-Source-Communities gesorgt werden. »Da können großzügige Unterstützungsbeträge für die Community pro Jahr ein gut angelegtes Geld sein und sich sehr schnell wieder rechnen«, ist sich Steinleitner sicher.

Wie lebenswichtig das Problem ist, zeigt ein Blick in die USA: Im Mai 2021 wurde vom Weißen Haus eine Durchführungsverordnung erlassen, nach der SBOMs verpflichtend sind für alle Software-Anbieter, die an Regierungsbehörden liefern.
»Bei uns scheint die Awareness bezüglich der Software-Obsoleszenz allerdings noch wenig ausgeprägt zu sein«, so beobachtet Steinleitner. »In den Unternehmen fehlen oft die Organisationen oder Obsoleszenzbeauftragte, die SBOMs sinnvoll umsetzen können.« Dabei würde ein Blick über den Atlantik schon viel bringen: »Da ließe sich einiges lernen und auch vieles übernehmen. Aber anscheinend machen das hierzulande bisher nur wenige.«