Die größten Risiken für Ihre Software-Lieferkette

Der von Unternehmen erstellte Code ist nur der Beginn der modernen Softwareentwicklung. Tatsächlich macht der Code von Erstanbietern oft nur einen kleinen Teil – mitunter lediglich 10 % – der Artefaktsammlung einer Anwendung aus.

Die Software-Lieferkette eines Unternehmens umfasst zahlreiche Bestandteile aus unterschiedlichen Quellen: Open-Source-Paketen, kommerzieller Software, Infrastructure-as-code- bzw. IaC-Dateien, Containern, Betriebssystem-Images und mehr. Folglich sind bei der abzusichernden Lieferkette unzählige Risikopunkte zu berücksichtigen. Auch birgt sie aufgrund von menschlichen Fehlern und Nachlässigkeiten, schlechter Qualität sowie böswilligen Angriffen ein großes Potenzial für Sicherheitsbedrohungen.

Die vier wichtigsten Trends bei den Risiken für Software-Lieferketten

Das Wissen um diese anfälligen Risikopunkte ist für den Schutz Ihrer Software-Lieferkette wichtig. Diese jedoch mit Einzellösungen beheben zu wollen, ist Sisyphusarbeit – eine an einem Punkt ausgemerzte Bedrohung kann sich leicht unerkannt an anderer Stelle erneut etablieren.

Der vollständige Schutz Ihrer Lieferkette vor Bedrohungen erfordert durchgängige Wachsamkeit. Diese Wachsamkeit beginnt bereits, bevor Ihre Entwickler externe Pakete abrufen, und ist auch bei der Entwicklung von eigenem Code, der Codekompilierung, der Erstellung von Interim-Builds sowie der Veröffentlichung und Verteilung bis hin zur Produktion – und sogar über die Bereitstellung hinaus – erforderlich. Dabei gilt es nicht nur, Schwachstellen und andere Sicherheitsprobleme aufzudecken. Ohne Kenntnisse des Kontexts können Sie das wahre Risiko nicht reell bewerten.

Bedrohungen der Software-Lieferkette lassen sich (grob) in zwei Kategorien unterteilen.

Bei der einen Art nutzen Angreifer die „offene Natur“ der Lieferkette, um Informationen über die Software zu gewinnen. Ein gängiges Beispiel ist der Versuch, einen Webdienst remote abzubilden oder eine Software für IoT-Devices einzuschleusen, um sich mit den verwendeten Open-Source-Paketen vertraut zu machen. Für die Hacker ist es daraufhin ein Leichtes, mit diesen Paketen verbundene CVE-Informationen ausfindig zu machen, mehr über die Sicherheitskonfigurationen der Pakete zu erfahren oder sogar noch unbekannte Schwachstellen (Zero-Day-Lücken) zu ermitteln. Nachdem Angreifer ausreichend Kenntnisse über Angriffswege erlangt haben, können sie zum nächsten Schritt übergehen.

Dabei wird die Lieferkette genutzt, um öffentliche oder private Repositorys mit schädlichen Paketen und Schadcode zu injizieren oder vorhandenen Code zu verändern.

Bedrohung der Software-Lieferketten über zwei Angriffswege

Werfen wir einen Blick auf vier gängige Risiken für die Software-Lieferkette, die diese für Angriffe anfällig machen können:

1. Bekannte Schwachstellen

Komponenten von Drittanbietern – wie etwa Open-Source- und kommerzielle Software – können unbeabsichtigte Schwachstellen enthalten. Viele davon sind bekannt und in der CVE-Liste (Common Vulnerabilities and Exposure = häufige Schwachstellen und Risiken) aufgeführt.

Sie können diese Risiken mittels einer SCA-Lösung (Software Component Analysis) aufdecken. Dabei wird die SBOM (Software Bill of Materials) eines Codes oder Artefakts identifiziert und mit bekannten CVEs verglichen. Für den Vergleich werden meist die Metadaten der identifizierten Software und öffentliche CVE-Datenbanken herangezogen.

