Warum Sicherheit in der Software-Lieferkette 2024 unverzichtbar ist
Cyberangriffe wie der Codecov-Lieferkettenangriff, der SUNBURST Cyberangriff und die Kompromittierung von Top.gg, einem Anbieter von Discord-Bots, zählen zu den verheerendsten Hackerangriffen der jüngsten Geschichte, mit Tausenden von infizierten Geräten weltweit. Die immensen Auswirkungen dieser Angriffe sind vor allem darauf zurückzuführen, dass es sich um sogenannte Software Supply Chain Angriffe handelt: Angriffe auf die Software Lieferkette. Doch was genau ist passiert?
Beginnen wir mit dem Codecov-Lieferkettenangriff, der im April 2021 aufgedeckt wurde. Dabei wurde ein internes Skript der Software Codecov, die Entwickler zur Messung der Testabdeckung ihrer Softwareprojekte nutzen, von Angreifern manipuliert. Diese Modifikation erlaubte es den Angreifern, sensible Daten wie Sicherheits-Token, Passwörter und Schlüssel von den Nutzern des Tools zu sammeln und unbemerkt an einen externen Server zu übertragen. Die Tragweite dieses Angriffs war enorm, da potenziell Tausende von Codecov-Kunden, die dieses Tool in ihre Entwicklungsprozesse integriert hatten, betroffen waren. Die kompromittierten Informationen stellten ein signifikantes Sicherheitsrisiko für die betroffenen Organisationen dar.
Der SUNBURST Cyberangriff wurde Ende 2020 entdeckt und zielte auf SolarWinds, einen Anbieter von IT-Management-Software ab. Hackern ist es aufgrund eines kompromittierten FTP-Servers (mit dem Passwort: "solarwinds123") gelungen, Schadcode in ein Software-Update der von SolarWinds selbst entwickelten Software Orion einzuschleusen. Die Auswirkungen waren immens: Mehrere Tausend Kunden von SolarWinds, einschließlich wichtiger US-Behörden und zahlreicher Fortune-500-Unternehmen wurden kompromittiert.
Ein sehr aktuelles Beispiel ist der Angriff auf Top.gg, eine beliebte Plattform für Discord-Bots, die im März 2024 Ziel eines ausgeklügelten Angriffs wurde. Hier manipulierten Hacker GitHub-Accounts, um die Software-Abhängigkeiten von Top.gg zu kompromittieren. Dieser Angriff führte zur unbefugten Übernahme von Nutzerkonten und potenziell zum Diebstahl sensibler Daten.
All diese Angriffe verdeutlichen die enormen Auswirkungen, die mit einem Software-Lieferkettenangriff einhergehen.
Was ist die Software Lieferkette?
Die Software Supply Chain bezeichnet den gesamten Prozess der Entwicklung, Veröffentlichung und Wartung von Software. Er beginnt mit der initialen Planung der Software, über die Entwicklung, das Testen, das Packaging und die Auslieferung, bis hin zur Bereitstellung und den regelmäßigen Updates bei den Endnutzern. Sie umfasst somit den gesamten SDLC (Software Development Lifecycle) eines Produkts. Jeder Schritt in dessen Erstellung birgt potenzielle Risiken für die Einführung von Sicherheitslücken oder die Ausnutzung bestehender Schwachstellen, wodurch die Integrität und Sicherheit der Software gefährdet werden kann. Angesichts der komplexen und oft verteilten Natur moderner Softwareentwicklung, einschließlich der Verwendung von Open-Source-Komponenten und Third-Party-Tools, ist die Sicherung der Supply Chain entscheidend, um das Risiko von Cyberangriffen zu minimieren und die Vertrauenswürdigkeit der Software zu gewährleisten.
Software Supply Chain nach SLSA
Quelle: slsa.dev
Die Software-Lieferkette besteht aus sechs Hauptkomponenten: dem Entwickler (Producer), dem Quellcode-Repository (Source), dem Bauprozess (Build), den Abhängigkeiten (Dependencies), der Auslieferung (Package) und zuletzt dem Betrieb beim Kunden (Consumer).
Top Sicherheitsrisiken in der Software-Lieferkette
Die Bedrohungslandschaft in der Software Supply Chain ist komplex und ständig im Wandel. Angreifer nutzen verschiedene Schwachstellen und Angriffsvektoren, um Software-Lieferketten zu kompromittieren. Google stellt an der Zahl 12 mögliche Schwachstellen einer Software Supply Chain vor.
Software Supply Chain Attack Vectors
Quelle: https://cloud.google.com/software-supply-chain-security/docs/attack-vectors?hl=de
Exemplarisch lassen sich etwa folgende drei konkrete Angriffsvektoren ableiten:
Schadcode im Namen des Entwicklers: Schadcode könnte im Namen des Entwicklers commited werden und ohne Code-Review in das Endprodukt gelangen.
Kompromittierung der Build-Plattform: Angreifer könnten Plattformen wie Jenkins oder GitHub-Actions kompromittieren und dort unbemerkt, während des Build-Prozesses, Schadcode einschleusen.
Kompromittierung von Bibliotheken: Eine weitere Gefahr besteht in der Kompromittierung einer verwendeten Open-Source-Bibliothek.
Ablauf eines Software Supply Chain Angriffs
Der Ablauf eines Supply Chain Angriffs kann in verschiedene Phasen unterteilt werden, die zeigen, wie ein Angreifer schrittweise vorgeht, um die Endziele zu kompromittieren.
1. Cyberangriff auf den Lieferanten
Diese Phase beginnt mit einem gezielten Angriff auf den Lieferanten. Der Angreifer nutzt dabei oft Schwachstellen in der IT-Infrastruktur oder menschliche Fehler aus, um in das Netzwerk des Lieferanten einzudringen. Methoden wie Phishing, Social Engineering oder das Ausnutzen von Software-Schwachstellen werden eingesetzt, um Zugang zu Systemen oder sensiblen Informationen zu erlangen. Ziel ist es, einen Einstiegspunkt in die Lieferkette zu finden, der eine weitere Ausbreitung und Kontrolle ermöglicht.
2. Kompromittierung der Software-Lieferkette des Lieferanten
Nach dem erfolgreichen Eindringen in das Netzwerk des Lieferanten konzentriert sich der Angreifer darauf, die Software-Lieferkette zu kompromittieren. Dies kann durch die Manipulation von Software-Code, das Einfügen von Malware in Softwarepakete oder die Veränderung von Build-Prozessen erfolgen. Der Angreifer kann auch versuchen, legitime Software-Updates oder Sicherheitspatches zu manipulieren, um so eine breitere Verteilung des schädlichen Codes zu erreichen.
3. Auslieferung eines kompromittierten Produktes
In dieser Phase wird das kompromittierte Produkt an die Kunden des Lieferanten, also die eigentlichen Zielunternehmen, ausgeliefert. Da das Produkt oder Update von einem vertrauenswürdigen Lieferanten stammt, wird es oft ohne ausreichende Prüfung in den Systemen der Zielunternehmen installiert. Die schädliche Software kann sich so unbemerkt in den Systemen der Zielunternehmen ausbreiten und dort Schaden anrichten.
4. Kompromittieren des Ziels
Sobald die kompromittierte Software im Zielnetzwerk aktiv ist, beginnt die letzte Phase des Angriffs. Der Angreifer versucht nun Zugriff auf sensible Daten zu erhalten oder das Netzwerk für zukünftige Angriffe nutzen. Die Ziele können vielfältig sein, von Datendiebstahl und Spionage bis hin zur Sabotage kritischer Infrastrukturen.
Ein Angriff auf die Lieferkette ist somit immer eine Kombination aus mindestens zwei Angriffen: Der erste Angriff richtet sich gegen einen Lieferanten, der Zweite gegen das eigentliche Ziel
Der Ablauf eines Supply Chain Angriffs zeigt, wie Angreifer durch die Ausnutzung von Vertrauensbeziehungen zwischen Unternehmen und ihren Lieferanten komplexe und schwer zu erkennende Angriffsvektoren schaffen können. Es ist daher entscheidend, dass Unternehmen nicht nur ihre eigenen Sicherheitsmaßnahmen stärken, sondern auch die Sicherheitspraktiken ihrer Lieferanten genau prüfen und bewerten.
NIST SSDF und SLSA entschlüsselt: Standards für eine sichere Software-Lieferkette
Im Kontext der wachsenden Bedeutung der Sicherheit in der Software-Lieferkette haben Organisationen wie NIST (National Institute of Standards and Technology) mit dem Secure Software Development Framework (SSDF) und SLSA (Supply-chain Levels for Software Artifacts) Rahmenwerke und Standards entwickelt, um die Risiken von Software-Schwachstellen zu mindern und die Entwicklung sicherer Software zu fördern.
Das SSDF und SLSA konzentrieren sich zwar beide auf die Sicherheit der Software-Lieferkette, aber nehmen unterschiedliche Perspektiven ein. Während das SSDF einen allgemeinen Ansatz für sichere Softwareentwicklungspraktiken über den gesamten Entwicklungszyklus bietet, konzentriert sich SLSA hingegen spezifischer auf die Sicherung der Software-Lieferkette durch Definition von Sicherheitsniveaus für die erstellten Softwareartefakte. Beide Frameworks ergänzen einander und können zusammen verwendet werden, um ein umfassendes Sicherheitsniveau zu erreichen.
Das Wichtigste aus der NIST Special Publication 800–218 (Secure Software Development Framework (SSDF))
Der NIST Special Publication 800-218, bekannt als Secure Software Development Framework (SSDF), bietet einen Satz von hochrangigen Praktiken für die sichere Softwareentwicklung, die in jeden Softwareentwicklungslebenszyklus (SDLC) integriert werden können. Das SSDF ist in vier Hauptbereiche unterteilt: die Vorbereitung der Organisation, den Schutz der Software, die Erstellung gut gesicherter neuer Software und das Reagieren auf Schwachstellen.
Das SSDF empfiehlt, Sicherheit in den gesamten Software Development Lifecycle zu integrieren. Eine sicherheitsorientierte Kultur im Entwicklungsteam ist notwendig, um die Berücksichtigung von Sicherheitsaspekten in allen Phasen des Entwicklungsprozesses zu gewährleisten. Unsichere Programmierpraktiken lassen sich später von Angreifern leicht ausnutzen. Deshalb ist es entscheidend, dass Entwickler in Bezug auf die Codierung sicherer Software ausreichend geschult sind.
Zusätzlich empfiehlt das SSDF die Einführung einer formellen Richtlinie für die sichere Softwareentwicklung. Diese Richtlinie soll die Verfahren und Praktiken festlegen, die eine Organisation für die Entwicklung sicherer Software verfolgt. Sie sollte Anweisungen für Personen, Technologien und Prozesse, die in jeder Phase des Entwicklungszyklus zum Einsatz kommen, enthalten. Solch eine Richtlinie ist nicht nur eine Empfehlung zur Steigerung der Softwareintegrität, sondern ist häufig auch eine verpflichtende Compliance-Anforderung (ISO 27001, SOC 2).
Außerdem unterstreicht das Secure Software Development Framework die Bedeutung der Überwachung und Sicherstellung, dass Drittanbieter, von denen Komponenten bezogen werden, denselben Sicherheitsstandards folgen wie die eigene Organisation. Es wird empfohlen, alle Drittanbieterkomponenten zu überwachen und sicherzustellen, dass diese Anbieter über die Sicherheitsanforderungen informiert sind und diesen entsprechen, um potenzielle Sicherheitslücken zu vermeiden. Konkret erfordert das SSDF, dass Dienstleiter Provenance-Informationen (Informationen über die Herkunft und die Art und Weise, wie eine Komponente gebaut wurde) und Mechanismen zur Integritätssicherung implementieren. Dies kann sich in der Praxis jedoch als große Herausforderung herausstellen, da solche Praktiken bislang nicht sehr verbreitet sind.
Des Weiteren wird die Automatisierung von Schwachstellenscans gefordert sowie regelmäßige Sicherheitsüberprüfungen, um Bedrohungen kontinuierlich und systematisch zu erkennen.
Die NIST SSDF hebt hervor, wie wichtig es ist, die Integrität des Codes zu schützen, indem sichergestellt wird, dass der Code und alle seine Komponenten in gesicherten Quellcode-Repositories aufbewahrt werden, um Manipulationen zu verhindern. Es wird empfohlen, den Zugriff auf den Quellcode auf autorisierte Entwickler zu beschränken und Funktionen zur Sicherung des Anmeldeprozesses sowie zur Überwachung von Codeänderungen zu nutzen. Dies kann beispielsweise mit Git-Commit Signing umgesätzt werden. Automatisierung spielt auch hier eine Rolle, um den Zugriff und die Codeanalyse zu überwachen.
Insgesamt stellt das NIST SSDF umfangreiche Anforderungen an den gesamten Software-Entwicklungsprozess, um die Cybersicherheit der erstellten Software zu erhöhen. In der Praxis haben sich Konzepte wie DevSecOps für die agile Umsetzung solcher Anforderungen bewährt.
SLSA zusammengefasst
SLSA (Supply-chain Levels for Software Artifacts) ist ein Sicherheitsframework zur Gewährleistung der Integrität von Software-Lieferketten.
Ein fundamentalles Konzept in SLSA ist die sogenannte Provenanz: Metadaten, die einem Software-Artefakt anhängen und die beschreiben, wie das Artefakt erzeugt, welcher Quellcode verwendet, welche Platform genutzt, und welche externen Parameter eingesetzt wurden. Ein Beispiel hierfür ist die Dokumentation der Quellcode-Version und der verwendeten Compiler-Einstellungen für ein gebautes Softwarepaket. Durch solche Informationen lässt sich die Transparenz und Sicherheit der Software-Lieferkette stark erhöhen, da sie es ermöglichen, die Integrität und Authentizität der Software zu überprüfen. Besonders wichtige Pakete können sogar selbst nachgebaut werden, um sicherzustellen, dass die Software nicht während der Auslieferung manipuliert wurde. SLSA definiert vier Sicherheitsstufen, von einfachen Grundpraktiken bis hin zu fortgeschrittenen Schutzmechanismen. Jede Stufe baut auf den vorherigen auf und fügt strengere Sicherheitsanforderungen hinzu.
Level 0 (L0) bietet keine Sicherheitsgarantien. Es repräsentiert den Ausgangspunkt ohne spezifische Sicherheitsmaßnahmen.
Level 1 (L1) sorgt für die Existenz von Metadaten, die die Herkunft und den Bau des Softwarepakets dokumentieren. Es ermöglicht eine bessere Analyse und Nachvollziehbarkeit.
Level 2 (L2) nutzt gehostete Build-Plattformen, die signierte Herkunftsinformationen bereitstellen, um einfache Manipulationen und Angriffe zu verhindern.
Level 3 (L3) führt gehärtete Build-Prozesse ein, die stark gegen Manipulation und Insider-Bedrohungen geschützt sind, und bietet somit das höchste Sicherheitsniveau.
Unverzichtbare Werkzeuge und Technologien für die Software-Lieferkettensicherheit
Die Gewährleistung einer robusten Sicherheit entlang der gesamten Software-Lieferkette erfordert den Einsatz von Werkzeugen und Technologien, die eine effektive Absicherung gegen potenzielle Bedrohungen und Risiken ermöglichen. Der Großteil der von SLSA und NIST SSDF definierten Anforderungen lässt sich durch die hier vorgestellten Werkzeuge umsetzen.
Einsatz von SBOMs (Software Bill of Materials)
Eine SBOM ist eine detaillierte Aufstellung aller Komponenten einer Softwareanwendung sowie deren Abhängigkeiten. Sie bietet eine transparente und umfassende Übersicht über die verwendeten Softwarekomponenten, was Organisationen dabei unterstützt, potenzielle Sicherheitsrisiken oder Schwachstellen frühzeitig zu erkennen und zu beheben.
Die Vorteile von SBOMs liegen in ihrer Transparenz und Nachvollziehbarkeit, die es ermöglichen, Risiken besser zu managen und die Einhaltung gesetzlicher Vorschriften und branchenspezifischer Standards sicherzustellen. Durch die Kenntnis der Softwarekomponenten und ihrer Abhängigkeiten können Organisationen Risiken besser einschätzen und geeignete Maßnahmen zur Risikominderung ergreifen. SBOMs dienen auch als wichtige Kommunikationsgrundlage zwischen Entwicklern, Sicherheitsteams und Lieferanten, um eine effektive Zusammenarbeit bei der Identifizierung und Behebung von Sicherheitslücken in der Software-Lieferkette zu ermöglichen.
SBOMs werden automatisch von entsprechenden Tools generiert, die die Softwareentwicklung unterstützen. Entwickler können SBOMs nutzen, um sicherzustellen, dass nur vertrauenswürdige und sichere Komponenten verwendet werden. Die Integration von SBOMs in den Softwareentwicklungsprozess ist ein wesentlicher Schritt zur Verbesserung der Sicherheit der Software-Lieferkette, da sie die Transparenz und Nachvollziehbarkeit erhöht und Organisationen dabei unterstützt, Sicherheitsrisiken zu minimieren und die Integrität ihrer Softwareanwendungen zu gewährleisten.
Verwendung von Continous Integration / Continous Deployment (CI/CD) Pipelines
Eine CI/CD-Pipeline ist ein automatisierter Prozess zur kontinuierlichen Integration (CI) und kontinuierlichen Bereitstellung (CD) von Softwareänderungen. Sie automatisiert den Build-, Test- und Bereitstellungsprozess, um die Entwicklung und Auslieferung von Software effizienter und zuverlässiger zu gestalten.
Die Vorteile von CI/CD-Pipelines sind vielfältig. Zum einen beschleunigen sie den Entwicklungsprozess, da sie die manuellen Aufgaben reduzieren und den Code schneller und häufiger bereitstellen können. Durch die Automatisierung von Tests können Fehler frühzeitig erkannt und behoben werden, was die Qualität der Software verbessert und die Wahrscheinlichkeit von Fehlern in der Produktion verringert. Auch automatisierte Schwachstellenscans lassen sich in eine CI/CD Pipeline integrieren (OWASP DevSecOps Pipeline). Darüber hinaus fördern CI/CD-Pipelines die Zusammenarbeit im Entwicklungsteam, da sie eine konsistente und standardisierte Arbeitsweise ermöglichen und die Integration neuer Funktionen erleichtern.
Die Verwendung von CI/CD-Pipelines erfordert zunächst die Einrichtung einer Pipeline entsprechend den Anforderungen des Projekts. Dies umfasst die Definition der Schritte für den Build, Test und die Bereitstellung der Software sowie die Integration von Tools zur Überwachung und Fehlerbehebung. Entwickler können dann Änderungen am Code vornehmen und diese automatisch in die Pipeline einfügen, um sie zu testen, auf Sicherheitslücken zu scannen und bei erfolgreicher Überprüfung und in die Produktionsumgebung zu übertragen. Durch die kontinuierliche Integration und Bereitstellung werden Softwareänderungen schnell und sicher in Betrieb genommen, was die Agilität und Reaktionsfähigkeit des Entwicklungsteams erhöht und die Sicherheit der Software verbessert.
Kryptografische Signaturen für den Schutz von Software-Artefakten
Eine Signatur ist eine digitale Kennzeichnung eines Datenpakets, die mittels kryptografischer Verfahren erstellt wird und dazu dient, die Integrität und Authentizität der Daten zu gewährleisten. Durch die Signierung von Software und anderen digitalen Inhalten können Herkunftsinformationen nachvollziehbar und verifizierbar gemacht werden.
Ein Beispiel für ein Werkzeug, das die kryptografische Signierung in der Software-Lieferkette erleichtert, ist Sigstore. Sigstore ist eine Open-Source-Plattform, die eine sichere und transparente Infrastruktur für die Verwaltung von Software- und Artefakt-Signaturen bereitstellt. Sie ermöglicht die Erstellung, Verifizierung und Speicherung von Signaturinformationen für Softwarepakete und andere digitale Assets.
Die kryptografische Signierung ist für Herkunftsinformationen so wichtig, weil sie sicherstellt, dass die Quelle einer Software oder eines digitalen Assets vertrauenswürdig ist und nicht manipuliert wurde. Durch die Verwendung von Signaturinformationen in Kombination mit Herkunftsinformationen können Organisationen sicherstellen, dass die von ihnen verwendeten Softwarepakete aus vertrauenswürdigen Quellen stammen und nicht durch unautorisierte Dritte modifiziert wurden.
Die Vorteile der kryptografischen Signierung in der Software-Lieferkette sind vielfältig. Zum einen gewährleistet sie die Integrität und Authentizität von Softwarepaketen und anderen digitalen Inhalten, indem sie sicherstellt, dass diese nicht unbefugt geändert wurden. Darüber hinaus trägt sie dazu bei, das Risiko von Malware-Infektionen und anderen Sicherheitsvorfällen zu minimieren, indem sie sicherstellt, dass nur vertrauenswürdige Softwarepakete verwendet werden.
Um kryptografische Signierung in der Software-Lieferkette zu verwenden, müssen Softwarepakete und andere digitale Assets mit einer digitalen Signatur versehen werden, die mittels eines kryptografischen Schlüssels erstellt wird. Diese Signatur kann dann von anderen Parteien verifiziert werden, um sicherzustellen, dass die Software oder das digitale Asset authentisch ist und nicht manipuliert wurde. Durch die Verwendung von Werkzeugen wie Sigstore und cosign können Organisationen die Erstellung und Verifizierung von Signaturinformationen automatisieren und sicherstellen, dass die Integrität ihrer Software-Lieferkette gewahrt bleibt.
Fazit: Warum eine starke Software-Lieferkettensicherheit der Schlüssel zum Erfolg ist
Ein robustes Sicherheitssystem für die Software-Lieferkette ist von entscheidender Bedeutung, da es die Grundlage für den Erfolg moderner Softwareentwicklungsprojekte bildet. Die Sicherheit der Software-Lieferkette ist der Schlüssel zum Schutz vor potenziellen Sicherheitsrisiken und Angriffen, die die Integrität, Verfügbarkeit und Vertraulichkeit von Anwendungen gefährden können.
Durch eine starke Software-Lieferkettensicherheit können Organisationen sicherstellen, dass die von ihnen entwickelte Software frei von Sicherheitslücken, Schwachstellen und bösartigen Komponenten ist. Dies trägt nicht nur dazu bei, das Risiko von Sicherheitsvorfällen zu minimieren, sondern auch das Vertrauen der Nutzer in die Sicherheit und Qualität der Anwendungen zu stärken.
Darüber hinaus ermöglicht eine solide Sicherheitsinfrastruktur in der Software-Lieferkette eine schnellere und effizientere Entwicklung und Bereitstellung von Software. Durch die Automatisierung von Sicherheitsprüfungen und -tests können Entwickler Sicherheitsprobleme frühzeitig erkennen und beheben, ohne den Entwicklungsprozess zu verlangsamen.
Nicht zuletzt ist eine starke Software-Lieferkettensicherheit auch ein wichtiger Wettbewerbsvorteil. Organisationen, die sich als vertrauenswürdige Anbieter sicherer Software etablieren, können sich gegenüber ihren Wettbewerbern differenzieren und das Vertrauen ihrer Kunden gewinnen.
Insgesamt ist eine starke Software-Lieferkettensicherheit unverzichtbar, um die Sicherheit, Qualität und Zuverlässigkeit von Softwareprodukten zu gewährleisten und den langfristigen Erfolg von Softwareentwicklungsprojekten zu sichern. Es ist daher von entscheidender Bedeutung, in robuste Sicherheitsmaßnahmen und -technologien zu investieren, um die Sicherheit der gesamten Software-Lieferkette zu gewährleisten.