Wenn die Software-Lieferkette zum Angriffsziel wird

Ransomware, Phishing und DDoS-Attacken sind nur die sichtbare Oberfläche einer weit größeren Gefahr: Manipulationen in der Software-Lieferkette. Angreifer platzieren Schadcodes nicht mehr nur in fertigen Produkten, sondern in deren Bausteinen – dort, wo Software entsteht. Die Folge: Ein infiziertes Paket kann sich in Windeseile durch ganze Systeme fressen. Was ist also beim Schwachstellenmanagement zu beachten?

Hunderttausende Sicherheitsvorfälle gibt es weltweit jedes Jahr – Tendenz steigend. Closed Source und Open Source-Umgebungen nehmen die Täter gleichermaßen ins Visier. Bei Open Source-Software kommt es dabei in jüngster Zeit vermehrt zu Angriffen auf die darin genutzten Komponenten, also die Software-Lieferkette. Laut dem Global Cybersecurity Outlook 2025 des World Economic Forum sehen mehr als die Hälfte aller befragten Organisationen in der Software-Supply-Chain die größte Bedrohung für ihre Cyber-Resilienz.

Zwischen kompromittierten Entwicklerkonten, verseuchten Paketen und gezielten Manipulationen sind die Beispiele nahezu unendlich. Schlagzeilen hat etwa ein Zwischenfall gemacht, bei dem ein Maintainer ‚Protest-Malware‘ in das JavaScript-Paket node-ipc einschleuste, um damit Systeme in Russland und Belarus lahmzulegen. Bei einem Angriff auf den GitHub Actions + PyPI-Token kamen etliche infizierte Dateien in Umlauf. Und den Paketmanager npm erwischte es sogar schon zweimal: Beim ersten Zwischenfall schleusten die Täter manipulierte Pakete ein, nachdem sie an die Zugangsdaten eines Entwicklers gelangt waren. Und kurz darauf wurde ein Paket mit Malware infiziert, das pro Woche millionenfach heruntergeladen wird.

Unternehmen sollten sich also nicht nur auf die physische Lieferkette konzentrieren, sondern auch die digitale absichern. In einem Open Source-Umfeld, bei dem jeder Anwender Schadsoftware einbringen kann, ist das leichter gesagt als getan. Was gibt es also für Möglichkeiten?

Viele Schwachstellen, wenig Risiko?

Wenn ein Unternehmen als CVE Numbering Authority, kurz CNA, autorisiert ist, hat es nicht nur direkten Einblick in Schwachstellen, sondern kann und muss diese auch selbstständig melden. Und beispielsweise als Hersteller einer Data Platform mit verschiedenen Open Source-Komponenten ist auch das Unternehmen auf eine verlässliche Lieferkette angewiesen. Um die Supply Chain Security sicherzustellen, ist deshalb ein besonderes Vorgehen nötig.

Zunächst einmal ist es wichtig, sich von der oft vorherrschenden Meinung zu verabschieden. In Sicherheitsberichten ist häufig von hunderten offener ‚Common Vulnerabilities and Exposures‘, bzw. CVEs die Rede. Das klingt dramatisch, ist aber oft irreführend. Eine lange Liste von CVEs bedeutet nicht zwangsläufig Unsicherheit – ebenso wie wenige Einträge nicht automatisch Sicherheit bedeuten. Entscheidend ist die Relevanz der Schwachstelle im jeweiligen Anwendungskontext.

Ein typisches Beispiel aus der Arbeit: Bei dem für Fernzugriffe genutzten Programm OpenSSH gibt es einige bekannte Schwachstellen in der CVE-Datenbank. Und viele Sicherheitsscanner schlagen automatisch Alarm, wenn sie eine bekannte CVE in der installierten Version von OpenSSH entdecken. Ein Risiko besteht deshalb aber nicht zwangsläufig. Das Programm lässt sich beispielsweise nur als Client nutzen, also um Verbindungen nach außen aufzubauen. Und deshalb sind CVEs bei den serverseitigen Funktionen von OpenSSH nicht von Bedeutung – an anderen Stellen aber natürlich schon.

