Open Source: Warum offener Code zum Sicherheitsfaktor wird
35 Jahre nach Linux 0.01 ist Open Source längst Teil kritischer IT-Infrastrukturen. Doch mit seiner wachsenden Bedeutung verschiebt sich die Debatte: Nicht mehr nur Kosten und Innovation zählen, sondern Sicherheit, Resilienz und die Frage, wie viel Kontrolle Organisationen über ihre digitale Basis tatsächlich behalten.
Linux begann 1991 als Projekt eines finnischen Studenten. Heute bildet Open-Source-Software (OSS) die Grundlage zahlloser Rechenzentren, Cloud-Plattformen, Unternehmensanwendungen und Internetdienste. Aus der Entwicklerbewegung ist zugleich ein milliardenschwerer Markt entstanden. Spätestens die Übernahme von Red Hat durch IBM für rund 34 Milliarden Dollar im Jahr 2018 zeigte, dass sich mit offenem Code belastbare Geschäftsmodelle aufbauen lassen.
Verkauft wird dabei nicht das exklusive Nutzungsrecht an verborgenem Quellcode. Unternehmen bezahlen für Enterprise-Versionen, Support, Updates, Zertifizierungen, Integration, Betrieb und zusätzliche Funktionen. Gerade diese Offenheit ist jedoch mehr als ein Geschäftsmodell. Sie berührt unmittelbar die Sicherheitsarchitektur moderner IT.
Transparenz ersetzt keine Sicherheit
Der verbreitete Einwand lautet, öffentlich einsehbarer Quellcode erleichtere Angreifern die Suche nach Schwachstellen. Das ist technisch nicht völlig falsch – greift aber zu kurz. Dieselbe Transparenz ermöglicht Anwendern, unabhängigen Experten und Communitys, Implementierungen zu prüfen, Fehler aufzudecken und Sicherheitskorrekturen nachzuvollziehen.
„Offener Quellcode garantiert keine Sicherheit, schafft aber eine wesentliche Voraussetzung für höhere Sicherheit“, sagt Univention-CEO Peter Ganten. Der entscheidende Punkt liegt nicht darin, dass viele Augen automatisch jeden Fehler finden. Sicherheit entsteht erst durch aktive Pflege, Code-Reviews, reproduzierbare Builds, zeitnahe Updates und klare Verantwortlichkeiten.
Open Source kann dabei einen strukturellen Vorteil bieten: Organisationen müssen nicht ausschließlich darauf vertrauen, dass ein Hersteller Schwachstellen intern erkennt, veröffentlicht und behebt. Prüfungen lassen sich unabhängig durchführen.
XZ zeigt Stärke und Schwäche zugleich
Wie wichtig diese Kontrollmöglichkeit sein kann, zeigte 2024 die Manipulation der XZ Utils. Über längere Zeit war versucht worden, Schadcode in das verbreitete Open-Source-Projekt einzuschleusen. Auffälligkeiten wurden schließlich entdeckt, bevor die kompromittierte Version breit ausgerollt werden konnte.
Stackable-Mitgründer Sönke Liebau sieht darin ein Beispiel für die Kontrollmechanismen offener Entwicklung: Die Manipulation sei „an einem Wochenende“ aufgedeckt worden. Zugleich offenbart der Fall ein grundsätzliches Problem moderner Software: Selbst zentrale Komponenten werden teilweise von kleinen Teams oder Einzelpersonen gepflegt, während Tausende Unternehmen sie produktiv einsetzen. Damit rückt die Software Supply Chain in den Mittelpunkt.
Die Lieferkette wird zum Sicherheitsrisiko
Unternehmenssoftware besteht heute selten vollständig aus eigenentwickeltem Code. Anwendungen integrieren Bibliotheken, Frameworks, Container-Images und Pakete aus zahlreichen Quellen. Eine einzige kompromittierte Komponente kann dadurch sehr viele Produkte gleichzeitig betreffen.
Open Source beseitigt dieses Risiko nicht. Entscheidend sind kontrollierte Abhängigkeiten, gepflegte Komponenten und die Fähigkeit, schnell festzustellen, wo eine betroffene Bibliothek eingesetzt wird. Software Bill of Materials (SBOM), signierte Pakete, reproduzierbare Builds und automatisierte Schwachstellenanalysen werden deshalb zunehmend Teil professioneller Sicherheitsarchitekturen.
Transparenz nützt wenig, wenn niemand weiß, welche Komponenten tatsächlich im eigenen Produktivbetrieb stecken.
Sicherheit heißt auch: wechseln können
Sicherheit endet zudem nicht beim Schutz vor Exploits. Resilienz umfasst die Fähigkeit, bei Ausfällen, Strategieänderungen oder wirtschaftlichen Problemen eines Anbieters handlungsfähig zu bleiben.
SUSE-Vertreter Torsten Hallmann nennt deshalb „Innovationsgeschwindigkeit, Resilienz und echte Wahlfreiheit“ als zentrale Argumente für Open Source. Offene Software kann selbst betrieben, angepasst oder von einem anderen Dienstleister weitergeführt werden. Das reduziert Abhängigkeiten von einzelnen Herstellern, deren Preisgestaltung, Produktstrategie und Support.
Rico Barth von KIX Service Software beschreibt Vendor Lock-in entsprechend als langfristiges Risiko. Was kurzfristig bequem erscheine, könne später zu einer Abhängigkeit von Preisen, Roadmaps und Supportentscheidungen führen. Stackable-Mitgründer Liebau spricht deshalb von einer „permanenten Exit-Option“. Für Unternehmen und Behörden kann genau diese Möglichkeit Teil einer Sicherheitsstrategie sein.
Digitale Souveränität wird zur Sicherheitsfrage
Die Debatte um Open Source verlagert sich damit zunehmend von Lizenzkosten zu Kontrolle. Wer Software prüfen, selbst betreiben, verändern oder durch Dritte weiterentwickeln lassen kann, gewinnt Handlungsspielraum.
Das gilt besonders für Behörden, Betreiber kritischer Infrastrukturen und Unternehmen mit sensiblen Daten. Digitale Souveränität bedeutet hier nicht vollständige Unabhängigkeit von externen Anbietern. Gemeint ist vielmehr die Fähigkeit, technische Entscheidungen selbst treffen und Alternativen realistisch nutzen zu können.
KI verschärft die Kontrollfrage
Bei Künstlicher Intelligenz (KI) gewinnt diese Diskussion zusätzlich an Bedeutung. Dort reicht Transparenz beim Quellcode allein nicht aus. Organisationen müssen auch nachvollziehen können, welche Modelle eingesetzt werden, wie Daten verarbeitet werden, wo Systeme laufen und welche externen Dienste eingebunden sind.
Barth fordert deshalb „geprüfte, vertrauenswürdige, gegebenenfalls lokale Umgebungen“. Je sensibler die verarbeiteten Daten und je stärker KI-Systeme in Geschäftsprozesse eingreifen, desto wichtiger werden überprüfbare Modelle, nachvollziehbare Datenflüsse und kontrollierbare Betriebsumgebungen.
35 Jahre nach Linux steht Open Source damit für weit mehr als günstige Software oder Entwicklerfreiheit. Offener Code kann Transparenz, Ausweichmöglichkeiten und unabhängige Kontrolle schaffen. Automatisch sicher ist Open Source deshalb nicht. Sein Sicherheitswert entsteht dort, wo Offenheit mit professionellem Schwachstellenmanagement, abgesicherten Lieferketten und echter technischer Wahlfreiheit verbunden wird.
Newsletter Abonnieren
Abonnieren Sie jetzt IT-SICHERHEIT News und erhalten Sie alle 14 Tage aktuelle News, Fachbeiträge, exklusive Einladungen zu kostenlosen Webinaren und hilfreiche Downloads.
