Julian Rausch Mit fortschreitender Digitalisierung gewinnt die Software Supply Chain für Unternehmen in der Softwareentwicklung immer mehr an Relevanz. Nicht nur die Verbesserung von Arbeitsabläufen, die Steigerung von Effizienz, die Erhöhung von Transparenz und das erfolgreiche Integrieren agiler Arbeitsmethoden sind dabei Resultat einer optimierten Software Supply Chain, sondern auch die Minderung von möglichen Sicherheitsrisiken durch externe Schadsoftware oder fehlerhaften Code. Dies bringt besondere Relevanz für regulierte Branchen mit sich, die durch verschiedene Regulatoriken dazu verpflichtet sind, Risiken und Cyberbedrohungen zu minimieren. Dies lässt sich oft effektiv mithilfe von automatisierten Tools lösen. Daher ist es mittlerweile unerlässlich die Bedeutung und Funktionsweise der Software Supply Chain zu verstehen und angemessene Sicherheitsmaßnahmen zu integrieren.
Welche Regulatorien gibt es?
Der Cyber Resilience Act (kurz CRA) soll zukünftig Sicherheitsstandards festlegen, denen digitale Produkte innerhalb der EU unabhängig von der Unternehmensgröße unterliegen. Diese sehen unter anderem vor, dass Produkte keine bekannten Schwachstellen beinhalten dürfen.
Die Kritische Infrastruktur (kurz KRITIS) bezeichnet Organisationen, die von hoher Bedeutung für das staatliche Gemeinwesen sind. Durch die EU-Richtlinie NIS2 gilt für KRITIS unter anderem, dass im Zuge des Risiko-Managements Supply Chains und ihre Bestandteile betrachtet werden müssen.
Auch für Banken und Versicherungen gilt, dass sie im Rahmen der bankenaufsichtlichen Anforderungen an die IT (kurz BAIT) oder der versicherungsaufsichtlichen Anforderungen an die IT (kurz VAIT) genutzte IT-Komponenten regelmäßig auf ihre Schwachstellen prüfen müssen.
Zusammenfassend ist es daher notwendig, die enthaltenen Bestandteile eines digitalen Produktes zu kennen, um diese untersuchen zu können, mögliche Sicherheitsrisiken zu identifizieren und zu beheben.
Was ist die Software Supply Chain?
Stellen wir uns beispielhaft eine Lieferkette für Schokolade vor. Am Anfang stehen die Zutaten Kakaobohnen, Zucker, Milchpulver und Vanille. Diese beziehen wir von verschiedenen Zulieferern, um sie anschließend in unserer Fabrik zu hochwertiger Schokolade zu verarbeitet. Unsere Maschinen werden von dafür zuständigen Technikern geprüft, anschließend wird die fertiggestellte Schokolade von Schokoladenverköstigenden geprüft.
Wie sieht das jetzt im Umfeld der Softwareentwicklung aus?
Analog zur Schokolade gibt es hochwertige digitale Produkte, die mit gängigen Programmiersprachen und Werkzeugen „gefertigt“ werden. Um Zeit einzusparen und Marktstandards einzubeziehen, werden diese „Zutaten“, also Bibliotheken oder Module, in die Produkte eingebaut. So gibt es für unterschiedliche Programmiersprachen zentrale Bezugsplattformen für diese Inhalte, ähnlich zu einer Rohstoffbörse.
Somit nutzen viele Softwareentwickler diese fertigen Inhaltsstoffe und veredeln sie mit ihrer Businesslogik zu hochwertigen digitalen Produkten, die erst nach der erfolgreichen Abnahme durch die Qualitätssicherung den Weg zum Kunden oder einem zentralen Kundenmarktplatz finden.
Wo liegen die Risiken und Möglichkeiten der Software Supply Chain?
Betrachtet man die verschiedenen Phasen der Lieferkette der Schokoladenherstellung, gibt es verschiedene Risiken, die abgedeckt und kontrolliert werden müssen. Ebenso gibt es in der Software Supply Chain der Softwareentwicklung verschiedene Phasen, in denen Tools unterstützen können.
Zutaten prüfen mit Software Composition Analysis
Es soll sichergestellt werden, dass die genutzten Zutaten auch von guter Qualität sind – z.B. sollte keine der Bohnen verdorben sein – außerdem sollten die Zutaten keine ungewünschten Nebenprodukte enthalten. Die Schokoladenverpackung muss unter anderem den Hinweis „Kann Spuren von Nüssen enthalten“ tragen, wenn nicht sicher festgestellt werden kann, dass die Zutaten frei von Nüssen sind. Dazu werden die Zutaten kontrolliert, bevor sie zu Schokolade verarbeitet werden und Inhaltsstoffe und mögliche Nebenprodukte werden gelistet. Hierfür gibt es bereits Prüfmechanismen, bevor die Zutaten dem nächsten Schritt der Supply Chain zugeführt werden. Dieses Verfahren lässt sich mit shift-left beschreiben.
In der Analogie müssen wir möglichst früh im Entwicklungsprozess unsere Softwarekomponenten auf mögliche Sicherheitslücken testen und die enthaltenen Artefakte auflisten. Wie in der Schokoladenindustrie möchten die Nutzer die digitalen Produkte genießen und keine negativen Auswirkungen durch unbekannte Inhaltsstoffe erleiden. Dazu kann eine Software Bill of Materials (kurz SBOM) genutzt werden, die alle verwendeten Softwarekomponenten auflistet, die auch die Nebenprodukte oder transitive Abhängigkeiten enthält, wie z. B. die Bemerkung “Kann Spuren von Nüssen enthalten”. Diese SBOM lässt sich zur Dokumentation nutzen und um Komponenten, die Sicherheitsprobleme verursachen, zu identifizieren. Hier kommen Software Composition Analysis (kurz SCA) Tools, wie beispielsweise Sonatype, JFrog, Snyk oder GitLab zum Einsatz. Sie erkennen und prüfen die verwendeten Softwarekomponenten auf bestehende Sicherheitslücken und können auch die benötigte SBOM generieren. Wird das SCA-Tool in die Entwicklungspipeline integriert, lassen sich Sicherheitslücken automatisiert diagnostizieren und behandeln. Der Shift-Left Ansatz hilft somit, Probleme früh zu erkennen, sodass es im Anschluss nicht zu unnötigen Feedbackloops kommt, welche die Entwicklung verzögern und unnötige Kosten verursachen.
Maschinen warten mit SAST
Während der Produktion der Schokolade sollten alle Maschinen ordnungsgemäß funktionieren, um sicherzustellen, dass keine Verunreinigungen oder Fehlnoten in die Schokolade gelangen.
Analog dazu soll auch der Programmcode überprüft und sichergestellt werden, sodass keine Sicherheitsrisiken in die Software implementiert werden. Hier kommt Static Application Security Testing (kurz SAST) zum Einsatz. Beispiele für Tools in diesem Zusammenhang sind SonarQube, Snyk, Mend SAST und die GitLab-Lösung, die unter anderem das Open-Source-Tool von Grype verwendet. Ein SAST-Tool prüft dabei den Code auf mögliche Sicherheitslücken, die bereits durch fehlerhafte Implementation zu beispielsweise Cross-Side-Scripting (kurz CSS) oder SQL-Injection Vulnerabilities führen können. Auch das SAST-Tool lässt sich in die Software Supply Chain und den Entwicklungsprozess integrieren, um die Entwickelnden frühzeitig auf Probleme hinzuweisen, sodass diese gar nicht erst in den produktiven Code gelangen.
Schokolade prüfen mit DAST
Am Ende der Herstellung der Schokolade soll diese noch einmal verköstigt werden, um sicherzustellen, dass während der Herstellung alles nach Plan funktioniert hat.
Ebenso sollten Softwareprodukte vor dem Deployment in Produktion auf mögliche Sicherheitsprobleme, die während des Betriebs bestehen, getestet werden. Hierzu lassen sich Dynamic Application Security Testing (kurz DAST) Tools nutzen, welche die laufende Applikation auf Sicherheitslücken testet. Auch hier gibt es bereits Produkte auf dem Markt, wie AppScan von HCLSoftware, WebInspect von Fortify oder GitLab. Der Unterschied zu SAST liegt darin, dass eine laufende Anwendung durch bestimmte API-Anfragen oder Eingaben getestet und nicht nur der statische Code analysiert wird. Diese DAST-Tools stehen somit in einer späteren Phase der Software Supply Chain und können unter anderem auch Probleme in der Konfiguration von Webservern oder Sicherheitslücken, die durch das Zusammenspiel verschiedener Komponenten entstehen, identifizieren.
Fazit
Sollen Applikationen im Rahmen der genannten regulatorischen Vorgaben bestmöglich abgesichert werden, empfiehlt es sich, jede Phase der Software Supply Chain genau zu betrachten. Von den zugelieferten Softwarepaketen über die Codebasis bis hin zur Endanwendung kann in allen Phasen mithilfe automatisierter Tools getestet und die notwendigen Sicherheitsrichtlinien in den Entwicklungsprozess integriert werden. Dazu können SCA-, SAST- und DAST-Tools genutzt werden. Hierzu gibt es bereits einige Tools auf dem Markt, die unter anderem Hilfestellungen beim Lösen dieser Probleme bieten und sich gut in verschiedene Entwicklungsumgebungen integrieren lassen.
Weiterführende Links
