DevSecOps trotz quelloffener Komponenten Sicher arbeiten mit Open Source

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Von Code über Software-Pakete und -Bibliotheken bis hin zu ganzen Anwendungen: Open Source ist ein wichtiger Faktor für den florierenden Entwicklermarkt. Aber wie kann man mit – und vielleicht sogar dank – allgemein zugänglichem Code wirklich sicher arbeiten.

Erst seit der Nutzung von Open Source können moderne Anwendungen in wirklich hohem Tempo erstellt, ausgefeilt und gewartet werden. Die Zeiten, in denen Entwickler neuen Code erstellen mussten, um alltägliche Funktionen zu programmieren, sind lange vorbei. Stattdessen können sie die Erkenntnisse großer Vordenker nutzen und sich auf die Bereitstellung von neuen Features und Funktionen der eigenen Anwendungen konzentrieren.

Open Source wird von Anwendungsentwicklern mittlerweile fast flächendeckend verwendet. Nach Angaben von Gartner enthalten 96 Prozent aller Anwendungen quelloffene Pakete. Sie bilden ein massives, unsichtbares Fundament, das unter den Anwendungen liegt und den nativen Code der Entwickler stützt.

Die Open-Source-Analyse von Gartner kommt zu dem Schluss, dass vier Fünftel des Quellcodes aller Anwendungen auf Open Source basieren. Diese Möglichkeit, schneller zu entwickeln und das Rad nicht neu erfinden zu müssen, ist ein immenser Vorteil. Aber mit dieser Chance geht auch eine große Verantwortung einher.

In den vergangenen Jahren griffen Cyberkriminelle immer öfter Lieferketten an und hatten es dabei besonders auf die Open-Source-Pakete abgesehen. Die Angreifer hatten sich bestehenden Projekten angeschlossen und den darin enthaltenen Code verändert oder neue Varianten bereits existierender Pakete erstellt. Diese erweckten den Anschein, die neueste Version zu sein, beinhalteten in Wirklichkeit aber bösartigen Code.

Diese Art von Angriffen hat sich in letzter Zeit als relativ einfach und zugleich hocheffektiv erwiesen. Viele Open-Source-Pakete werden beinahe täglich aktualisiert und in Repositorys wie NPM, RubyGems und PyPi hochgeladen – meist mit wenigen oder gar keinen Sicherheitschecks. Diese Pakete werden dann teils millionenfach von Entwicklern heruntergeladen, die ebenfalls nur eine mangelhafte Sicherheitsprüfung durchführen.

Ein gutes Beispiel dafür ist der Event-Stream-Vorfall im Jahr 2018. Ein Cyberkrimineller gab sich als begeisterter und fähiger neuer Mitarbeiter von event-stream aus, einem angesehenen und nützlichen Low-Level-Dienstprogramm, das 2015 in den Wartungsmodus übergegangen war. Es dauerte nicht lange, bis der Angreifer die Bearbeitungs- und Zugriffsrechte erlangte.

In erster Instanz fügte er dem Paket eine neue, zunächst harmlose Komponente hinzu. Diese aktualisierte er aber im folgenden Monat mit einer neuen Version, die bösartigen Code enthielt. Genau dieses Paket wurde von Millionen Entwicklern heruntergeladen – es dauerte jedoch über einen Monat, bis jemand den bösartigen Inhalt bemerkte.

Der eingefügte Code zielte auf die Entwickler eines einzelnen Unternehmens ab, das eine Bitcoin-Wallet-Anwendung bereitstellt. Er sollte die Daten der Endnutzer abfangen. Aber natürlich hätte er auch andere, allgemeinere Anwendungen wie Ransomware oder andere Möglichkeiten zum Datendiebstahl enthalten können.

Die Konsequenz aus diesem und vielen ähnlichen Angriffen ist, dass Entwickler Open-Source-Pakete nicht mehr für bare Münze nehmen können. In der Vergangenheit unterlagen die 20 Prozent intern entwickelter Anwendungscodes stärkeren Sicherheitsprüfungen als Open-Source-Code. Man ging davon aus, dass Open-Source-Pakete von Natur aus vertrauenswürdiger sind.

Heutzutage weiß man, dass das eine unkluge Annahme war und Entwickler Open-Source-Pakete gründlich untersuchen sollten, bevor sie sie verwenden. Die Untersuchung sollte sich auf vier Schlüsselfragen konzentrieren:

1. Wer benutzt es?

Ein Paket, das von verschiedenen Entwicklern verwendet wird, ist potenziell vertrauenswürdiger als eines mit nur wenigen Benutzern. Eine höhere Beliebtheit lässt auch darauf schließen, dass ein Paket seine Aufgaben effektiv erfüllt. Je mehr Leute sich aktiv mit dem Paket befassen, desto wahrscheinlicher werden Schwachstellen oder neu hinzugefügter bösartiger Code entdeckt.

