Richtlinien, Inventarisierung und mehr 5 Best Practices für sichere Open-Source-Integration

Open Source Code ist nicht zwingend anfälliger als poprietärer Code. Bei quelloffenen Komponenten sind aber viele Informationen über Schwachstellen vorhanden, was sie für Angreifer durchaus interessant macht. Mit diesen fünf Best Practices wird Open Source sicher.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Black Duck Software, Inc.

Kürzlich hat ein Forrester Research-Report die Aufmerksamkeit auf Open-Source-Kompoenten in der Anwendungsentwicklung gelenkt: lediglich zehn bis 20 Prozent des Codes in Anwendungen seien demnach maßgeschneidert, der Rest basiert auf frei verfügbarem Code.

Obwohl traditionelle Sicherheitstools für Anwendungen wie DAST (Dynamic Application Security Testing) oder SAST (Static Application Security Testing) effektiv Bugs in maßgeschneidertem Anwendungscode finden, können sie Schwachstellen in Open-Source-Komponenten nicht identifizieren – oft auch nicht nach Monaten oder Jahren, nachdem die Bugs öffentlich bekannt wurden.

Tatsächlich werden die meisten Open-Source-Schwachstellen von Sicherheitsexperten entdeckt und nicht etwa durch DAST oder SAST. Seit dem Jahr 2004 wurden mehr als 74.000 Schwachstellen von der National Vulnerability Database (NVD) bekanntgegeben, davon resultiert jedoch nur eine Handvoll aus kommerziellen Sicherheitstools wie DAST, SAST oder Fuzzers.

Mehr als 80 Prozent aller Cyber-Attacken erfolgen auf Applikationsebene. Kombiniert man nun die Fakten, dass Anwendungen das Hauptziel von Cyberattacken sind, Open Source andererseits ein wesentlicher Bestandteil von Code heutzutage ist und schließlich traditionelle Sicherheitstools nicht effektiv in der Identifikation von Open Source sind, kommt man zu folgendem Schluss: Schwachstellen in Open Source gehören zu den größten Risiken für die Sicherheit von Anwendungen.

Unsere Forschung zeigt, dass eine kommerzielle Anwendung im Durchschnitt aus mehr als 140 diskreten Open-Source-Komponenten besteht. Im vergangenen Jahr wurden mehr als 3.600 neue Schwachstellen in Open-Source-Komponenten gemeldet – das sind im Schnitt zehn pro Tag sowie ein Anstieg um zehn Prozent gegenüber 2015.

Vor diesem Hintergrund wird klar, dass effektive Open-Source-Sicherheit und -Verwaltung dringend benötigt werden. Allerdings zeigen unsere Untersuchungen von Code konsequent, dass sich viele Organisationen der Sicherheits- und Lizenzvereinbarungsrisiken, denen sie sich mit der Verwendung von Open Source möglicherweise aussetzen, nicht bewusst sind.

Warum mögen Angreifer Open-Source-Schwachstellen?

Es gibt keinen Beweis dafür, dass Open Source mehr oder weniger sicher ist als maßgeschneiderte Software. Beides ist Software, die potenziell Bugs enthält. Aufgrund der Allgegenwärtigkeit von beliebten Open-Source-Komponenten jedoch sehen Angreifer diese als attraktive Umgebung mit öffentlich verfügbaren Informationen über Schwachstellen sowie detaillierten Informationen und Beispiele darüber, wie man sie ausnutzt.

Open Source ist nur schwer manuell nachzuverfolgen, so dass Organisationen oft nicht wissen, welche Open-Source-Komponenten sie nutzen. Im Unterschied zu kommerzieller Software, bei der dem Kunden Updates und Bug-Fixes mitgeteilt werden, ist Open Source ein „Pull“-Support-Modell.

Das heißt, die Nutzer sind selbst dafür verantwortlich, sich über Schwachstellen, Fixes und Updates für den verwendeten Open-Source-Code zu informieren. Auch wenn sich eine Organisation der verwundbaren Open-Source-Komponenten bewusst ist, die sie nutzt, ist es dennoch sehr wahrscheinlich, dass die Komponenten ungepatched bleiben.

