Der Open Source Burnout: Eine Einladung zu (noch) mehr Sicherheitslücken?

Illustration: Absmeier, Darkmoon Art

Open Source Code ist frei verfügbar und leicht zugänglich. Man kann ihn problemlos herunterladen und in eine Anwendung integrieren. Und zwar ohne zwangsläufig darüber nachzudenken, woher genau er stammt. Dabei spielt es keine Rolle, ob ein Entwickler die Entscheidung bewusst während der Planungsphase einer Anwendung getroffen hat, oder der Code über die Zeit mitgeschleppt wurde, um eine bestimmte Aufgabe zu erledigen.

 

Aber warum sollte man sich überhaupt Gedanken darüber machen, woher der verwendete Open Source Code kommt? Jedes Unternehmen, das seinem Open Source Management auch nur einen minimalen Grad an Aufmerksamkeit widmet, verfügt über Methoden und Tools, um die damit verbundenen Risiken zu erkennen und zu mindern. Und das sind einige.

Risiken in Bezug auf Schwachstellen, Lizenzverpflichtungen, respektive Lizenzkonflikte oder auch betrieblich motivierte Bedenken. Wenn Sie die Risiken eindämmen, die davon herrühren, dass Sie nicht wissen, woher Ihre Open Source Software stammt – warum ist es wichtig, mehr als das zu wissen?

 

Tatsache ist, dass es etliche Risiken gibt, die Sie nicht einfach quantifizieren können. Risiken, die nicht in Schwachstellen-Feeds auftauchen oder von Anwälten an Sie herangetragen werden. Dennoch handelt es sich um Risiken, die eine Anwendung lahmlegen und die Nutzer vor nicht unerhebliche Probleme stellen können. Wenn Sie ein grundlegendes Verständnis für die Problematik entwickeln wollen, müssen Sie sich die verwendeten Open-Source-Komponenten (denen Sie vertrauen) genauer ansehen. Etwa wie diese Komponenten entwickelt wurden und wer die Entwicklungsarbeit leistet. Nur so bekommen Sie ein Gefühl für die Stabilität und Lebensfähigkeit von Open-Source-Projekten. Mithin von genau solchen Projekten, die Grundlage der Apps sind, die Ihr Unternehmen am Laufen halten. An dieser Stelle mehr zu wissen, trägt wiederum dazu bei, das damit verbundene Risiko zu senken.

 

Es ist ein weit verbreiteter Irrglaube, dass jedes Open-Source-Projekt von Tausenden oder Millionen von Entwicklern gestützt wird, die es regelmäßig weiterentwickeln und verbessern. Das mag für einige populäre Projekte wie Kubernetes zutreffen, in den meisten Fällen ist das aber nicht der Fall.

 

Der FOSS Census II der Linux Foundation bestätigt, dass bei 23 % der Top 50 non-nmp-Projekte ein Entwickler für mehr als 80 % der Codezeilen des Projekts verantwortlich zeichnet. Bei 94 % der analysierten Projekte waren weniger als 10 Entwickler für 90 % der Codezeilen verantwortlich. Die Quintessenz: fast alle der am weitesten verbreiteten Open-Source-Produkte wird lediglich von einer Handvoll Entwickler gepflegt. Das sorgt unzweifelhaft für einen besorgniserregenden »Bus-Faktor«. Damit dieser Status zum Problem wird, muss der Entwickler nicht gleich vom Bus überfahren werden. Projekte werden aus einer Vielzahl von Gründen aufgegeben. Manch einer verliert das Interesse oder wendet sich neuen Aufgaben zu. Andere sind durch konkurrierende berufliche wie persönliche Verpflichtungen eingespannt oder sie kämpfen mit Burnout-Symptomen wie so oft in der Branche. Vielleicht sind sie es auch einfach nur leid, sich für eine eher undankbare Tätigkeit zu engagieren – eine Leistung im Übrigen, mit der nicht wenige Großunternehmen sehr viel Geld verdienen.

 

Das Problem ist klar, aber ich möchte trotzdem den direkten Zusammenhang herstellen. Wenn Sie sich für ein Open-Source-Projekt entscheiden, auf dem Ihre proprietäre Software aufsetzt – ein Open Source-Projekt, das von einem oder zwei Entwicklern gepflegt wird – und einer oder beide beschließen, daran nicht mehr mitzuarbeiten, dann bringt das App und Unternehmen in eine schwierige Lage.

 

