Supply-Chain-Angriffe

Open-Source-Software - Risiko für die Lieferkette?

21.04.2022
Von 
Martin Bayer ist Chefredakteur von COMPUTERWOCHE, CIO und CSO. Spezialgebiet Business-Software: Business Intelligence, Big Data, CRM, ECM und ERP.
Softwareentwicklung muss heute schnell gehen. Prüfungen, ob dabei verwendete Open-Source-Komponenten auch sicher sind, fallen oft unter den Tisch. Das kann Supply-Chain-Angriffe begünstigen.
Hacker schleusen immer mehr Malware in die Software Supply Chain.
Hacker schleusen immer mehr Malware in die Software Supply Chain.
Foto: OB KCP - shutterstock.com

Welch fatale Folgen Lücken in der Software Supply Chain nach sich ziehen können, haben die Hacks von Solarwinds und Kaseya im vergangenen Jahr gezeigt. Dabei manipulieren die Cyber­kriminellen Software-Bibliotheken oder andere Code-Komponenten, die im Rahmen des Entwicklungsprozesses verwendet werden. Die so eingeschleusten Schwachstellen nutzen sie später, um Unternehmen anzugreifen und mit Malware zu kompromittieren.

Die Per­fi­die dabei: Mit der Supply-Chain-Methode skalieren die Attacken, denn die befallene Software wird von hunderten wenn nicht gar tausenden Unternehmen eingesetzt. Das maximiert den Schaden und erhöht die Profite der Cyberbanden. Problematisch wird es auch, wenn Code kompromittiert wird, der für den Aufbau von Cloud-Infrastrukturen verwendet wird. Verlagern Unternehmen immer mehr Ressourcen in die Cloud, können an vielen Stellen die Sicherheitsrisiken zunehmen.

Open Source Software kann ein schwaches Sicherheitsglied in der Software Supply Chain sein. Hacker würden quelloffene Komponenten häufiger ins Visier nehmen, berichten die Verantwortlichen von Sonatype, einem Anbieter einer Plattform für das Software Supply Chain Management. Laut der Studie "2021 State of the Software Supply Chain" (PDF) haben die Angriffe auf Open-Source-Anbieter exponentiell zugenommen. Im vergangenen Jahr habe man weltweit 650 Prozent mehr Angriffe auf Software-Lieferketten verzeichnet, die auf die Ausnutzung von Schwachstellen in vorgelagerten Open-Source-Ökosystemen abzielten.

Dass Hacker verstärkt Open-Source-Komponenten attackieren, hat auch damit zu tun, dass Angebot und Nachfrage derzeit massiv zunehmen. Sonatype zufolge haben allein die vier größten Open-Source-Ökosysteme im vergangenen Jahr zusammen über 6,3 Millionen neue Versionen veröffentlicht und mehr als 700.000 neue Projekte eingeführt. Insgesamt kämen diese Communities auf fast 37,5 Millionen verschiedene Versionen – ein Plus von 20 Prozent gegenüber dem Vorjahr.

Auch die Nachfrage explodiert regelrecht. Die wachsenden Anforderungen nach immer schnellerer Innovation zwinge Entwickler dazu, ihren Code möglichst häufig und effizient wiederzuverwenden. Das habe zu einer starken Abhängigkeit von OSS-Bibliotheken geführt, die aus Drittanbieter-Bibliotheken stammen, konstatieren die Verantwortlichen von Sonatype. Entwickler hätten 2021 weltweit über 2,2 Billionen Open-Source-Pakete aus den vier führenden Ökosystemen heruntergeladen. Damit sei die Nachfrage im Vergleich zu 2020 um 73 Prozent gewachsen.

Supply-Chain-Angriffe: Die Methoden werden immer bösartiger

Diese Entwicklung hat allerdings auch eine Schattenseite. In den über 37 Millionen Projektversionen lauere ein "Minenfeld an bekannten und unbekannten Sicherheitsrisiken", heißt es im Sonatype-Report. Dabei gehen die Hacker gezielt vor und konzentrieren sich darauf, Schwachstellen in solchen Projekten aufzu­spüren, die am prominentesten sind. Die Cyberkriminellen begnügen sich längst nicht mehr nur damit, Exploits für bereits bekannte und öffentlich gemeldete Sicherheitslücken in Open-Source-Projekten zu platzieren. Statt­dessen ergreifen sie selbst die Initiative und schleusen neue Schwachstellen in Open-Source-Projekte ein. Fließen diese Projekte in globale Software Supply Chains, nutzen die Hacker diese Lücken dann aus.

Veraltete Open-Source-Software gefährdet Sicherheit