Deshalb sollte man es sich zur Priorität machen, nicht alle Sicherheitshinweise gleich pauschal zu prüfen, sondern sich auf die wirklichen Gefahren zu konzentrieren. So lässt sich ein effektives Schwachstellenmanagement etablieren, bei dem man das Signal vom Rauschen trennen kann. Eine Möglichkeit ist es etwa, die öffentlich einsehbaren CVE-Einträge mit Listen von Vulnerabilities zu vergleichen, von denen bekannt ist, dass Cyberkriminelle sie ausnutzen. Oder Exploit-Quellen wie das Proof-of-Concept-Repos auf GitHub oder Metasploit im Auge zu behalten. Nützlich ist auch der Einsatz von Exploit Prediction Scoring Systemen, kurz EPSS, um die Wahrscheinlichkeit eines Schwachstellen-Exploits einzuschätzen. Denn entscheidend ist letztendlich, ob eine Lücke ausgenutzt wird – nicht, ob sie existiert.

Klingt nach viel Arbeit? Ist es auch. Aber die Mühe ist es wert. Denn so lassen sich Updates priorisieren, anstatt Systeme durch überhastete Patches aus dem Gleichgewicht zu bringen. Das Ziel sollte nicht eine maximale Update-Frequenz sein, sondern stabile Sicherheit. Mit Integrationstests und zugeschnittenen Tools, um Patches selbst über mehrere Versionen zu verwalten. Und mit einem klaren Bekenntnis zu Open Source.

Offenheit als Sicherheitsprinzip

Aktuelle Umfragen zeigen: Software mit offenem Quellcode ist keine Randerscheinung mehr, sondern mittlerweile fest im Mainstream etabliert. Zu dem Schluss kam beispielsweise auch der Open Source Monitor 2025 des Branchenverbands Bitkom. Dort gaben mehr als 70 Prozent der befragten Unternehmen an, dass sie Open Source-Lösungen in verschiedenen Bereichen nutzen. Auf die Frage, welche Aspekte sie besonders überzeugen, antworten die meisten Befragten: Funktionalität und Sicherheit.

Beim Thema Sicherheit spielt Open Source-Software eine doppelte Rolle – sie ist Angriffsziel und Abwehrmechanismus zugleich. Wie sich mit Open Source die Sicherheit erhöhen lässt, ergibt sich dabei nicht sofort. Denn während man bei proprietärer, geschlossener Software keinen Zugang zum Quellcode hat, können ihn bei Open Source alle Anwender einsehen und verändern. Für Cyberkriminelle also das vermeintlich beste Mittel, um Einfallstore zu orten. In Wirklichkeit sorgt aber gerade diese Transparenz für ein äußerst hohes Maß an Sicherheit. Schwachstellen werden deutlich schneller entdeckt und geschlossen als bei proprietärer Software, da viele Menschen auf der ganzen Welt am Code arbeiten und ihn kontrollieren. So ergibt sich ein unschlagbares Teamwork zwischen Community und Entwicklern.

Open Source ist das optimale Werkzeug, um Sicherheit und Funktionalität zu vereinen. Was bei einem offenen Quellcode entwickelt und geändert wird, ist keine Verschlusssache – alle User können jeden Schritt jederzeit nachvollziehen. Und diese Transparenz zahlt sich auch beim Thema Security aus. Da die Entwickler die komplette Kontrolle über den Quellcode und das Endprodukt haben, können sie immer nachvollziehen, wo und warum Schwachstellen entstehen. Darüber hinaus empfiehlt es sich, für jedes Container-Image eine SBOM zu erstellen, also eine Software-Bill-of-Materials, wodurch sich alle integrierten Komponenten nach potentiellen Risiken durchleuchten lassen.

Nur wer also seine Software-Lieferkette kennt, kann sie auch schützen. Panik ist fehl am Platz, Sorgfalt dagegen Pflicht. Nicht jede Schwachstelle ist gefährlich, aber jede verdient Aufmerksamkeit. Der Unterschied liegt im Wissen um Zusammenhänge – und in der Bereitschaft, Sicherheit nicht als Produkt, sondern als fortlaufenden Prozess zu begreifen. Und dafür ist der Einsatz von Open Source-Lösungen das optimale Mittel.