Supply-Chain-Security: Container bauen, Schwachstellen entdecken

Containerisierte Anwendungen bringen oft lange und intransparente Abhängigkeitsketten mit sich. Einige Regeln helfen, versteckte Schwachstellen zu entdecken.

Lesezeit: 21 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 2 Beiträge
Von
  • Stefan Walluhn
Inhaltsverzeichnis
Mehr zu Supply-Chain-Security

Auf der Website von Docker findet sich ein Satz, der übersetzt wie folgt lautet und die Komponenten eines Containers beschreibt: "Ein Docker-Container-Image ist ein leichtgewichtiges, eigenständiges, ausführbares Softwarepaket, das alles enthält, was nötig ist, um eine Anwendung auszuführen: Code, Laufzeitumgebung, Systemtools, Systembibliotheken und Einstellungen."

Diese Aufzählung zeigt genau, wo aus Sicht der Supply-Chain-Security die Probleme liegen. Denn Container werden in der Regel in den Entwicklungsabteilungen gebaut; und damit geraten Teile des Softwarestacks in deren Verantwortungsbereich, die traditionell bei den Betreibern der Server lagen, mit all deren direkten und indirekten Abhängigkeiten. Dieser Übergang von Verantwortung für große Teile der Supply Chain vom Administrator eines Servers auf den Anbieter eines Containers ist vielen noch nicht wirklich bewusst.

Zu den Komponenten eines Containers gehört naheliegenderweise der Code der eigentlichen Anwendung; er wird von Entwicklern gepflegt. Im besten Fall beheben sie Sicherheitsprobleme durch bereitgestellte Security-Updates. Auch die Versionspflege der durch die Anwendung eingebundenen Bibliotheken wie RubyGems oder Python Wheels gehören traditionell in den Verantwortungsbereich der Developer.