Best Practice, um Open-Source-Risiken zu umgehen

1. Erstellung und Durchsetzung von Richtlinien für den Gebrauch von Open Source

Viele Organisationen tun sich bereits bei der Dokumentation von Open-Source-Richtlinien schwer. Es sollte einen Verantwortlichen oder ein verantwortliches Komitee geben, das den Gebrauch von Open Source überwacht, Richtlinien dokumentiert und Entwickler darin schult, wie man verantwortungsvoll mit Open Source umgeht.

2. Erstellung und Unterstützung einer umfassenden Inventarauflistung über genutzte Open-Source-Elemente

Es sollten alle Open-Source-Komponenten aufgelistet werden, die zur Erstellung einer Software genutzt werden. Ein vollständiges Inventar umfasst alle Open-Source-Komponenten, die verwendeten Versionen sowie die Downloadquellen für jedes Projekt, das genutzt oder entwickelt wird. Zudem sollten Abhängigkeiten darin enthalten sein, also die Bibliotheken, die der Code aufruft, beziehungsweise die Bibliotheken, auf die die Abhängigkeiten verlinken.

Sollten externe Entwickler beteiligt sein, sollte man sichergehen, dass diese ebenso gewissenhaft mit dem Inventar umgehen wie das eigene Team. Denn je größer das Team ist und je mehr Teams man hat, desto unhandlicher wird der Inventarprozess und desto anfälliger ist man für Fehler und Versäumnisse.

3. Überblick über bekannte Sicherheitsschwachstellen von Open Source

Quellen wie die NVD bieten Informationen zu öffentlich bekannten Schwachstellen in Open-Source-Software; jedoch werden nicht alle Schwachstellen der NVD gemeldet und oft es ist schwer zu erkennen, welche Version einer angegebenen Open-Source-Komponente betroffen ist. Man sollte sich daher nicht nur auf die NVD als Informationsquelle für Schwachstellen stützen. Weitere hilfreiche Informationsquellen sind Projektverteilungsseiten, wie sie beispielsweise von Debian- oder Python-Projekten gepflegt werden. Security-Blogs und Message Boards wie die US-CERT Alerts Page oder das Security Weblog von Google sollten ebenfalls Teil der Informationsquellen zu Schwachstellen sein.

4. Identifizierung weiterer Open-Source-Risiken

Die Nichteinhaltung von Open-Source-Lizenzierungen kann für Organisationen ein Risiko für Rechtsstreitigkeiten oder eine Verletzung des geistigen Eigentums darstellen. Ebenso kann die Verwendung von veralteten oder schlechten Komponenten die Qualität der Anwendungen beeinträchtigen.

5. Ständige Überwachung von neuen Open Source Risiken

Mit über 3.600 neuen Schwachstellen, die jedes Jahr bekannt werden, endet das Tracking von Schwachstellen nicht, wenn eine Anwendung die Entwicklungsphase verlässt. Organisationen müssen stetig Ausschau nach neuen Bedrohungen halten, solange die Anwendung in Gebrauch ist.

Ein Schritt in Richtung Open-Source-Sicherheit

Mike Pittenger

Auch wenn es einfacher scheint, wie bisher weiter zu machen und auf das Beste zu hoffen, ist der wichtigste Schritt, einen Open-Source-Security-Management-Prozess zu etablieren. Denn Anwendungsschwachstellen sind die größte Sicherheitsbedrohung für die eigene Organisation; und der Gebrauch von Komponenten mit bekannten Schwachstellen zählt zu den OWASP Top 10. Ohne Inventarisierung, Verwaltung und Sicherung der Open-Source-Komponenten, die in den Anwendungen enthalten sind, ist man für Angreifer leichte Beute.

* Mike Pittenger ist Vice President Security Strategy bei Black Duck Software und verfügt über 30 Jahre Erfahrung in Technik und Wirtschaft, mehr als 25 Jahre Führungserfahrung und 15 Jahre im Security-Bereich. Bei Black Duck ist er verantwortlich für die strategische Leitung von Sicherheitslösungen, einschließlich Produktausrichtung.

(ID:44694354)