Cyberresilienz in der „Software“-Lieferkette

Kaum eine Woche vergeht, in der nicht eine schwerwiegende Sicherheitslücke in weitverbreiteten Softwareprodukten bekannt wird. Und oft lassen Exploits zur Ausnutzung dieser Sicherheitslücken nicht lange auf sich warten. Wer an dieser Stelle mahnend den Zeigefinger hebt und von der Log4j-Lücke auf das ach so unsichere Java schließt, muss sich darüber im Klaren sein, dass nahezu jede Programmiersprache beziehungsweise jedes Paketökosystem schon einmal kompromittiert wurde. Und dabei geht es nicht nur um Sicherheitslücken, die unbeabsichtigt in die Codebasis gelangen.

Dies ist umso kritischer zu betrachten, als Softwarekomponenten immer Teil einer Liefer- oder Verwertungskette sind. Das heißt leider auch, dass eine Schwachstelle in irgendeiner Komponente entlang dieser Kette die Endanwendung verwundbar machen kann. Im Fall von Log4j waren es Anwendungen und Dienste, die Log4j als Logging-Backend genutzt haben. Setzte ein Entwickler in seinen eigenen Programmen Log4j ein, waren diese auch betroffen. Undurchsichtiger wird es aber, wenn zum Beispiel die Abhängigkeit einer Abhängigkeit von einer Bibliothek, die man nutzt, Log4j hinter den Kulissen einsetzt. Noch weniger transparent wird es bei der Nutzung von Cloud-Diensten. Wenn ein Programmierer eine Cloud-API nutzt, die intern Log4j für das Logging verwendet, besteht die Gefahr der Kompromittierung der eigenen Anwendung – und das „nur“, weil eine verwundbare Cloud-API eingesetzt wurde.