Ein aktueller Beitrag von heute auf golem.de besagt, dass rund 38 Prozent aller Anwendungen, die das von der Apache Software Foundation entwickelte Logging-Framework Log4j verwenden, noch auf eine veraltete Version mit bekannten Sicherheitslücken setzen. Als Hauptgrund wird angeführt, dass durch diverse Abhängigkeiten von externen Bibliotheken ein Release-Update nicht ohne weiteres möglich ist.
Was ist von einer solchen Aussage zu halten?
Man könnte es sich leicht machen, und alle Nutzer dieser „Problembibliotheken“ als inkompetent denunzieren. Das würde sicherlich den einen oder anderen Klick bringen. Dies wäre nicht nur sehr arrogant, sondern wird dem Problem auch nicht wirklich gerecht.
Wie würden wir in einem solchen Fall agieren?
a) Wenn das Kind im Brunnen liegt
- Es ist zu prüfen, warum ein Update der Bibliothek nicht möglich ist.
- Sollte sich herausstellen, dass es tatsächlich Abhängigkeiten gibt, die ein Update unmöglich machen, dann bleibt nix anderes übrig als ein aufrichtiger Blick in den Spiegel, der einem am Ende eine Neuentwicklung / Migration reflektiert.
- Wenn ich eine (Java-) Lösung habe, die aufgrund einer Abhängigkeit nicht aufwärtskompatibel ist, dann wird auf kurz oder lang nicht nur diese eine Bibliothek Probleme bereite. Die Lösung wird degenerieren und mittelfristig auch updates der drunterliegenden Infrastruktur (OS, VM, Container) verhindern. Es ist also nur eine Frage der Zeit…
b) Damit das Kind es schwer hat, in den Brunnen zu fallen:
- Es sind oftmals nicht die 1 oder 2 Kernbibliotheken, die Probleme verursachen, sondern die vielen vielen Helferlein, die sich doch so schnell via pom in das Projekt ziehen lassen. Und zack, wieder ein Problem weniger, weil irgendjemand meine Sorge mal in Form einer Bibliothek gelöst und publiziert hat. Schnell gegoogelt, und 100 oder 1000 andere Entwickler auf StackOverflow haben es genauso gemacht, weshalb der Lösung mit vielen Sternchen und likes bedacht ist.
- Es ist eine philosophische Frage, ob ich – puristisch – möglichst viel Code selber schreibe, oder möglichst viele externe Libs „zusammenklicke“. Bei der Nutzung externer Libs sollte ich immer Klarheit darüber haben, welche indirekten Abhängigkeiten ich mir einfange.
c) Manchmal kann auch ein wenig weniger Stack sinnvoll sein
- OnPrem, IaaS, PaaS: Alles kalter Kaffee, das macht man doch nicht mehr.
- Cloud Native, Serverless. Alles wunderbare Trends. Ich muss mich mit lästigen Infrastrukturthemen einfach nicht mehr auseinandersetzen. Blöd nur, wenn der Anbieter bestimmte Vorgaben macht bzgl. der einzusetzenden Releases. Insbesondere dann, wenn diese von einem Exploit betroffen sind. Dann liegt es gar nicht mehr in meiner Hand, wie und wann ich migrieren kann.
- Ähnlich wie beim Sourcecode sollte ich nicht stets alle Verantwortung für delegieren. Unter bestimmten Situationen ist es sinnvoll, wieder mehr in Richtung Selbstbestimmung bzgl. der Infrastruktur zu tendieren, auch wenn dies mit ein wenig Mehraufwand seitens des Entwicklerteams und der Infrastruktur einhergeht.
Sie benötigen oder planen eine neue Anwendung?
