Illustration Absmeier foto freepik ki

Digitale Bedrohungen nehmen weltweit kontinuierlich zu. Meldungen über Malware, Ransomware oder DDoS-Attacken gehören bereits zum Alltag. Und auch Angriffe auf Software Supply Chains gibt es immer öfter. Die Täter nehmen dabei gern Marktplätze ins Visier, auf denen Entwickler fertige Software-Bausteine bzw. -Pakete tauschen. Was ist also beim Schwachstellenmanagement zu beachten? Welche Rolle spielt Open Source? Auf diese Fragen mussten auch wir bei Stackable Antworten finden.

Jedes Jahr kommt es zu hunderttausenden Sicherheitsvorfällen in der IT – sowohl im Closed- als auch im Open-Source-Umfeld. Security-Experten und Cyberkriminelle liefern sich dabei ein ständiges Katz-und-Maus-Spiel um das Ausnutzen und Schließen von Schwachstellen. Und die Täter werden immer einfallsreicher. Bei Open Source besonders häufig in letzter Zeit: Supply Chain-Angriffe. Hierbei schleusen Täter Schadsoftware in Software-Pakete ein, also fertige Programmier-Bausteine. Im Global Cybersecurity Outlook 2025 des World Economic Forum gaben 54 Prozent der Organisationen an, dass die Software-Lieferkette die größte Herausforderung für die Cyberresilienz ist.

Die Beispiele sind nahezu unendlich. Zu einem berühmten Zwischenfall kam es etwa beim JavaScript-Paket node-ipc. Ein Maintainer schleuste eine »Protest-Malware« ein, mit der er Systeme in Russland und Belarus lahmlegen wollte – samt Textdatei »with love from america«. In einem anderen Fall erwischte es den GitHub Actions + PyPI-Token, wodurch infizierte Dateien veröffentlicht wurden. Und vor ein paar Wochen traf es npm, sozusagen ein Appstore für Software-Pakete, gleich doppelt: Zuerst konnten die Angreifer, nachdem sie an die Zugangsdaten eines Entwicklers gelangt waren, manipulierte Pakete in Umlauf bringen. Und nur wenige Tage später wurde ein wöchentlich millionenfach heruntergeladenes Paket mit einem Schad-Wurm infiziert.

Diese und andere Vorfälle wie Log4Shell oder der SolarWinds-Hack zeigen: Für Unternehmen ist nicht nur die physische Lieferkette enorm wichtig, sondern auch die digitale. Doch was gibt es in einem Open Source-Ökosystem zu beachten, in dem theoretisch jeder User Schadsoftware einbringen kann?

Hunderte Schwachstellen? Kein Problem!

Als CVE Numbering Authority haben wir von Stackable direkten Einblick in Schwachstellen und können bzw. müssen neue Einfallstore melden. Und für unsere Data Platform, bei der mehrere Open Source-Komponenten zum Einsatz kommen und wir uns deshalb auf die Lieferkette verlassen müssen, haben wir ein spezielles Vorgehen bei der Supply Chain Security etabliert.

Dafür mussten wir zunächst umdenken: Eine Vielzahl an Schwachstellen bedeutet nämlich nicht zwangsläufig, dass eine Software unsicher ist. Und wenige CVEs stehen nicht automatisch für Sicherheit. Scanberichte zeigen, dass selbst in Softwareprojekten großer, globaler Hersteller viele CVEs vorhanden sind. Häufig stellen sie aber nur ein theoretisches Risiko dar, und es ist in der Praxis so gut wie ausgeschlossen, dass sie Probleme verursachen.

Ein Beispiel: OpenSSH ist ein Programm für Fernzugriffe, zu dem es in der CVE-Datenbank bekannte Schwachstellen gibt. Viele automatische Sicherheitsscanner schlagen Alarm, sobald sie eine bekannte CVE in der installierten OpenSSH-Version finden. Das ist aber nur ein Indiz – nicht automatisch ein Risiko. Bei uns wird OpenSSH ausschließlich als Client genutzt, also nur, um Verbindungen nach außen aufzubauen. CVEs bei serverseitigen Funktionen von OpenSSH sind für uns deshalb nicht relevant, in anderen Bereichen aber natürlich schon.