Diese Next-Generation-Angriffe auf Software Supply Chains sind besonders bösartig, so die Security-Fachkräfte von Sonatype. Durch die Verlegung ihrer Angriffe in den vorgelagerten Bereich (upstream) erhielten die Hacker einen entscheidenden Zeitvorteil, ihre Malware in der gesamten Supply Chain zu verbreiten, was wiederum zu gut skalierbaren Angriffen auf nachgelagerte Nutzer (downstream) führe.

Die Verteidigung gegen diese Infiltration der Continuos Integration und Continuos Delivery/Deployment (CI/CD-)Pipelines mit Malware- Packages ist schwierig. Zu diesem Ergebnis kommen die Security-Forscher von Palo Alto Networks in einem aktuellen Bericht. Das wirkt sich gerade im Cloud-Umfeld, wo die Taktung für die Bereitstellung neuer Softwarefunktionen extrem hoch ist, negativ auf die Sicherheit aus. Nahezu alle modernen nativen Cloud-Anwendungen verwenden Open-Source-Komponenten, einschließlich fast aller Software-as-a- Service-Plattformen (SaaS). Das Problem sei, dass sich kaum jemand um die Wartung oder Sicherung dieses Codes kümmere, heißt es in dem Palo-Alto-Networks-Report.

Als problematisch stufen die Sicherheitsexperten vor allem die Abhängigkeiten zwischen den verschiedenen von den Entwicklern verwendeten Paketen und Modulen ein. Jede dieser Abhängigkeiten beinhalte ein Sicherheitsrisiko und könne einen Angriffsvektor öffnen. Dazu komme, dass Third-Party-Pakete oft im Rahmen von Infrastructure as Code (IaC)Templates mehr oder weniger automatisch in die Software Supply Chain eingebaut würden – ohne dass die Entwickler vorher großartig über die Sicherheit nachdenken. Das führe dazu, dass sich Schwachstellen weitgehend unbemerkt in die IT-Infrastrukturen einschleichen können, warnen die Forscher von Palo Alto Networks.

Open Source Security - der Lieferkette zuliebe

Nach Angaben der Cloud Native Computing Foundation (CNCF) enthalten 98 Prozent der Code-Basen für den Aufbau von Cloud-Infrastruk­turen Open-Source-Komponenten. 92 Prozent davon seien veraltet oder enthielten anfälligen Code. Palo Alto Networks hat sich die verschiedenen Bestandteile angesehen, von Terraform-Scripten, einem beliebten Open-Source-IaC-Tool von Hashicorp, über Helm-Charts für das Deployment von Kubernetes-Containern bis zu Docker-Images.

Das Ergebnis der Spezialisten ist erschreckend. Zwischen 60 und 100 Prozent der untersuchten Komponenten enthalten Schwachstellen und Sicherheitslücken, viele davon sind als kritisch zu bewerten. Keine guten Aussichten angesichts der Tatsache, dass jede Software Supply Chain nur so stark ist, wie ihr schwächstes Glied. Durch die Verwendung zahl­reicher Open-Source-Tools und -Komponenten entstehen regelrechte Ketten verschiedenster Abhängigkeiten. Das macht die Absicherung kompliziert. Fachkräfte empfehlen, mehr Transparenz über die verwendeten Software­bestandteile in der eigenen CI/CD-Pipeline zu schaffen. Es brauche Einblicke in die Software-Stück­listen für jeden Workload. Nur mit dieser Transparenz sei es möglich, das damit verbundene Risiko zu bewerten und Leitplanken für die Sicherheit zu schaffen.

Neue Gesetze erhöhen zusätzlich den Druck. Im Mai vergangenen Jahres hat US-Präsident Joe Biden per Verordnung festgelegt, dass Softwarezulieferer für US-Behörden dedizierte Software Bills of Materials (SBoMs) vorlegen müssen, in denen genau aufgeführt wird, welche kommerziellen und Open-Source-Komponenten ihre Entwicklungen enthalten.

Verschiedene Organisationen und Gremien geben Tipps, wie sich die Softwareentwicklung besser absichern lässt. Dazu zählen beispielsweise die Cloud Native Computing Foundation (CNCF), die Open Source Security Foundation (OpenSSF) und Libraries.io. Letztere hat eine Metrik und ein Punktesystem entwickelt, in das die Popularität eines Open-Source-Projekts und dessen Dokumentationsqualität einfließen. OpenSSF hat den "Critically Score" ent­wickelt, der die Aktivität und Nutzung einzelner Projekte misst, sowie eine tiefergehende Scorecard, die automatisiert Entwicklungsverfahren und Tool-Einsatz analysiert, und daraus die Maturität eines Projekts ableitet. Als Qualitätsmerkmal für Open-Source-Projekte lassen sich zudem Kennzahlen wie beispielsweise die Mean Time To Upgrade (MTTU) heranziehen. Dabei handelt es sich um die durchschnittliche Zeit, die ein Projekt benötigt, um auf neue Versionen seiner Abhängigkeiten zu reagieren.