Vor rund zwei Jahren habe ich hier im Blog eine Diskussion losgetreten. Völlig frustriert von der miesen Qualität diverser Bibliotheken und fehlender Dokumentation habe ich Dampf abgelassen. Die Aussage: “Es ist mir scheißegal, ob Open Source oder nicht.”
Im Bezug auf die aktuellen Geschehnisse um OPENSSL und den #heartbleed Bug muss ich meine Meinung revidieren. Es ist plötzlich wichtig #OPENSOURCEFREE auf das Produkt-Paket gedruckt zu bekommen. Um es klar zu sagen, dies war kein Einzelfall:
- Heartbleed, unentdeckt für ca 2 Jahre, schlimmster Sicherheitsunfall in der Geschichte des Internets
- GnuTLS blieb 10 Jahre unentdeckt
- Eine fehlende Codezeile im Random Number Bug über 2 Jahre
- TCP-32764 Backdoor, dessen Urheber bis heute unklar ist
Damit gilt das oft zitierte Statement als widerlegt. In der Wissenschaft reicht ein Negativbeweis. Die Diskussion über Open Source als Sicherheitsrisiko, speziell im Unternehmenseinsatz, ist über 10 Jahre alt, wird aber von den Verfechtern negiert.
"Weil aber Open Source die Offenlegung des Quellcodes bedeutet, können Anwendungen von allen Nutzern ständig weiterentwickelt werden. Auch Fehler lassen sich so meist schneller beheben."
"Der Vorteil von Open Source: Schadsoftware, Bugs oder Sicherheitslücken können in der Regel schneller entdeckt werden. Es reicht allein der Verdacht, und Tausende von EntwicklerInnen nehmen den betreffenden Code ganz genau unter die Lupe", sagt Grote. Die größere Gefahr bestehe vielmehr in den unfreien Komponenten, etwa proprietären Modemtreibern oder Firmware, die meist von den Herstellern kommen und deren Sicherheit niemand überprüfen kann."
Nun stehen zwei Konzepte gegenüber: Open Source und Closed Source. Warum ich glaube, dass Closed Source die bessere Wahl sein kann:
Kosten
Es wird argumentiert, dass bei Open Source die Lizenzkosten wegfallen. Das Beispiel der Stadt München hat bewiesen, dass man mit mehr finanziellem Aufwand ein qualitativ weniger hochwertiges Ergebnis erreichen kann - bei höherem zeitlichem Aufwand. Open Source kann nur seriös eingesetzt werden, wenn das Know-how und die Ressourcen vorhanden sind, den Code zu pflegen. Niemals kann man sich darauf verlassen, dass jemand für immer und gratis seine Bibliothek weiter pflegt oder das jemand ganz automatisch mit Freude und völlig unentgeltlich diesen Job übernimmt. Persönlich schmerzlich erfahren mit dotnetopenauth.
Sicherheit
Ganz generell gesprochen gibt es keinen schlüssigen Zusammenhang zwischen Sicherheit und Open Source. Ein Vier-Augen-Prinzip erhöht die Sicherheit in jedem Softwareprojekt, allerdings ist es auch ein Leichtes, in ein Open Source-Projekt Programmierer einzuschleusen, die andere Ziele verfolgen. Dabei hat sich gezeigt, dass die Entdeckung von Sicherheitslücken über Parsing Tools und nicht per Code-Analyse erfolgte.
Verantwortung
Der letzte Punkt ist mir erst in den letzten Tagen so richtig klar geworden. Niemand übernimmt die Verantwortung. Gerade in einem Land wie Deutschland, in dem sich jeder gegen jedwede Risken versichert, in dem unglaublicher Aufwand getrieben wird den kleinsten Parksünder dingfest zu machen, kann es sich eigentlich niemand leisten, nicht zu wissen, wer eigentlich Schuld trägt.
Das ist sowohl rechtlich in Fragen der Gewährleistung als auch gesellschaftlich ein unhaltbarer Zustand.
Stellen Sie sich mal vor eine Airline würde Metallteile verbauen, die sie auf der Straße findet. Dann hätten wir nicht nur eine MH370, sondern jeden Tag zehn. Verantwortungslos.
Fazit
Open Source wurde immer durch Gebrauch des englischen Begriffs "free" mit gratis verwechselt. Nachdem dieser Irrtum erwiesen ist und die erheblichen Risiken nicht mehr zu leugnen sind, müsste man folgerichtig ein EU-Verbot fordern. Oder zumindest abschreckende Warnaufdrucke, ähnlich der Zigarettenschachteln. Die werden auch nicht weniger schädlich, wenn man das billige Kraut raucht.
PS: Auch Microsoft hatte seine Sicherheitsgaus - bis vor etwa 10 Jahren (SQLSlammer), danach nicht mehr.