Sie benötigen jedoch auch ausreichend Informationen, um risikobasierte Entscheidungen treffen und automatisieren zu können. Eine erweiterte Datenbank ist dafür unabdingbar. Damit lassen sich nicht nur mehr Risiken verfolgen, sondern auch eingehende Sicherheitsuntersuchungen durchführen. Dies ermöglicht es Ihnen, alle Optionen zur Minderung dieser Risiken zu verstehen und die effektivste und kostengünstigste Methode zu wählen.

Gleichermaßen wichtig sind Kontextanalysen, um die Angriffswahrscheinlichkeit über die verschiedenen Sicherheitslücken zu ermitteln. Möglicherweise wird eine anfällige Funktion in einer Komponente nicht von der Anwendung genutzt oder ein anfälliger Prozess nie in einer Produktionsversion ausgeführt. Bestimmte Konfigurationen können eine CVE-Liste auch nutzlos machen.

Auch bei scheinbar sicheren Komponenten lassen sich potenzielle operationelle Risiken erkennen. Ein seit Längerem nicht verwaltetes Open-Source-Paket wurde beispielsweise vielleicht auch nicht ausreichend hinsichtlich Sicherheitsproblemen überwacht. In diesen Fällen besteht trotz fehlender Gewissheit hinsichtlich Schwachstellen ein erhöhtes Bedrohungspotenzial.

Diese bekannten und potenziellen Risiken können und sollten an folgenden Punkten entdeckt werden:

• Quellcode: Die Sicherheit bereits frühzeitig bei der Codeerstellung zu überwachen, kann später Kosten für die Behebung von Schwachstellen sparen. Sicherheitsteams können ein internes Repository genehmigter Komponenten von Drittanbietern erstellen. Warnungen an Entwickler bezüglich anfälliger Abhängigkeiten infolge von Erweiterungen auf die integrierte Entwicklerumgebung (IDE) sind ebenfalls eine Option. Auch wenn dies kein umfassender Ansatz ist, kann er dennoch zur Vermeidung bekannter Risiken beitragen. Zu bedenken ist jedoch, dass Shift-Left-Sicherheitstools die Entwickler in der Regel mit Hunderten oder Tausenden Aufgaben überfrachten, die unter dem Gesichtspunkt der Sicherheit nicht zwingend effektiv sind, da der vollständige Kontext der Schwachstelle oder des Sicherheitsproblems fehlt.
• Binärdateien: Ein automatisierter SCA-Scan aller Pakete, Builds und Images in wichtigen Binär-Repositorys (Komponenten von Erst- und Drittanbietern) stellen sicher, dass Ihre komplette Software-Lieferkette vor bekannten Schwachstellen und operationellen Risiken geschützt ist. Binärdateien sind die genaueste Darstellung des Produktionsstands Ihrer Anwendung und ermöglichen aufgrund des präziseren Kontexts die hochwertigste reale Risikoanalyse. Außerdem lassen sich damit Probleme analysieren, die mit Shift-Left-Tools und Sicherheitslösungen in der Produktion nicht erkennbar sind.

2. Unbekannte Schwachstellen (Zero-Day-Bedrohungen)

Fehler sind bei der Codierung nichts Außergewöhnliches. Logische Fehler, schlechte Verschlüsselungen und potenzielle Speichermanipulationen erhöhen die Anfälligkeit von Anwendungen etwa für RCE- (Remote Code Execution) und DoS-Angriffe (Denial-of-Service). Diese Fehler können mitunter jahrelang unbemerkt in Code von Erst- und Drittanbietern lauern, bevor sie erkannt werden.

Sie sind als „Zero-Day“-Bedrohungen bekannt – zum einen wegen der Dauer ihrer Bekanntheit, aber auch aufgrund dessen, dass Sicherheitsteams für die Behebung in bereits entwickelter Software „null Tage“ haben.

