Wie aus einer aktuellen Studie im Auftrag von CA Veracode hervorgeht, nutzen drei Viertel der befragten Unternehmen auf die eine oder andere Art Open-Source-Software. Während sich der größte Teil auf eine Kombination kommerzieller Angebote und quelloffener Software verlässt, setzten 12 Prozent sogar ausschließlich auf Open Source. Die Gründe für die Nutzung externer Komponenten liegen dabei auf der Hand: sie ermöglichen sehr kurze Release-Zyklen, die nicht möglich wären, wenn Unternehmen alle Teile einer Anwendung in Eigenregie entwickeln müssten.

Der Einsatz externer Software-Bausteine gilt schon lange als Best Practice, was aber nicht heißt, dass damit keine Risiken verbunden sind. Im Durchschnitt wurden pro untersuchter Anwendung 71 Schwachstellen gefunden, die ihre Ursache in derartigen Komponenten haben. Dennoch testen nur 23 Prozent der Befragten Komponenten nach jeder neuen Veröffentlichung auf Sicherheitslücken. Das könnte auch daran liegen, dass nur gut die Hälfte ein Verzeichnis unterhält, in dem alle verwendeten externen Komponenten erfasst sind.

Ein formelles Anwendungssicherheitsprogramm (AppSec) wurde auch nur in 71 Prozent der befragten Unternehmen implementiert. Der State of Software-Security 2017-Report von CA Veracode kam sogar zu dem Ergebnis, dass 44 Prozent aller Anwendungen gravierende Schwachstellen beinhalten, die durch Open-Source verursacht werden.

Deshalb auf die Vorteile der quelloffenen Software zu verzichten, kann nicht die Lösung sein, denn das würde die Effizienz von Entwicklern entscheidend beeinträchtigen. Stattdessen gilt es, ein Risikobewusstsein zu entwickeln, um Probleme in Open Source-Komponenten rechtzeitig zu erkennen. Mit diesem Wissen lassen sich die Gefahren minimieren.

Open Source hat einen entscheidenden Vorteil

Die 2017 durchgeführte Studie fand heraus, dass 77 Prozent der getesteten kommerziellen Software-Pakete Sicherheitsscans nach den Vorgaben des Open Web Application Security Projects (OWASP) nicht bestehen. Anbieter, die mit ihrer Software Geld verdienen wollen, machen ihren Code natürlich nicht öffentlich zugänglich, somit bekommen ihn weniger Menschen zu sehen, die Fehler finden könnten.

Nach dem sogenannten Linus‘-Law müssten sich Fehler in offenem Code mit der Zeit durch die ständige Analyse einer großen Zahl von Anwendern und Entwicklern fast vollständig eliminieren lassen. Dass mehr Augen auch mehr Fehler finden, klingt zunächst ganz einleuchtend, allerdings gibt es anderen Einschätzungen zu Folge eine begrenzte Anzahl von Reviewern, die noch sinnvoll ist. Das will heißen: einen Fehler, den der zehnte Prüfer nicht gefunden hat, findet der elfte auch nicht. Dabei kommt erschwerend hinzu, dass es in der Regel Entwicklern leichter fällt, Code zu analysieren, den sie selbst geschrieben haben. Außerdem ist nicht jeder, der die Open-Source-Komponenten verwendet, auch ein ausgewiesener Sicherheitsexperte, der Schwachstellen direkt erkennen kann.

In einem Punkt ist Open-Source-Software kommerziellen Angeboten aber definitiv überlegen: Wenn der Quellcode offen ist kann jeder einen Patch für eine bekannt gewordene Sicherheitslücke schreiben. Bei kommerzieller Software müssen Anwender dagegen auf ein Update des Herstellers warten und diesem vertrauen.

Ein Fahrplan für sichere Open-Source-Lösungen

Ein Konzept für sichere Open-Source-Nutzung ist also vonnöten. Doch wo anfangen? Anwender können sich bei der Umsetzung einer Sicherheitsstrategie an den folgenden Best-Practice-Beispielen orientieren.

1. Policies schaffen

Für eine erfolgreiche Open-Source-Sicherheitsstrategie ist es von entscheidender Bedeutung, klar zu definieren, welche Software überhaupt eingesetzt werden darf. Das klingt zunächst trivial, doch wenn Unternehmen keine klare Linie vorgeben, besteht die Gefahr, dass Mitarbeiter Software nach Gutdünken verwenden. Das schafft unkalkulierbare Risiken, die sich vermeiden lassen, wenn eine unternehmensweite Policy klar regelt, welche Software-Komponenten eingesetzt werden dürfen.

2. Patch-Management verringert die Reaktionszeit

Regelmäßige Patches sind für die Sicherheit unerlässlich, natürlich nicht nur bei Open Source. Entscheidend ist dabei aber die Zeit, die zwischen der Entdeckung einer Sicherheitslücke und der Implementierung des Patches liegt. Denn genau dieses Zeitfenster steht Cyber-Kriminellen für Angriffe offen. Deshalb sollte man es möglichst kleinhalten, indem Patches so schnell wie möglich installiert werden. Ein zentral gesteuertes Patch-Management kann dabei helfen.

3. Kontrolle von Repositories schafft Sicherheit

Entwickler benötigen für ihre Arbeit natürlich Zugang zu umfassenden Open-Source-Bibliotheken in nativen Umgebungen. Unter Sicherheitsaspekten kann es jedoch manchmal sinnvoll sein, den Zugang einzuschränken. In Frage kommt dafür zum Beispiel ein Cache-Speicher mit Software-Komponenten, die nach eigehender Prüfung eine Freigabe erhalten haben. Eine drastischere Lösung wäre eine Firewall, die den Zugriff auf bestimmte Ressourcen komplett unterbindet.

4. Software-Lieferkette sollte überprüft werden

Neben den gängigen Standardprogrammen nutzt fast jedes Unternehmen auch Software-Pakete 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.

5. Bei Sicherheit ist gut nie genug

Auch wenn der momentane Sicherheitsstandard eines Unternehmens als ausreichend beurteilt wird, ist das noch lange kein Grund, sich darauf auszuruhen. In einer Welt, in der auch das digitale Verbrechen niemals schläft, bedeutet Stillstand Rückschritt. Unternehmen sollten sich nie mit dem Status Quo zufrieden geben, sondern ständig Risikoanalysen durchführen. Daneben sollte man für alle Fälle einen Plan haben, wie Entwickler und IT-Sicherheitsexperten zusammenarbeiten um eventuelle Schwachstellen zu beseitigen.

6. Sicherheitsfachleute und Entwickler müssen an einem Strang ziehen

Um das Gefahrenpotential von Software richtig bewerten zu können, muss die IT-Sicherheitsabteilung die Werkzeuge der Entwickler kennen und auf diese zugreifen können. Die Sicherheitsexperten müssen ihrerseits den Kollegen in der Entwicklung die eigene Sichtweise klar kommunizieren. Der Informationsaustausch zwischen beiden Abteilungen ist für ein belastbares Sicherheitskonzept unerlässlich. Man kann zum Beispiel gemeinsame Trainings abhalten, um sicherzustellen, dass beide Abteilungen auf dem gleichen Stand sind, was Sicherheitslücken in Open-Source-Software betrifft.

Auch Freiheit braucht Regeln

Mit den richtigen Vorbereitungen und einer umfassenden Sicherheitsstrategie lässt sich Open-Source-Software mindestens genauso sicher nutzen wie kommerzielle Software. Im Rahmen klar definierter Regeln und mit einem gegenseitigem Austausch kann die freie Software ihr volles Potential entfalten, ohne zu einem Risiko zu werden.