2014 kam die "Heartbleed"-Lücke ans Licht, und die Leute die behaupteten, dass Free and Open Source Software (FOSS) im Vergleich zu proprietärer Software sicherer sei, verstummten allmählich. Und bis heute gibt die Sicherheit, beziehungsweise Unsicherheit von FOSS immer wieder zu reden.

So ist beispielsweise das deutsche CERT BSI inzwischen bei Update 18 über 3 Lücken im Linux Kernel mit der höchsten Risiko-Einschätzung angelangt.

Der Bericht "Report on the 2020 FOSS Contributor Survey", den die Linux Foundation und das Laboratory for Innovation Science der Harvard Universität publiziert haben, deutet an, warum dem so ist und warum die Security-Lücken von OSS so lange leben.

Denn Ziel dieser Umfrage war es unter anderem, den Stand der Sicherheit und Nachhaltigkeit bei FOSS zu verstehen und Möglichkeiten zu deren Verbesserung zu identifizieren, dies auf technologischer wie menschlicher Seite.

Das Ergebnis ist aus Security-Sicht ernüchternd. Pro Stunde Arbeit investieren die Developer gerade mal rund 80 Sekunden für Security-Fragen im Code (2,27%). Aus den Antworten geht hervor, dass viele Befragte kein Interesse daran haben, Zeit und Aufwand für die Sicherheit auf sich zu nehmen. Ein Befragter sagte: "Ich halte das Thema Sicherheit für eine für die Seele belastende Aufgabe und ein Thema, das am besten den Anwälten und Prozessfreaks überlassen bleibt. Ich bin ein Applikationsentwickler". Ein anderer sagte: "Ich finde Sicherheit ein unerträglich langweiliges Hindernis."

Lieber würden sie ihre Prioritäten schneller abarbeiten.

Ganz abgesehen davon gehört Security nicht zu den Motivatoren, um überhaupt in einem Projekt mitzuarbeiten. Stattdessen lernen die Contributors gerne dazu, werden für die Entwicklung bezahlt und schätzen die Anerkennung der Kollegen. Ganz abgesehen davon bedienen sie ihr Bedürfnis nach kreativer, herausfordernder Arbeit oder brauchen ganz simpel eine spezifische Funktion oder einen Fix .

Was tun? Hier sind die Autoren einigermassen ratlos: "Bei der Diskussion über Anreize ist es unwahrscheinlich, dass das blosse Anbieten von Geld an die Contributors viel bringt (obwohl dies bei einigen kleineren, unterbesetzten Projekten möglicherweise helfen könnte)."

Man könnte sich eventuell wegbewegen von Sprachen wie C oder C++, oder externe Audits unterstützen. Und statt bestehenden Code zu fixen, könnte man das ganze neu schreiben. Allerdings würden "all diese Bemühungen bestenfalls keinen unmittelbaren sichtbaren Vorteil für die User haben, da sie in der Regel keine unmittelbare funktionelle Verbesserung erkennen werden."

Man solle den Entwicklern grundsätzlich keine neuen Bürden auferlegen. Erfolgsversprechend seien bessere Ausbildung, die Identifikation einflussreicher Security-Befürworter in der Community, die Partnerschaft mit Mentoren-Programmen wie dem "Google Summer of Code". Oder auch viele verschiedene Sicherheitswerkzeuge und automatisierte Tests als Teil der Pipeline für kontinuierliche Integration (continuous integration CI) einzusetzen. "Plattformen wie GitHub und GitLab könnten zudem "nützliche Standardeinstellungen bieten und die Einbindung dieser Werkzeuge und Tests besonders einfach machen."

Zudem müsse man besser verstehen, warum die Entwickler so wenig Interesse an der Security ihrer Software hätten, heisst es weiter (PDF).

Der Bericht beinhaltet auch einen Appell, der in der vorweihnächtlichen Zeit auch in keiner Predigt und in keinem Spendenaufruf fehlt: "Es bedarf einer von der Gemeinschaft angetriebenen Anstrengung, die Einzelpersonen, Unternehmen und Institutionen einschliesst, um sicherzustellen, dass FOSS für zukünftige Generationen sicher und nachhaltig ist." Hach, da öffnet sich einem doch das Herz.