Supply Chains in Open-Source-Software

Open Source ist bei der überwiegenden Mehrheit der Firmen, Softwarehersteller und -anbieter unaufhörlich auf dem Vormarsch. Mit diesem Siegeszug steigt aber auch die Bedeutung der Überwachung der Supply Chain, also der „Lieferkette“ der eingesetzten Software, die Dritte gemäß den Open-Source-Traditionen entwickelt haben. Doch nicht jeder, der Open-Source-Software benutzt, beachtet dabei alle bewährten Regeln. Greenbone kann helfen, solchen Fehlern auf die Schliche zu kommen. Dieser Blogpost erklärt das Problem und wie es sich vermeiden lässt.

 

Schwachstellen in Log4j, Docker oder NPM

Ende 2021 schlug das Bundesamt für Sicherheit in der Informationstechnik (BSI) wegen einer aus der Ferne ausnutzbaren Schwachstelle in der Logging-Bibliothek Log4j offiziell Alarm – sogar die Tagesschau berichtete. Prompt meldeten sich damals die Kritiker von Open-Source-Software zu Wort: Quelloffene Software wie Log4j sei implizit unsicher und in der Supply Chain anderer Programme ein praktisch unkalkulierbares Risiko.

Zwar hatten die Open-Source-Entwickelnden selbst das Problem binnen weniger Stunden gefixt, dennoch schlummern in zahllosen kommerziellen Produkten noch heute veraltete Versionen von Log4j – ohne Chance darauf, jemals ausgetauscht zu werden. Das ist kein Einzelfall: kürzlich sorgte die Geschichte eines Entwicklers für NPM (Node Package Manager, ein Softwarepaket-Format für den Webserver Node.js) für Aufsehen, der mit seinem eigentlich gut gemeinten Protest gegen den Krieg in der Ukraine das Vertrauen in die Open-Source-Supply-Chain und die Entwicklungsgemeinschaft massiv erschütterte.

Open Source in der Kritik

Es war nicht das erste Mal, dass NPM zum Ziel wurde. Schon Ende 2021 war der Paketmanager von Angriffen betroffen. Damals veröffentlichte der Entwickler Oleg Drapeza einen Fehlerbericht bei GitHub, nachdem er bösartigen Code zum Abfischen von Passwörtern in der Bibliothek UAParser.js gefunden hatte. Stück für Stück konnte der ursprüngliche Autor der Software, Faisal Salman, rekonstruieren, dass sich jemand in seinen Account im Paketsystem von NPM gehackt und dort Schadcode hinterlegt hatte. Das Problem: UAParser.js ist ein Modul für Node.js und kommt in Millionen von Setups weltweit zum Einsatz. Entsprechend gewaltig war der Kreis der betroffenen Nutzenden.

Wieder hieß es seitens der Open-Source-Kritischen, quelloffene Software wie UAParser.js sei implizit unsicher und in der Supply Chain anderer Programme ein praktisch unkalkulierbares Risiko. Mehr noch: Open-Source-Entwickelnde, so der explizit vorgetragene Vorwurf, bänden externe Komponenten wie Bibliotheken oder Container-Images viel zu unvorsichtig ein und verschwendeten kaum einen Gedanken an die damit verbundenen Sicherheitsimplikationen. Aus diesem Grund sei ihr Werk latent anfällig für Sicherheitsangriffe, vor allem eben in der Open-Source-Supply-Chain. Alyssa Shames diskutiert auf docker.com das Problem am Beispiel von Containern und schildert dabei ausführlich die Gefahren.

Die Schattenseiten des Basars

Tatsächlich haben DevOps und Cloud Native die Arbeitsweise in der Entwicklung in den vergangenen Jahren stark beeinflusst. In der Community existierende Komponenten in die eigene Anwendung einzubinden statt vergleichbare Funktionalität selber neu zu programmieren ist dabei Teil des Selbstverständnisses der gesamten Open-Source-Szene. Diese Community und ihr Angebot lassen sich mit einem Basar vergleichen, mit allen Vor- und Nachteilen. Viele Entwickelnde stellen ihre Programme gerade deshalb unter eine offene Lizenz, weil sie die Beiträge der anderen „Basarbesuchenden“ schätzen. Auf diese Weise können andere, die ähnliche Probleme haben, profitieren – unter denselben Bedingungen – und müssen das Rad nicht neu erfinden. Galt das früher mehr oder weniger nur für einzelne Bestandteile von Software, haben Cloud und Container dazu geführt, dass Entwickelnde inzwischen nicht mehr nur einzelne Komponenten übernehmen, sondern gleich ganze Images. Dabei handelt es sich um Softwarepakete, eventuell sogar inklusive Betriebssystem, die auf der eigenen Infrastruktur dann schlimmstenfalls ungeprüft starten.