Deshalb prüfen wir nicht jede Meldung gleich pauschal, sondern konzentrieren uns auf die tatsächlichen Gefahren. Dazu vergleichen wir CVE-Einträge mit Listen von Vulnerabilities, von denen bekannt ist, dass sie aktiv ausgenutzt werden. Und wir beobachten öffentliche Exploit-Quellen wie Metasploit oder Proof-of-Concept-Repos auf GitHub. Zusätzlich nutzen wir EPSS-Scores (Exploit Prediction Scoring System), um einzuschätzen, wie wahrscheinlich ein Schwachstellen-Missbrauch in der Praxis ist. So lassen sich echte Bedrohungen von harmlosen Treffern unterscheiden.

Warum diese Mühe? Weil wir in erster Linie ein verlässliches Produkt liefern möchten. Unser Fokus liegt auf einem stabilen System, das wir nicht durch aggressive Updates aus dem Gleichgewicht bringen möchten, wenn sie keine nennenswerten Sicherheitsvorteile bieten. Das bedeutet natürlich nicht, Updates zu vernachlässigen, sondern vielmehr zielgerichtet vorzugehen. Etwa durch Integrationstests oder mit maßgeschneiderten Tools, um Patches auch über mehrere Produktversionen hinweg zu verwalten. Und vor allem durch Open Source.

Sicherheit durch Offenheit

Software mit offenem Quellcode ist längst im Mainstream angekommen. Das zeigt der aktuelle Open Source Monitor des Branchenverbands Bitkom: Über 70 Prozent aller deutschen Unternehmen setzen inzwischen Open Source-Software ein. Zwei Punkte sind den Befragten dabei besonders wichtig – die Funktionalität und die Sicherheitsaspekte.

Auf den ersten Blick erscheint das zunächst widersprüchlich. Während wir bei proprietärer Software nicht mal eine Chance auf einen Einblick haben, können bei Open Source-Software alle User den Quellcode einsehen und verändern – also auch Menschen mit böswilligen Absichten. Und das macht Open Source eigentlich perfekt für Cyberkriminelle, um mögliche Einfallstore auszuspähen. Tatsächlich ist es aber gerade diese Offenheit, die für ein sehr hohes Maß an Sicherheit sorgt. Da viele Menschen rund um den Globus an dem Code mitarbeiten und ihre Erfahrungen teilen, werden Schwachstellen meist sehr schnell entdeckt und geschlossen. Viele Augen sehen einfach mehr.

Open Source war für uns von Beginn an das perfekte Mittel, um Funktionalität und Sicherheit zu vereinen. Was wir entwickeln, ist komplett öffentlich. Und diese Entscheidung zahlt sich jetzt auch im Security-Bereich aus. Wir haben die Kontrolle über den Quellcode und das Endprodukt, und durch die Transparenz können wir jederzeit nachvollziehen, wie und wo Schwachstellen entstehen. Zudem erstellen wir für jedes Container-Image eine Software-Bill-of-Materials, kurz SBOM, um alle enthaltenen Komponenten auf mögliche Risiken scannen zu können.

Wenn es also um eine sichere Software Supply Chain und die Bewahrung der eigenen Daten geht, heißt es in erster Linie: Don’t panic. Nur weil in einer Komponente Schwachstellen existieren, ist sie nicht automatisch gefährlich. Unternehmen sollten ein solides Schwachstellenmanagement etablieren, um über tatsächliche Risiken jederzeit informiert zu sein. Wer zudem auf Open Source setzt, unternimmt einen großen Schritt hin zu einer erhöhten Sicherheit.

Lars Francke, CTO und Mitgründer von Stackable, stackable.tech

836 Artikel zu „Software Supply Chain“

News | IT-Security | Ausgabe 7-8-2022 | Security Spezial 7-8-2022

Sicherheit in der Software Supply Chain – DevOps braucht DevSecOps

23. August 2022

Im Gespräch erklärt Frank Fischer, Product Marketing bei Snyk, warum Open Source in Software-Projekten gleichzeitig Fluch und Segen sein kann, warum Sicherheit integraler Bestandteil jedes Prozessschrittes in DevOps werden muss und das Security im Wesentlichen aus den drei Aspekten Technologie, Prozesse und Menschen besteht und die alle gleich bedacht und gestärkt werden müssen.