Metastudie zur Sicherheit von Software – Stand 2023 Proprietäre vs. Open-Source-Software

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Insider Research

Quelloffener oder geschlossener Code – was bringt mehr Sicherheit? Eine aktuelle Metastudie der Open Source Business Alliance gibt Antworten, nimmt der Ausgangsfrage aber schon eingangs ihre Relevanz.

Die Open Source Business Alliance (OSBA) hat kürzlich eine interessante Studie unter dem Titel „Studie zum Vergleich der Sicherheit von Open-Source-Software und proprietärer Software“ veröffentlicht (Dev-Insider berichtete). Die OSBA-Auftragsarbeit wurde an der Rheinischen Friedrich-Wilhelms-Universität Bonn erarbeitet.

Bezüglich des Konkurrenzkampfs der beiden Modelle kommt die Studie gleich zu Beginn zu einer interessanten Erkenntnis: „Heute gibt es diesen Dualismus nicht mehr […]“. Und doch wird sich am Ende eine gewisse Präferenz von Open Source abzeichnen. Die Studie teilt sich in drei große Bereiche: Der Vergleich der beiden Entwicklungsmodelle, Best Practices für die Entwicklung sowie Qualitätsmetriken für die Beurteilung von Projekten.

Vergleich der Modelle

Open-Source-Software auf der einen, proprietäre Anwendungen auf der andern Seite – lange Zeit scheinbar unvereinbare Gegensätze, die sich feindlich gegenüberstanden. Und so beginnt die Studie auch damit, zunächst beide Lager auf dieser Basis miteinander zu vergleichen, wohl wissend, dass es sich bei vielen traditionellen Argumenten für das eine oder andere Lager um Meinungen, Bauchgefühle, subjektive Urteile handelt.

So sieht die OSBA-Metastudie in den untersuchten Quellen etwa die üblichen Argumente pro Open Source, wie zum Beispiel schnellere Behebung von Bugs, eigene Bug-Fixes, die generelle Transparenz oder erhöhte digitale Souveränität und somit geringere Gefahren für Vendor-Lock-ins. Auf der anderen Seite scheinen auch die altbekannten Argumente gegen Open Source sehr lebendig, beispielsweise Tendenzen zu schlechtem/fehlendem Support oder dürftiger Dokumentation.

Für proprietäre Software spräche nach wie vor, dass Änderungen am Code nicht von jedermann, sondern nur von autorisierten Personen durchgeführt werden können, rechtliche Sicherheit und planbare Kosten für Support, Anpassungen und so weiter. Dazu werden einige konkrete Kontroversen aufgegriffen.

Bezüglich der Kosten sei zum Beispiel festzuhalten, dass Kostenersparnis zwar bei Open-Source-Nutzern hoch im Kurs stehen, die tatsächlichen Lifecycle-Kosten jedoch durchaus ebenbürtig ausfallen können, durch nötiges Personal, Individualisierungen, Schulungen etc.

Bezüglich der Einstellung von Projekten wird vermerkt, dass auch Open-Source-Projekte eingestellt, dann jedoch gegebenenfalls übernommen oder geforkt und weitergeführt werden können. Als wichtiger Aspekt zur Mitigation werden aber vor allem offene Standards erwähnt, die eine Übernahme in andere Produkte ermöglichen/vereinfachen.

Vor- und Nachteile von Transparenz

Hier soll es aber vor allem um die Sicherheit gehen. Open-Source-Kritiker bemängelten stets insbesondere, dass in frei verfügbarem Code Änderungen von Unbekannten gemacht werden könnten. Dem wird entgegengestellt, dass die eigentlichen Entwickler bei proprietärer Software generell unbekannt seien. Und, dass Empfehlungen zur Qualitätssicherung für Open-Source-Projekte ebenso gelten würden.

Sogar darüber hinaus wurde offen liegender Code seit jeher dafür kritisiert, dass jeder Angreifer nach potenziellen Schwachstellen Ausschau halten könne. Auch hier legt die Studie dar, dass die Möglichkeit des Quellstudiums viel eher dazu führt, dass Fehler und Probleme gefunden werden.

Der wirklich interessante Punkt, der hier aufgeworfen wird, ist aber ein anderer: „Ohne Einblick in den Quelltext kann die Sicherheit einer Software niemals sichergestellt werden.“ Abseits von zer­tifizierungs­relevanten Bereichen seien Sicherheitsversprechen in der Regel lediglich hersteller­seitige Selbsterklärungen.

Aufgrund eben dieser Transparenz offener Projekte, „[…] bewertet das Bundesamt für Sicherheit in der Informationstechnik (BSI), Open-Source-Software als mindestens genauso sicher wie proprietäre Software.“ Dabei geht es eben nicht um die eigentliche Entwicklung, sondern um die Überprüfbarkeit: „Das Entwicklungsmodell an sich erlaubt keine Aussage über die Sicherheit. Bei Open-Source-Software ist die Implementierung jedoch für jeden prüfbar.“

Diesen Punkt sollte man allerdings ergänzen: In der Praxis werden freilich auch für proprietäre Code-Basen Code-Reviews und -Audits von Dritten durchgeführt, wenn es beispielsweise um Zertifizierungen für den Einsatz in kritischen Bereichen geht. Gegen entsprechende Ver­schwie­gen­heits­ver­ein­bar­ungen wird der Code dann den Auditoren übergeben. Die gleiche Transparenz wie bei Open Source entsteht so natürlich dennoch nicht annähernd – wieder ist (blindes) Vertrauen in die prüfende Einrichtung Voraussetzung.