Um potenzielle Zero-Day-Bedrohungen zu erkennen und zu vermeiden, müssen alle Komponenten und Anwendungen getestet werden. Dabei ist die Interaktion zwischen unterschiedlichen Binärdateien, Prozessen und Diensten zu berücksichtigen. Mit Tools für die statische Codeanalyse (zur Überprüfung der Codequelle) sowie die dynamische Codeprüfung (zum Testen des ausgeführten Codes) lassen sich in der Regel 85 % der Fehler identifizieren. Dabei werden pro Release meist jedoch auch Tausende von Einträgen generiert, sodass Fachkenntnisse erforderlich sind, um die Ergebnisse zu interpretieren und zu priorisieren. Neben bekannten Problemen können auch Schwachstellen existieren, die nicht zwingend angreifbar sind.

Mit fortschrittlicheren Technologien, die eine symbolische Ausführung, Datenflussanalysen und automatisiertes Fuzzing vereinen, können Sie den Anteil an Falschmeldungen drastisch reduzieren und Schwachstellen identifizieren, die mit konventionellen SAST- und DAST-Verfahren nicht erkennbar sind. Die kombinierte Analyse von Quell- und Binärdateien kann auch zu besseren Ergebnissen führen. Dies ermöglicht es Entwicklern, Sicherheitsteams und Produktionsmanagern, sich auf die Behebung kritischer Fehler zu konzentrieren.

Trotz akribischer Maßnahmen können jederzeit neue Schwachstellen erkannt werden und bereits bereitgestellte Software beeinträchtigen. Ein kontinuierlicher SCA-Scan ermöglicht mitunter eine schnelle Benachrichtigung bezüglich brandaktueller CVEs, die sich auf Produktionssoftware auswirken. Mit umfangreichen SBOM-Metadaten lassen sich die vollständigen Auswirkungen einer Schwachstelle in Ihrem Unternehmen schnell ermitteln und mindern oder in allen Ihren Anwendungen beheben. Durch die ordnungsgemäße Integration mit Code und Artefakt-Repositorys können schnell innerhalb des gesamten Unternehmens Maßnahmen ergriffen werden, um die identifizierte Bedrohung abzuschwächen.

3. Nicht codespezifische Probleme

Nicht alle Schwachstellen sind im Code zu finden. Sie können sich auch in Binärdateien wie EPMs, Containern mit JAR-Dateien, Firmware sowie unterstützenden Artefakten wie Konfigurations- oder IaC-Dateien verbergen. Fehlkonfigurationen, schlechte Verschlüsselung, die Offenlegung von Secrets und privaten Schlüsseln sowie Probleme mit dem Betriebssystem stellen potenzielle Angriffsflächen dar.

Diese Nebenprodukte menschlicher Fehler sind in der Regel auf Unachtsamkeit zurückzuführen und schleichen sich meist unauffällig in große Entwicklungsprojekte ein. Schnell für Testzwecke erstellte Konfigurationen können versehentlich für die Produktion bereitgestellt werden. Diese Risiken lassen sich oft leicht eliminieren, während sich die Erkennung und anschließende Systemwiederherstellung deutlich schwieriger gestalten.

Selbst kleine Versehen können großen Schaden anrichten. Der berüchtigte Hackerangriff auf SolarWinds begann mit einer Passwortoffenlegung auf einem öffentlichen GitHub-Server. Dadurch konnte schädlicher Code injiziert werden, der letztendlich zur Offenlegung vertraulicher Regierungsdaten führte. Verwirrung hinsichtlich der Abhängigkeit zwischen Paketen mit ähnlichen Namen kann ebenfalls ohne böse Absicht entstehen. Dies ist insbesondere bei einer schlecht konfigurierten Auflösung des Paket-Repositorys der Fall.

Diese Probleme müssen möglichst früh erkannt werden, bevor sie in die Produktion gelangen. Nehmen Sie diese potenziellen Risiken mindestens ebenso ernst, wie Sicherheitslücken in Ihrem Code. Wenden Sie diese Wachsamkeit auch durchgängig auf den Sicherheitsstatus Ihrer Pipelines an.

