Container-Sicherheit über den gesamten SDLC hinweg

Container entwickeln sich zunehmend zur Standardeinheit von Software. Das Container-Image, das in der OCI Image Specification technisch definiert ist, ist ein zentraler Bestandteil moderner Tools – von Docker und Kubernetes bis hin zu Plattformen wie AWS Fargate und Google Cloud Run. Was bedeutet das für die Anwendungssicherheit?

Wo Container-Images zum Einsatz kommen

Eine interessante Eigenschaft von Container-Images ist, dass sie den Softwareentwicklungslebenszyklus (SDLC) durchlaufen.

• Entwickler erstellen Images lokal. Sie bieten eine praktische Möglichkeit, Software einfach – manchmal zu einfach – zu verteilen.

• Images werden auch als Teil von Continuous-Integration- und Continuous-Delivery-Pipelines erstellt. An das Image lassen sich Metadaten zur Anwendung anhängen, um die Verwaltung von Assets zu verbessern.

• Images werden in öffentliche und private Registries hochgeladen, von wo aus sie zur Bereitstellung weitergegeben werden können.

• Schließlich werden Images in Clustern bereitgestellt – von Entwicklung und Test bis hin zur Produktion. Diese werden zunehmend mit Kubernetes oder ähnlichen Tools verwaltet.

Jede dieser Phasen bietet die Möglichkeit, das Image auf Sicherheitslücken zu prüfen. Doch an welcher Stelle ist das am sinnvollsten?

Wo sollten wir unsere Images testen?

Wenn es darum geht, unsere Container-Images zu schützen, liegt der Gedanke nahe, sie nur an einer Stelle im SDLC zu testen. Wenn sich beispielsweise nur sichere Images in Ihrer Registry befinden, sind Sie dann geschützt? Die Realität ist komplexer und bringt in der Regel Kompromisse mit sich.

Je näher an der Produktion Sie testen, desto sicherer können Sie die Risiken Ihrer laufenden Anwendungen einschätzen. Wenn Sie nicht als Softwareanbieter Tools für andere entwickeln, möchten Sie wahrscheinlich vor allem die Anwendungen schützen, die Sie gerade in der Produktion betreiben. Tests spät im Zyklus sind auch dann hilfreich, wenn eine neue Sicherheitslücke in einer von Ihnen verwendeten Abhängigkeit bekannt wird. So können Sie schnell feststellen, welche Produktionsanwendung betroffen ist, und mit der gebotenen Dringlichkeit handeln.

Wenn Sie jedoch nur am Ende des SSDLC testen, bedeutet das wahrscheinlich längere Feedbackzyklen für Entwickler. Der Entwickler, der ein Image ausgewählt oder geändert hat, hat darauf aufgebaut und sich inzwischen anderen Aufgaben zugewandt. Die erforderlichen Änderungen zur Behebung der Sicherheitslücke werden dadurch störend und teuer. Denken Sie daran: Es geht nicht nur darum, zu wissen, welche Sicherheitslücken vorhanden sein könnten (was wichtig ist), sondern sie zu beheben. Lokale Tests ermöglichen die schnellsten Feedbackzyklen, setzen aber voraus, dass jeder Entwickler daran denkt, jedes Mal einen Scan durchzuführen – eine kaum umfassende oder realistische Lösung.

Bevor Sie zu dem Schluss kommen, dass die Pipeline also der richtige Ort für Tests ist, sollten Sie auch die Implementierungskosten berücksichtigen. Möglicherweise haben Sie ein oder zwei zentral verwaltete Container-Registries, über die Sie alle erstellten Images prüfen können. Wahrscheinlich verfügen Sie jedoch über deutlich mehr Continuous-Integration-Pipelines. Je nach Automatisierungsgrad und Zuständigkeit für die verschiedenen Tools in Ihrem Unternehmen kann es sinnvoller sein, zunächst an der einen oder anderen Stelle anzusetzen.

Außerdem steht uns in den verschiedenen Phasen des SDLC unterschiedlich viel Kontext zur Verfügung. Bei lokalen Tests oder Tests in CI haben wir wahrscheinlich Zugriff auf den Quellcode und die Versionskontrollinformationen. Dadurch lassen sich bestimmte Arten von Problemen möglicherweise leichter erkennen, etwa Probleme durch den verwendeten Compiler oder nicht signierte Commits eines Angreifers. Auch lässt sich so besser nachvollziehen, wie eine Bibliothek eingebunden wurde. Bei Tests in der Produktion wissen wir dagegen genau, welche Images wo verwendet werden und wie sie konfiguriert sind. Das kann uns helfen, die entdeckten Probleme nach Priorität zu ordnen.

Fazit

Tatsächlich erfüllt das Testen an nur einer Stelle möglicherweise die Anforderungen einer einzelnen Funktion (Entwicklung, Betrieb oder Sicherheit), deckt aber wahrscheinlich nicht das übergeordnete Unternehmensziel ab, Sicherheitslücken so schnell wie möglich zu finden und zu beheben. Zusammengefasst:

Tests auf Sicherheitslücken in verschiedenen Phasen des SDLC

Mit welcher Option Sie beginnen, hängt von den Gegebenheiten in Ihrem Unternehmen ab. Das Ziel sollte jedoch sein, containerbasierte Anwendungen während des gesamten SDLC gründlich zu testen. Sich auf ein einzelnes Gate zu verlassen, ist zu vereinfachend und führt wahrscheinlich zu Reibungsverlusten – entweder zwischen Entwicklungs-, Betriebs- und Sicherheitsteams oder bei der Geschwindigkeit, mit der Sie Anwendungen bereitstellen.