Schwachstellen in Open Source Code können ernsthafte Auswirkungen haben. Das lässt sich von Security Teams, die im Dezember 2021 die Auswirkungen von Log4j bearbeitet haben, unabhängig bestätigen. Software Supply Chains sind über die Jahre komplexer und offener für Angriffe geworden. Code von Dritten macht einen beachtlichen Teil heutiger Anwendungen aus. Bei Webseiten wird von rund 70% Fremdcode ausgegangen, der mittels Packagemanager als Abhängigkeit zur Applikation gepackt wird. Aber auch viele andere Anwendungen basieren auf Open-Source-Komponenten (z.B. Spring Framework oder freie Bibliotheken wie OpenSSL).

Weiters werden mit einer agilen Arbeitsweise von Build-Systemen täglich unzählige Versionen von Anwendungen gebaut und als Container Image zur Verfügung gestellt. Nicht jede Version ist dabei für die Verwendung außerhalb von Testsystemen gedacht. Zudem basieren diese Images meist auf offenen Base Images, beispielsweise von Docker Hub, die wiederrum Code von Dritten beinhalten. Als Laufzeitumgebung hat sich Kubernetes etabliert, auf denen diese containerisierten Anwendungen zur Ausführung kommen. Kubernetes wiederrum bringt weitere Abhängigkeiten zu Dritten mit sich. Es wird damit zunehmend schwieriger, Überblick über Softwareversionen, deren Abhängigkeiten sowie potenzielle Schwachstellen zu behalten.

Ziel des Vortrags ist es, den aktuellen Stand zu Cloud-Native Supply Chain Security zu beleuchten:

• Was sind die größten Supply Chain Security Probleme?
• Was sind SBOMs und wie können sie helfen, Schwachstellen in Open Source Komponenten zu managen?
• Welche Optionen gibt es, um die Authentizität und Integrität von Build-Artefakten zu gewährleisten?
• Welche Prozesse können helfen, nur dafür vorgesehene Artefakte auf Produktionssystemen ausführbar zu machen?