Repositories zeichnen die Download-Anzahl sowie die Bewertungen, Abspaltungen, Abhängigkeiten und andere Erfolgsindikatoren auf. Die Beliebtheit allein ist jedoch – wie auch der Event-Stream-Vorfall zeigte – noch nicht der Königsweg.

2. Wird es regelmäßig gewartet?

Einige Pakete sind zwar beliebt, werden aber nicht regelmäßig gewartet. Stattdessen wurden sie irgendwann als „fertig“ eingestuft oder die beteiligten Entwickler verloren das Interesse. Hier sollten die Alarmglocken schrillen. Falls Developer mit diesem Paket bei einer geschäftskritischen Anwendung auf Probleme stoßen sollten, kann ihnen niemand weiterhelfen. Außerdem können sie sich nicht sicher sein, ob das Paket mit modernen Komponenten kompatibel ist oder im Laufe der Zeit Schwachstellen entwickelt hat.

Ein Paket sollte während seiner gesamten Lebensdauer einen regelmäßigen Aktualisierungsfluss aufweisen. Entwickler sollten die Liste der offenen Probleme und Pull-Requests überprüfen. Diese deuten bei einem sehr aktiven Projekt nicht immer auf eine Schwachstelle hin; aber signifikante Lücken im Verlauf verdienen eine genauere Betrachtung.

3. Ist der Gebrauch sicher?

Beliebtheit und regelmäßige Wartung geben zwar eine gewisse Grundsicherheit, es sollte jedoch unbedingt auch das potenziell in einer Anwendung enthaltene Risiko evaluiert werden. Es ist nicht immer einfach festzustellen, ob ein Paket Sicherheitslücken oder gar bösartigen Code enthält.

Entwickler müssen sich sehr oft zwischen verschiedenen Paketen entscheiden. Dabei sollten sie natürlich das Paket wählen, das das geringste Risiko bei der gewünschten Funktionalität birgt. Gleichzeitig sollten sie die am wenigsten anfällige Version dieses Pakets verwenden, die nicht unbedingt die neueste sein muss. Eine gut gepflegte Datenbank enthält Informationen über genau diese Schwachstellen. Teile der Prüfung können auch von einer Automatisierung übernommen werden.

Sicherheit allein schützt jedoch nicht vor jedem Risiko. Jede Open-Source-Komponente wird mit einer Lizenz geliefert, die beschreibt, wie sie verwendet werden darf. Viele namhafte Unternehmen haben sich nicht an Lizenzbestimmungen gehalten und mussten deshalb Geldstrafen und andere Sanktionen hinnehmen. Entwickler sollten den Namen und die Art der Lizenz, unter der die Software veröffentlicht wurde, recherchieren und sicherstellen, dass ihre eigene Anwendung oder ihre Unternehmensrichtlinien der Compliance nicht widersprechen.

4. Wie stark ist die Community hinter dem Paket?

Bei den meisten Open-Source-Paketen liegt die Verantwortung für die Erstellung und Pflege des Codes bei einem kleinen Kernteam. Aber auch die Nutzer spielen eine wichtige Rolle, wenn es darum geht, ein Projekt zu optimieren. Sie helfen, indem sie Funktionswünsche äußern, Fehler melden und Feedback zur Roadmap geben.

Je stärker die Community, desto dynamischer und sicherer ist ein Paket. Zudem erlangt es im Laufe der Zeit neue sowie verbesserte Funktionen und Features. Eine starke, engagierte Gemeinschaft wird wahrscheinlich auch Tools entwickeln, die die Verwendung des Pakets erleichtern und so das Leben der Entwickler vereinfachen. Die Anzahl der Mitwirkenden über den gesamten Lebenszyklus des Pakets ist ein wichtiger Indikator für die Vertrauenswürdigkeit eines Projekts.

Mit einer gründlichen und kritischen Vorabprüfung der oben beschriebenen Punkte kann bei der Auswahl von Open-Source-Paketen in dem Vertrauen programmiert werden, dass die grundlegenden Anwendungselemente eine solide und vor allem sichere Unterstützung bieten.

Natürlich stellt das einen gewissen Mehraufwand dar. Diesen können funktionale webbasierte Datenbanken wie der der Snyk Advisor jedoch so reduzieren, dass benötigte Informationen so schnell wie bei einer Google-Suche bereitstehen. Der so erreichte Seelenfrieden und die vermiedenen Sicherheitsvorfällen machen den Recherche-Aufwand sehr lohnenswert.

* Daniel Berman ist Product Marketing Director bei Snyk.

Dieser Beitrag stammt von unserem Partnerportal Dev-Insider.de.

(ID:48115284)