Bevor wir die unzähligen potenziellen Sicherheitsvorteile erläutern, die Freie, Open Source Software (FOSS) hat beziwhungsweise auch nicht hat, wollen wir zunächst die offensichtliche Frage stellen: „Ist Freie, quelloffene Software [immer] sicherer als proprietäre Software?“
Natürlich lautet die Antwort auf diese Frage: „Es kommt darauf an“. Software kann selbstverständlich Fehler und Sicherheitslücken enthalten (und tut dies auch!), egal ob sie Open Source oder proprietär ist. Der Unterschied zwischen beiden Optionen besteht natürlich darin, dass FOSS-Projekte leicht und von allen auf der ganzen Welt überprüft werden können, egal ob es sich um Hobby-Programmierer:innen oder um ein Software-Sicherheitsunternehmen handelt. Im Gegensatz hierzu fällt der Quellcode proprietärer Software in der Regel unter das Geschäftsgeheimnis und kann daher meist nicht eingesehen werden. [1, 2]
Das wirft jedoch die Frage auf, ob allein die Möglichkeit, jederzeit von Tausenden von Menschen überprüft zu werden (unabhängig davon, ob dies tatsächlich geschieht oder nicht), Freie Software sicherer macht als proprietäre Software, bei der der Quellcode von niemandem, auch nicht von potenziellen Angreifern, eingesehen werden kann.
Ist Open Source unsicher? – Nein!
Freie, Open Source Software (FOSS) wird oft als „nette Idee, aber ungeeignet für kritische Infrastrukturen“ bezeichnet, insbesondere von Personen, die nicht in diesem Bereich arbeiten, oder von Interessenvertreter:innen proprietärer Softwareunternehmen. Diese Auffassung war vor einigen Jahren noch deutlicher verbreiteter als heute, ist aber bis heute noch durchaus vorhanden.
So wurde die Bundesregierung 2017 in einer Informationsfreiheitsanfrage (FOI) gefragt, warum bestimmte Bereiche in deutschen Verwaltungen keine Open-Source-Software einsetzen, wo immer dies möglich ist. Dies betrifft insbesondere sicherheits- und datenkritische Verwaltungsbereiche wie Wahlverfahren, das Militär, die amtliche Statistik und Steuerbehörden. In den meisten Fällen folgen die Antworten dem Argument, dass es die Software wahrscheinlich weniger sicher machen würde, wenn sie transparent und offen wäre. [2]
Dieses Argument ist natürlich nicht neu, aber es scheint immer dann, wenn eine neue Sicherheitslücke in weit verbreiteter Open Source Software auftaucht, an Popularität zu gewinnen. Und das ist natürlich auch verständlich, denn viele der berühmten Sicherheitslücken, von denen wir in den Medien hören, scheinen solche Open Source Softwarebibliotheken zu betreffen, wie beispielsweise der Heartbleed-Bug in OpenSSL im Jahr 2014, eine kritische Privilegieneskalation im Linux-Kernel im Jahr 2016 oder die Log4Shell-Sicherheitslücke vor wenigen Monaten.
Es liegt also auf der Hand, dass Fragen zur Sicherheit von Freier, Open Source Software immer wieder auftauchen. Dies liegt insbesondere auch daran, dass einige grundlegende Konzepte der heutigen digitale Infrastruktur sowie allgemeine IT-Sicherheitskonzepte in der Öffentlichkeit missverstanden zu werden scheinen. Nachweislich unsichere Konzepte, wie zum Beispiel die Idee der „Sicherheit durch Obskurität“ sind im Allgemeinverständnis leider immer noch weit verbreitet. Stattdessen sollte Softwaresicherheit in erster Linie aus sauberem, intensiv getesteten und umfassend geprüften Code sowie einer gesunden Entwicklungs- und Diskussionsumgebung mit entsprechender Fehlerkultur entstehen. [4, 5]
Wann ist Open Source sicher und was ist es das nicht?
Es wäre eine unvollständige Aussage, zu behaupten, dass die Lizenz eines Softwareprojekts allein es von Natur aus sicherer machen würde. Wie bereits zuvir angesprochen enthält jede Software Fehler und Sicherheitslücken. Der (theoretische) Vorteil, den Freie, Open Source Software gegenüber proprietären Lösungen hat, liegt in der Entwicklungskultur, die hinter solchen FOSS-Lizenzen steht.
An dieser Stelle bietet es sich an zu erklären, wie Code-Beiträge in Open Source Projekten normalerweise funktionieren: In der Regel sind Open Source Projekte mehr als glücklich darüber, Beiträge von Entwickler:innen außerhalb des Kernprojektteams zu erhalten und haben genau aus diesem Grund einfach verständliche Beitragsrichtlinien verfasst. Sie umreißen die Schritte, die beim Hinzufügen oder dem Ändern von Code unternommen werden müssen, so dass die Beiträge leicht von Administrator:innen des Projekts überprüft werden können. Oft enthalten die Richtlinien auch bevorzugte Kodierungsstile, alle zu beachtenden Vorsichtsmaßnahmen und wie automatische Tests auf neue Änderungen anzuwenden sind. Wie der Code selbst sind auch die vorgeschlagenen Änderungen in der Regel für alle einsehbar und können von öffentlich diskutiert werden. Dies schafft Raum und eine Plattform für den Austausch und die Verbesserung nicht nur der Codebasis, sondern auch der Fähigkeiten der (neuen) Entwickler:innen. [6]
Die völlige Offenheit fördert eine Kultur, in der sauberer Code geschrieben und weniger „faule“ Abkürzungen genommen werden, welche potenziell Angriffsflächen bieten könnten. Außerdem haben „viele Augen“ auf der Codebasis das Potenzial, Sicherheitsprobleme und Fehler im Allgemeinen viel schneller zu beheben, als dies der Fall wäre, wenn die Software auf undurchsichtige Weise (proprietär) entwickelt würde, wobei bestenfalls eine Handvoll Entwickler:innen sie durchsehen würde. Ähnlich wie bei den Datenschutzversprechen der Hersteller:innen proprietärer Software müsste man auch bei der Sicherheit proprietärer Software ihnen naiv glauben. Bei Freier, Open Source Software ist dies schlicht nicht der Fall, da der Code jederzeit von Dritten überprüft werden kann. So ist es nicht verwunderlich, dass viele Hersteller:innen proprietärer Software, wie z.B. Google, inzwischen einen „Open Core“-Ansatz verfolgen und im Grunde genommen die Vorteile von Open Source Software (auch in Bezug auf die Sicherheit) ausnutzen, ohne zur FOSS-Gemeinschaft insgesamt beizutragen. [7]
Die jüngsten Debatten über die berüchtigte Log4Shell-Sicherheitslücke haben jedoch erneut ein damit zusammenhängendes Problem der so genannten Software-Lieferketten aufgeworfen. Das Problem beschreibt die Tatsache, dass sich ein großer Teil unserer modernen IT-Infrastruktur, sei es FOSS oder proprietär, auf Softwareteile stützt, um die sich nur wenige Menschen kümmern oder beitragen. Damit entfällt das Argument der „vielen Augen“ und es verbleiben einige scheinbar willkürliche Softwarebibliotheken, an denen nur eine kleine Gruppe oder sogar nur ein einzelne Entwickler:innen jahrzehntelang in der Freizeit arbeiten, während sich riesige kommerzielle Softwareprojekte darauf stützen, ohne jemals dazu beigetragen zu haben oder sie zu überprüfen. Für diejenigen, die visuelle Darstellungen mögen, fasst der Comic XKCD 2347 das Problem präzise zusammen. [8]
Lizensiert unter CC by-nc 2.5.
Software-Lieferketten sind jedoch kein spezifisches Problem von Open Source, da so gut wie jede Software auf einer Vielzahl verschiedener professioneller und auch auf weniger gepflegter Projekte beruht, insbesondere im Web- und Cloud-basierten Bereich. Bei der Lieferkettenproblematik geht es daher eher darum, sicherzustellen, dass alle Teile eines Softwareprojekts gut gepflegt und aktiv weiterentwickelt werden. Dies ist wiederum viel transparenter, wenn sowohl die Projekte in der Lieferkette als auch das Hauptprojekt aus Open Source Software bestehen. Zumindest bei diesen FOSS-Projekten besteht dann die Möglichkeit, dass Nutzer:innen und Dritte offen und öffentlich über solche Probleme berichten können und alle sehen können, wie das Projekt darauf reagiert. [8]
Was sagt die empirische Forschung?
Die Frage zur Softwaresicherheit wird in der wissenschaftlichen Forschung seit Jahrzehnten breit diskutiert. Schon recht früh qualifizierte sich das Konzept des „Open Source Paradigmas für Sicherheit durch Transparenz“ in vielen Fällen als valides Sicherheitsmodell in der Softwareentwicklung. Es bestätigte die bisherigen Vermutungen, dass die Sicherheit von Software immer dann verbessert werden kann, wenn sie transparent gestaltet ist, d.h. wenn die Sicherheitsverfahren so gestaltet sind, dass sie auch dann funktionieren, wenn sie im Detail für alle nachvollziehbar sind. [9]
Als einschränkender Faktor ist es wichtig zu verstehen, dass die undurchsichtige Natur proprietärer Software sich auch in der Offenlegung bestehender Sicherheitslücken manifestieren kann, was bedeutet, dass es für Freie Software-Projekte unvermeidlich ist, Sicherheitslücken öffentlich zu machen, während proprietäre Software-Anbietende sich dafür entscheiden können, sie im einfach Stillen zu beheben (oder eben nicht…). In ähnlicher Weise merken Wissenschaftler:innen an, dass Transparenz nur dann zu mehr Sicherheit führen kann, wenn die Gemeinschaft um ein solches Projekt eine kritische Masse erreicht, bei der öffentliche Audits („viele Augen“) ein realistisches Szenario sind. [9, 10]
Dieses Problem besteht vor allem deshalb, weil die Entdeckung und Offenlegung von Sicherheitslücken, wie auch die übrige Entwicklungsarbeit im Rahmen von Open Source Projekten, oft öffentlich stattfindet. Dies verschafft Angreifer:innen ein potenzielles Zeitfenster, in dem sie schnell agieren können, solange die Schwachstelle nicht behoben ist und (was noch wichtiger ist) bevor die Software-Nutzenden entsprechende Sicherheits-Patches installiert haben. Empirische Untersuchungen ergeben, dass Open Source Projekte zwar im Durchschnitt etwas weniger kritische Sicherheitsprobleme aufweisen, diese früher finden und viel schneller beheben als ihre proprietären Pendants, dass aber Software-Nutzer:innen möglicherweise einem etwas höheren Risiko ausgesetzt sind, wenn sie nicht rechtzeitig Sicherheitsupdates einspielen. Dies basiert allerdings auf der Annahme, dass das Wissen um eine Sicherheitslücke Angreifer:innen die Möglichkeit gibt, diese auch praktisch auszunutzen, was widerum eine umstrittene und immer noch stark diskutierte Hypothese ist. [11, 12]
Um hier Abhilfe zu schaffen, sind viele größere Open Source Projekte dazu übergegangen, Schwachstellen (vorübergehend) nicht öffentlich bekannt zu geben, bis entsprechende Sicherheitsupdates zur Verfügung stehen. Das bedeutet also, dass potenzielle Sicherheitsprobleme nur einem internen Entwickler:innen-Kernteam mitgeteilt und erst dann veröffentlicht werden, sobald entsprechende Sicherheitsupdates verfügbar sind. Insbesondere bei unternehmenskritischen, kommerziellen Open Source Projekten wird die Kundschaft dabei vor der Öffentlichkeit informiert, um ihnen Zeit zu geben, die Sicherheitspatches zu installieren. [13]
Zusammenfassung
Die Verwendung von Freier Open Source Software eröffnet das Potenzial für bessere Entwicklungspraktiken und eine höhere Gesamtqualität des Codes sowie der Sicherheit. Die Argumente für und gegen die Sicherheit von Open Source werden in einer hitzigen Debatte diskutiert und folgen oft einer Art Hype-Dynamik, die behauptet, dass Open Source entweder von Natur aus „kugelsicher“ ist oder ein komplettes Sicherheitsdesaster darstellen würde.
Natürlich spiegeln beide Seiten in ihrer Absolutheit nicht die Realität wider. Wissenschaftliche Untersuchungen ergeben, dass Freie, Open Source Software sowohl theoretisch als auch praktisch viele Sicherheitsvorteile bieten kann, allerdings nur unter bestimmten Bedingungen. Freie Open Source Software ist per sé weder mehr noch weniger sicher, aber sie hat das Potenzial, transparenter und sicherer zu sein, wenn sie sorgfältig eingesetzt wird.
Zum einen ist die Software-Lieferkette sowohl für Open Source als auch für proprietäre Softwareprojekte ein großes Problem, das angegangen werden muss. Für die Nutzer:innen bedeutet dies, dass sie über den Entwicklungs- und Wartungsstatus der von ihnen verwendeten Software sowie über deren Abhängigkeiten informiert werden müssen. Dies gilt sowohl für Freie als auch für unfreie Software.
Zweitens muss die Open-Source-Gemeinschaft erkennen, dass eine vorübergehende Geheimhaltung von Vorteil sein kann, wenn es um die Offenlegung von Schwachstellen geht, ohne dabei ihren transparenten Charakter zu verraten. Viele sicherheitskritische Projekte haben in den letzten zwei Jahrzehnten Maßnahmen in dieser Richtung ergriffen und bitten darum, dass Schwachstellen über sichere Kanäle direkt an das Hauptentwicklungsteam gemeldet werden. Auf diese Weise gemeldete Schwachstellen werden in der Regel innerhalb weniger Stunden oder Tage behoben und entsprechende Sicherheitsupdates für alle verfügbar gemacht, bevor diese Probleme vollumfänglich öffentlich bekannt gemacht werden. Dies fördert sowohl ein Vertrauensverhältnis als auch einen vernünftigen Umgang mit Sicherheitsvorfällen zwischen Entwickler:innen und Softwarenutzenden.
Alles in allem macht eine Lizenz eine Software natürlich nicht per sé sicherer oder unsicherer. Es hängt immer von der Leidenschaft der Softwareentwickler:innen und der Menge an Expert:innen ab, die sich um ein Projekt kümmern. Freie, Open Source Software (FOSS) ist jedoch ausgesprochen offen und transparent, was die Entwicklung und die Sicherheitsmaßnahmen angeht, wohingegen die Nutzenden bei proprietärer Software den Anbieter:innen vertrauen müssen, was den Status und den Aufwand betrifft, der in eine bestimmte Softwareveröffentlichung einfließt. Es ist daher davon auszugehen, dass FOSS durch die inherente Transparenz einen theoretischen und praktischen Vorteil gegenüber proprietärer Software hat, nicht nur in Bezug auf den Schutz der Privatsphäre (was allgemeiner Konsens ist), sondern auch, wenn es um Software- und Datensicherheit geht.
Quellen
- Wilander J. (2021): Is Open Source More Secure Than Cloused Source? Online unter https://devops.com/is-open-source-more-secure-than-closed-source/
- Vlad V., Maryna Z. (2021): Three Myths Debunked About Open Source Software Security. Online unter https://rubygarage.org/blog/open-source-software-security
- Deutsche Bundesregierung (2017): Antwort der Bundesregierung auf die Kleine Anfrage der Abgeordneten Dr. Konstantin von Notz, Renate Künast, Tabea Rößner, weiterer Abgeordneter und der Fraktion BÜNDNIS 90/DIE GRÜNEN. Drucksache 18/12471. Online unter https://dserver.bundestag.de/btd/18/129/1812906.pdf
- Scarfone K., Jansen W. & Tracy M. (2008): Guide to General Server Security. National Institute of Standards and Technology. URL: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf
- King B. (2017): Is Security Through Obscurity Safer Than Open Source Software?. Online unter https://www.makeuseof.com/tag/security-obscurity-open-source-better/
- Nextcloud-Team (2022): Nextcloud developer documentation. URL: https://docs.nextcloud.com/server/latest/developer_manual/
- Das A. (2021): Is Open-Source Software Secure? Online unter https://news.itsfoss.com/open-source-software-security/
- Walker J. M. (2016): Open source and the software supply chain. Online unter https://opensource.com/article/16/12/open-source-software-supply-chain
- Swire P. (2004): A Model for When Disclosure Helps Security: What Is Different About Computer and Network Security? Journal on Telecommunications and High Technology Law 163(3). URL: http://dx.doi.org/10.2139/ssrn.531782
- Swire P. (2006): A Theory of Disclosure for Security and Competitive Reasons: Open Source, Proprietary Software, and Government Agencies. Houston Law Review 101), Ohio State Public Law Working Paper No. 49, URL: https://ssrn.com/abstract=842228
- Ransbotham S. (2010): An Empirical Analysis of Exploitation Attempts based on Vulnerabilities in Open Source Software. Workshop on the Economics of Information Security. URL: https://infosecon.net/workshop/downloads/2010/pdf/An_Empirical_Analysis_of_Exploitation_Attempts_based_on_Vulnerabilities_in_Open_Source_Software.pdf
- Schryen G. (2009). Security of Open Source and Closed Source Software: An Empirical Comparison of Published Vulnerabilities. AMCIS. URL: https://www.semanticscholar.org/paper/Security-of-Open-Source-and-Closed-Source-Software%3A-Schryen/fde3ba053cede0e7fde6e220d6d09e42638421d5
- Zahedi M., Babar M., Treude C. (2018): An Empirical Study of Security Issues Posted in Open Source Projects. Hawaii International Conference on System Sciences (HICSS). URL: https://www.academia.edu/35153562/An_Empirical_Study_of_Security_Issues_Posted_in_Open_Source_Projects
Jan ist Mitgründer von ViOffice. Er kümmert sich insbesondere um die technische Umsetzung und Wartung der Software. Seine Interessen liegen insbesondere in den Themengebieten Sicherheit, Datenschutz und Verschlüsselung.
Neben seinem Studium der Volkswirtschaftslehre, später der angewandten Statistik und seiner daran anknüpfenden Promotion, hat er jahrelange Erfahrung im Bereich Softwareentwicklung, Opensource und Serveradministration.