Tierney - stock.adobe.com
Mit Open-Source-Sicherheitsrisiken richtig umgehen
Von Open-Source-Problemen wie Heartbleed zu Alltagsschwachstellen und Abhängigkeiten. Wie sicher ist Open Source wirklich? Das reale Risiko und der richtige Umgang damit.
Open Source ist heute Mainstream und bei Entwicklern ebenso beliebt wie im Projektmanagement. Der Siegeszug von quelloffener Software hat viele Gründe – für Entwickler besteht der Anreiz vor allem darin, effizienter zu entwickeln. Dank frei verfügbaren Open-Source-Bibliotheken können Entwickler schnell auf umfangreichen Code zugreifen, ohne ihn neu schreiben zu müssen.
Wie der neue Veracode State of Software Security: Open Source Report zeigt, finden sich in über 75 Prozent aller 85.000 getesteten Anwendungen die gleichen beliebten Open-Source-Bibliotheken wieder.
Neben den Vorteilen bringt diese Methode der Einbindung von Open Source jedoch auch einige Risiken mit sich. Abhängigkeiten innerhalb der Bibliotheken führen dazu, dass mehr nachgeladen wird, als der Entwickler aktiv einbindet. Und damit oft mehr, als er will. Wieviel nachgeladen wird, hängt von mehreren Faktoren ab – unter anderem von der verwendeten Programmiersprache. Vor allem JavaScript, Ruby und PHP führen zu transitiven Abhängigkeiten.
Das bedeutet nicht, dass die drei Sprachen notwendigerweise mehr Fehler mit sich bringen, doch die Wahrscheinlichkeit, sich unbewusst Schwachstellen einzufangen, steigt. Besonders PHP ist gefährlich: Der Einsatz einer PHP-Bibliothek führt mit über 50-prozentiger Wahrscheinlichkeit zur Integration einer Sicherheitsschwachstelle. Die häufigste Fehlerkategorie der OWASP Top Ten liegt in Open-Source-Bibliotheken im Bereich Access Control. Konkret sind die wichtigsten drei Schwachstellen Broken Access Control, unsichere Deserialisierung und Cross Site Scripting.
Open Source ist überall – ist das sicher?
Die Beliebtheit von Open Source hat dazu geführt, dass die erwähnten Open-Source-Bibliotheken in Unternehmen, Behörden und Universitäten genutzt werden. Eine typische Anwendung enthält heute im Schnitt 257 Open-Source-Komponenten, viele Anwendungen bestehen zu 90 Prozent aus Open-Source-Code.
Dabei geht es nicht nur um eine effizientere Entwicklung, auch die Code-Optimierung lässt sich mit einsehbarem Quellcode besser realisieren. Am Ende stehen damit minimale Release-Zyklen, die ohne Open Source nicht möglich wären.
Wenn es um die Sicherheit bei Open Source geht, gibt es klassischerweise zwei Lager: Auf der einen Seite gibt es das sogenannte Linus-Gesetz. Einfach ausgedrückt lautet es: Mehr Augen sehen mehr Fehler – weil Open Source einer ganzen Community offensteht, statt nur proprietären Entwicklern, lassen sich demnach Fehler einfacher finden, was zu mehr Sicherheit führt.
Dem entgegen stehen nicht nur Open-Source-Desaster wie Heartbleed, sondern auch die Einschränkung der abnehmenden Wirksamkeit von Prüfern: Einen Fehler, den der zehnte Prüfer nicht findet, findet auch der elfte nicht.
Mit dem Risiko leben
All die aufgelisteten Herausforderungen könnten den Schluss zulassen, dass Open Source gefährlich ist. Doch das wäre falsch. Zum einen ist proprietäre Software ebenso fehleranfällig, nur ist sie schwerer zu prüfen, da der Quellcode nicht zur Verfügung steht. Zum anderen sind die meisten Schwachstellen, die durch die Einbindung fehlerhafter Open-Source-Bibliotheken entstehen, einfach zu patchen. Ein kleines Versions-Update genügt.
Die Vorteile von Open Source überwiegen – Entwickler müssen nicht auf die Effizienz verzichten, die sie gewohnt sind. Sie müssen sich jedoch mit dem Problem der Abhängigkeiten beschäftigen und ein Risikobewusstsein entwickeln. Der Erfahrung nach lassen sich die Tipps an Entwickler und Unternehmen, wenn es um den Umgang mit Open Source geht, in fünf Schritte gliedern:
1. Interne Policies
Der naheliegende erste Punkt bei der Risikokontrolle ist die Kontrolle der Softwarekomponenten. Zunächst lohnt es sich, Policies bezüglich der Software selbst zu definieren: Welche Software soll in der Entwicklung eingesetzt werden? Welche Software soll ausgeschlossen werden? Dadurch lassen sich bereits einige grundlegende Risiken vermeiden.
2. Repository-Kontrolle
Der zweite Schritt ist die Kontrolle der Repositories. Entwickler brauchen umfassenden Zugang zu Bibliotheken, doch nicht alle Bibliotheken sind wirklich notwendig. Denkbar und in der Praxis auch machbar sind Lösungen wie ein Cache-Speicher, mit Komponenten, die geprüft und freigegeben werden. Eine drastischere Lösung ist eine Firewall beziehungsweise Block List, die bestimmte Ressourcen direkt ausblendet. Hier gilt es (wie auch bei Punkt 1), eine Balance zwischen Kontrolle und Workflow-Effizienz herzustellen. Wer zu viel blockt, behindert seine Entwickler.
3. Kontrolle der Software Supply Chain
Neben den gängigen Standards nutzt fast jedes Unternehmen auch Softwarepakete diverser Hersteller. Auf diesem Weg können neben bekannten Problemen Sicherheitslücken ins Unternehmen Einzug halten, von denen nicht einmal Experten etwas wissen. Hier kann man mit Sicherheitstests Abhilfe schaffen. Solche Überprüfungen sollten mit Tools für statische Code-Analyse und Werkzeugen für Software Composition Analysis (SCA) durchgeführt werden. Die Sicherheits- und Softwareexperten im Unternehmen erhalten dadurch einen fundierten Einblick in bestehende Risiken.
„Mit den richtigen Vorbereitungen und einer umfassenden Sicherheitsstrategie lässt sich Open Source mindestens genauso sicher nutzen wie proprietäre Software.“
Julian Totzek-Hallhuber, Veracode
4. Patch-Management
Regelmäßige Patches sind nicht nur bei Open Source für die Sicherheit unerlässlich. Entscheidend ist die Zeit, die zwischen der Entdeckung der Sicherheitslücke und dem Patchen liegt. Diese Zeit ist das Fenster für einen Angriff. Ein zentral gesteuertes Patch-Management kann dabei helfen, diese Fenster so klein wie nur möglich zu halten. Außerdem sollte Patchen zur Selbstverständlichkeit werden und in die Routine im Arbeitsablauf integriert werden.
5. Zusammenarbeit von Security und Development
Um das Gefahrenpotential von Software bewerten zu können, müssen die Sicherheitsteams die Werkzeuge der Entwickler kennen und die Prozesse in der Softwareentwicklung verstehen. Die Sicherheitsexperten müssen ihrerseits den Kollegen in der Entwicklung die eigene Sichtweise, ihr Vorgehen und ihre Methoden klar kommunizieren. Der Informationsaustausch zwischen beiden Abteilungen ist für ein belastbares Sicherheitskonzept unerlässlich. Dabei helfen gemeinsame Trainings, die gleichzeitig für mehr Zusammenhalt und ein Abgleichen des Wissensstandes sorgen.
Fazit: Open Source mit klaren Regeln nutzen
Open Source lässt sich heute aus der Entwicklung nicht mehr wegdenken. Das muss es auch nicht. Open Source bietet viele Vorteile und steht auch im Bereich Risiko und Schwachstellen nicht schlechter da als proprietäre Software. Allerdings kann die schnelle Verfügbarkeit von Open-Source-Bibliotheken dazu führen, dass Entwickler ihre Vorsicht vergessen.
Mit den richtigen Vorbereitungen und einer umfassenden Sicherheitsstrategie lässt sich Open Source mindestens genauso sicher nutzen wie proprietäre Software. Im Rahmen klar definierter Regeln und unter gegenseitigem Austausch, kann der Einsatz von Open-Source-Komponenten und Open-Source-Bibliotheken mit geringem Risiko erfolgen.