Unter dem Stichwort „Synergien“ führt der Autor den Leser dann noch zum eingangs zitierten fehlenden Dualismus: Stand heute sei „ […] proprietäre Software zunehmend und in hohem Maße von Open-Source-Software durchdrungen […].“ Typischerweise wird Open Source als Basis genutzt und um Markenkennzeichnungen, eigenes Design, patentierte Funktionen und generell Features ergänzt, die in ihrer Gesamtheit überhaupt erst zu einem Alleinstellungsmerkmal führen. Als Beispiel wird später etwa Chromium aufgeführt, das als Basis für Microsoft Edge und ebenso Google Chromium dient.

Im Grunde kommt die Studie zu dem Schluss, dass sich die Frage nach dem sichereren Entwicklungsmodell im Sinne von „Open source vs. Proprietär“ gar nicht mehr stelle. Greifen wir das Eingangszitat nochmal auf, wird es klar:

„Heute gibt es diesen Dualismus nicht mehr, denn weit über 90% aller Software enthält Open Source - auch die proprietären Produkte. Die Sicherheit von Open Source betrifft daher heute alle Softwarehersteller und Anwender. Wenn wir Sicherheit wollen, müssen wir sie überprüfen können. Auch hier müssen sich alle Softwareprodukte den gleichen Herausforderungen stellen.“

Das Entwicklungsmodell „Open Source“ führt demnach also nicht per se zu sichererer Software – allerdings lässt sich nur deren Sicherheit wirklich prüfen. Bleibt die Frage, wie sich die Qualität inklusive Sicherheit einer offenen Software feststellen lässt.

Best Practices

Im Abschnitt zu den Best Practices führt das OSBA-Papier vor allem einige Projekte auf, die Empfehlungen für den Entwicklungsprozess geben. Zunächst findet hier das Secure Software Development Framework (SSDF) des NIST Erwähnung, ein abstraktes Rahmenwerk, für dessen Umsetzung folgend diverse Werkzeuge empfohlen werden.

Abgestellt wird hier auf die Open Source Security Foundation (OpenSSF) für die Organisation von Projekten, Supply Chain Levels for Software Artifacts (SLSA) für die Absicherung der Supply Chain und den 26-Punkte-Plan für Entwickler „Best Practices for Open Source Developers“ (ebenfalls OpenSSF).

Schlussendlich werden konkrete Tools für eine sichere Entwicklung empfohlen, beispielsweise Detektoren für Authentifizierungsdaten wie Passwörter oder SBOM-Generatoren.

Qualitätsmetriken

Die Feststellung, dass sich die Sicherheit einer Software nicht allein am Entwicklungsmodell festmachen lässt, ist eine Erkenntnis. Im letzten Kapitel zitiert der Autor zunächst kurz einige Studien zum Thema Software-Bewertung und führt anschließend konkrete „Eigenschaften und Messgrößen gesunder Open Source-Projekte und Open Source-Ökosysteme“ auf.

Diese sind dem Paper „Open Source als Innovationstreiber für Industrie 4.0“ der Deutschen Akademie der Technikwissenschaften entnommen. Die Kriterien in aller Kürze: Unter „Vitalität & Lebendigkeit“ fallen Werte wie Anzahl der Commits, Anzahl eingereichter/bearbeiteter Tickets, Menge der Committer, Entwicklungsgeschwindigkeit, Alter des Projekts, Sponsoren und so weiter.

Unter „Strukturiertheit & Qualität“ finden sich qualitative Kriterien wie die Qualität der Dokumentation, das Entwicklungsmodell oder die Gesamtdarstellung der Organisation. Hinzu kommen quantitative Aspekte wie Code-Qualität, durchgeführte Tests, Optimierungen und so weiter.

In der dritten Kategorie „Community & Ökosystem“ geht es um Merkmale wie die Diversität innerhalb des Projekts (etwa bezüglich teilnehmender Nationen und Sprachen), Quantität und Qualität der Kommunikation, Fragen rund um die Lizenzierung und Rahmenbedingungen wie ein Verhaltenskodex, Inklusion oder Führungsstandards.

Abschließend werden drei Tools empfohlen, die bei der Erfassung und Bewertung der aufgeführten Metriken helfen sollen: Fossstars von SAP, Community Health Analytics in Open Source Software (CHAOSS) von der Linux Foundation sowie die OpenSSF Scorecard.

Wir nehmen mit: Die OSBA-Studie kommt insbesondere zu zwei Schlüssen. Zum einen, dass sich die Frage nach Sicherheit kaum nur anhand des Entwicklungsmodells beantworten lässt – und sich in der Form sowieso kaum noch stellt, da proprietäre Produkte meist auch freien Code enthalten. Zum anderen, dass nur Open-Source-Modell die Möglichkeit bietet, Sicherheit wirklich zu überprüfen.

Als tendenziell bestes Modell sieht der Autor übrigens kommerzielle Open-Source-Software, die sowohl mit Transparenz als auch mit rechtlicher Sicherheit und Support auf Herstellerlevel punkten kann.

(ID:49677970)