Ein wachsendes Risiko?

In der Tat ist der mögliche Angriffsvektor dabei deutlich größer als zuvor und wird aktiv ausgenutzt. Laut Dev-Insider beispielsweise ist im vergangenen Jahr „die Zahl der Angriffe auf Open-Source-Komponenten […] von Software-Lieferketten laut einer Studie des Anbieters Sonatype […] um 430 Prozent gestiegen.“ Das bestätigt auch der Risiko-Analyse-Bericht von Synopsis, der zudem feststellt, „dass kommerzieller Code heute hauptsächlich aus Open-Source-Software besteht.“ Schon 2020 berichtete der Cloud-Native-Experte Aquasec auf seinem Blog von Angriffen auf die Docker-API, über die Cyber-Kriminelle Cryptomining in Docker-Images betrieben.

Allerdings sind Entwickelnde, die auf Open-Source-Komponenten zurückgreifen oder aus der Open-Source-Community stammen, nicht annähernd so unaufmerksam, wie es solche Meldungen suggerieren. Anders etwa als in proprietären Produkten, in denen lediglich die Mitarbeitenden eines Unternehmens den Code im Auge haben können, schauen in Open-Source-Projekten viele Menschen auf den verwalteten Quelltext. Dass dabei regelmäßig auch Sicherheitslücken wie im Fall von Log4j, Docker oder NPM ans Tageslicht kommen, liegt auf der Hand. Hier beweist die Open-Source-Szene dass sie gut funktioniert, nicht etwa dass ihre Software grundsätzlich unsicher(er) wäre.

Nicht schutzlos ausgeliefert

Ein großes Problem ist dagegen – unabhängig, ob Open-Source- oder proprietäre Software – die mangelnde Weitsicht bei der Update- und Patch-Strategie mancher Anbieter. Nur deshalb finden sich vielerorts Geräte mit veralteten, oft angreifbaren Softwareversionen, die als Scheunentor für Angreifende dienen können. Die Greenbone Enterprise Appliance, die professionelle Produktlinie von Greenbone, hilft dabei, solche Lücken zu finden und sie zu schließen.

Hinzu kommt, dass komplexe Sicherheitslecks wie die oben beschriebenen in Log4j oder UAParser.js eher die Ausnahme als die Regel darstellen. Die meisten Angriffe erfolgen mit deutlich simpleren Methoden: In den fertigen Images für Docker-Container im Docker Hub etwa findet sich regelmäßig Malware, die aus einer Datenbank den oben beschriebenen Bitcoin-Miner macht. Auch diesem Treiben stehen Entwickelnde, die Open-Source-Komponenten integrieren, jedoch keineswegs schutzlos gegenüber. Längst gibt es Standards, die Angriffe der beschriebenen Art verhindern, beispielsweise fertige Container-Images nur direkt beim Hersteller einer Lösung zu beziehen oder sie besser gleich per CI/CD-Pipeline selbst zu bauen. Ganz grundsätzlich steht Entwickelnden obendrein ein gesundes Misstrauen gut zu Gesicht, etwa wenn Software aus einer Quelle kommt, die erkennbar nicht jene des Herstellers ist.

Supply-Chain-Überwachung bei Greenbone

Dass Open-Source-Software im eigenen Programm kein unkalkulierbares Risiko ist, zeigt Greenbone in seinen Produkten, den Greenbone Enterprise Appliances. Im Unternehmen gelten eine Reihe von Richtlinien, die das Thema Supply Chain in der Softwareentwicklung in den gesamten Entwicklungszyklus einbinden. Neben umfangreichen Funktionstests unterzieht Greenbone seine Produkte dabei beispielsweise automatisierten Tests mit gängigen Sicherheitswerkzeugen. Wer bei Greenbone kauft, verlässt sich zu Recht auf das starke Gespann aus Open-Source-Transparenz und sorgfältigster Qualitätssicherung des Herstellers, ein Aufwand den sich nicht generell alle Open-Source-Projekte leisten können.