Das ist nicht zwangsläufig bei jedem einzelnen Open-Source-Projekt ein großes Problem. Wenn das Projekt für die Benutzeroberfläche Ihrer E-Commerce-Plattform im Sande verläuft, ersetzen Sie es durch ein anderes – im Rahmen eines Rebrandings lässt sich das gut verkaufen. Das muss aber nicht so sein. Der Census II hat gezeigt, dass eine beträchtliche Anzahl von Projekten (wir sprechen hier von Millionen von Projekten), die als grundlegende Elemente moderner Apps dienen, lediglich von einer kleinen Gruppe von Mitwirkenden entwickelt werden. Was würden Sie tun, wenn Betriebssystem, Backend-Server, Logging-Framework usw. nicht mehr unterstützt würden? Abgesehen von den betrieblichen Risiken, die durch Apps mit nicht mehr gepflegtem und veraltetem Code entstehen, wie sieht es mit den Sicherheitsrisiken aus? Ein großer Teil der  Projektbetreuung besteht darin, regelmäßig Schwachstellen zu identifizieren sowie Patches und aktualisierte Versionen bereitzustellen.

 

Fallen Entwickler etwa aufgrund von Burnout aus, wird niemand diese Lücken finden, beheben und verantwortungsbewusst offenlegen. Sehr wahrscheinlich ist es, dass ein Angreifer, genau diese Schwachstellen findet und an Exploits arbeitet – und nicht an Patches oder Offenlegungen.

 

Die gute Nachricht ist, dass Unternehmen einiges tun können, um zu verhindern, dass es überhaupt erst soweit kommt. Dazu einige Beispiele:

 

  • Wenn ein Unternehmen stark von einem bestimmten Projekt abhängig ist, sollten Sie Entwickler aktiv ermutigen und ihnen gestatten, an dem Projekt mitzuarbeiten. Das ist einer der Gründe, warum das Kubernetes-Projekt so erfolgreich ist und sich so viele daran beteiligen.
  • Finanzieren Sie Initiativen und zahlen Sie Entwickler innerhalb und außerhalb Ihres Unternehmens für die Zeit, die sie in Open-Source-Projekte stecken. Die Community Bridge33 der Linux Foundation oder die Programme Bug Bounty34 und Sponsors35 von GitHub bringen Open-Source-Projekte und -Entwickler mit Finanzmitteln privater Unternehmen zusammen, die auf diese Projekte vertrauen. Außerdem hat Google im August 2021 zugesagt, in den nächsten fünf Jahren 10 Milliarden Dollar für mehr Cybersicherheit bereitzustellen und 100 Millionen Dollar an Stiftungen von Dritten wie OpenSSF zu vergeben – Stiftungen, die bei der Behebung von Sicherheitsschwachstellen in kostenloser und Open-Source-Software helfen.
  • Entlohnen Sie Ihre Entwickler dafür, dass sie Projekte, auf die Sie vertrauen, im Rahmen ihrer täglichen Arbeit pflegen.
  • Stellen Sie Aktive aus Ihren Stiftungsaktivitäten ein und lassen Sie in ihrer Freizeit an diesen Projekten arbeiten.

 

Die wichtigste Erkenntnis lautet: Das Phänomen Burnout ist innerhalb der Open-Source-Entwicklung höchst real. Und es hat nicht unerhebliche Auswirkungen auf diejenigen, die auf die von ihnen gepflegten Projekte angewiesen sind. Der beste Weg, Ausfälle zu vermeiden, besteht darin, Anreize zu schaffen und die Bemühungen wirklich zu honorieren. Es sollte immer ein Geben und Nehmen sein – geben Sie der Entwicklergemeinschaft, von der Sie profitieren, etwas zurück.

 

In Abwandlung eines berühmten Zitats von JFK: Fragen Sie nicht, was Open Source für Sie tun kann, fragen Sie, was Sie für Open Source tun können.

 

Mike McGuire, Senior Solutions Manager, Synopsys Software Integrity Group