4. Schädlicher Code

Vorsätzliche Bedrohungen, egal, ob durch externe Angreifer oder böswillige Insider, können am schwierigsten zu ermitteln sein. Diese Angriffe erfolgen häufig über bereits überprüfte Komponenten. Trojaner, Bots, Ransomware, Cryptomining und Spyware werden oft als Nutzlasten mit den bereits erörterten Schwachstellenarten eingeschleust. Das Infiltrieren beliebter Repositorys mit schädlichen Paketen, Hackerangriffe auf Administratorkonten, um vorhandene Pakete zu manipulieren, oder die Injektion von Code in kompromittierte Quell-Repositorys sind gängige Angriffsmethoden über die Hintertür.

Werden diese Angriffe erst nach der Bereitstellung erkannt, ist es in der Regel zu spät. Der Schaden ist bereits angerichtet und kann extrem kostspielig sein. Aus diesem Grund sollten Sie Ihre gesamte Pipeline davor schützen:

• Zugriffskontrolle: Bei internen Paket-Repositorys sollte der Schreibzugriff mithilfe von unternehmensweit konsistenten Berechtigungen und Authentifizierungen (einschließlich Multi-Faktor-Authentifizierung) auf wichtige Rollen und Teammitglieder begrenzt werden.
• Proxy-Repositorys: Das Zwischenspeichern externer Repositorys (wie etwa Maven Central und npm) kann einen unveränderlichen Snapshot von Drittanbieterressourcen liefern. Jegliche nachfolgenden böswilligen Überschreibungen werden dadurch sofort sichtbar.
• Tests und Analysen: Mit ausgefeilten Tools für statische und dynamische Analysen können Sie Schadcode und böswillige Verhaltensweisen fragwürdiger Pakete erkennen und melden. Das bei JFrog für die Sicherheitsforschung zuständige Team hat mit eigens dafür entwickelten Tools mehr als 1.300 schädliche Pakete in öffentlichen Paket-Repositorys ermittelt.

Durchgängige Wachsamkeit für das Risikomanagement der Software-Lieferkette

Während sich einige dieser Risiken einzeln mindern lassen, sind Punktlösungen lediglich Warnsysteme – die nur da helfen, wo Sie sie gezielt einsetzen.

Auch separate Sicherheitslösungen nützen daher nur bedingt. Infolge der begrenzten Reichweite kann damit nicht der vollständige Kontext eines Risikos innerhalb der gesamten Software-Lieferkette analysiert und bewertet werden. Unabhängig von den Repositorys und den Softwareverwaltungslösungen wäre es selbst bei extrem genauen Punktlösungen für die Sicherheit äußerst schwierig, das identifizierte Problem effektiv zu mindern oder zu beheben.

Ein umfassender Sicherheitsstatus muss Ihnen neben der Überwachung einzelner Pipeline-Punkte auch die Möglichkeit geben, die Zusammenhänge zwischen verschiedenen Problemen und Sicherheitsrisiken zu verstehen – was mit separaten Nischenlösungen nicht zu bewerkstelligen ist.

Für die Softwaresicherheit ist eine durchgängige Wachsamkeit wichtig. Diese beginnt bei der IDE des Entwicklers und endet in der Produktion. Sie erzwingt einen konsistenten Überblick über die Risiken und ermöglicht deren Minderung in Entwicklungs- und Produktionsumgebungen gleichermaßen. Ihre Sicherheitslösungen müssen Ihre Software-Lieferkette ganzheitlich schützen und umfangreiche Maßnahmen ermöglichen. Für die unternehmensweite Konsistenz ist es wichtig, dass die Lösung in einer zentralen Datenquelle für alle Ihre Binärdateien ausgeführt wird und umfangreich mit Ihren DevOps-Tools integriert ist.

Sie möchten mehr über neue Entwicklungen von JFrog erfahren, die diese Anforderungen erfüllen? Registrieren Sie sich für eine der demnächst stattfindenden swampUp-Städtetouren in Ihrer Nähe.