Wir haben diese Frage einmal gehört, und sie ist uns im Kopf geblieben. Nicht, weil es eine schlechte Frage war, sondern weil die Annahmen dahinter so weit verbreitet und so falsch waren, dass sie eine vollständige und ehrliche Antwort verdienten.

Das ist diese Antwort.

Wenn Sie in Finanzdienstleistungen, im Gesundheitswesen, in der Rechtsbranche oder in einem anderen regulierten Sektor arbeiten und jemand in Ihrer Organisation gefragt hat, ob Open Source sicher genug ist, um unternehmenskritische Infrastruktur zu betreiben, dann ist dieser Beitrag für Sie geschrieben. Wir werden eine klare These vertreten: Open-Source-Software ist für regulierte Branchen nicht bloß „sicher genug“. Im Jahr 2026 ist sie die einzige Architektur, die das erfüllen kann, was moderne Regulierung tatsächlich verlangt.

Der Mythos im Zentrum der Frage

Der Einwand gegen Open Source in regulierten Umgebungen beruht fast immer auf einem einzigen, intuitiven Glauben: proprietäre Software müsse sicherer sein, weil Angreifer den Code nicht sehen können.

Das nennt man Sicherheit durch Geheimhaltung. Es ist eine der ältesten Ideen in der Kryptografie. Und sie wurde vor mehr als 140 Jahren endgültig ausgemustert.

Im Jahr 1883 veröffentlichte der niederländische Kryptograf Auguste Kerckhoffs eine Reihe von Prinzipien für die militärische Kryptografie. Das dauerhafteste davon besagt, dass ein System sicher bleiben sollte, selbst wenn alles daran außer dem Schlüssel öffentlich bekannt ist. Der amerikanische Mathematiker Claude Shannon formulierte dieselbe Idee später noch knapper: „der Feind kennt das System.“

Die Logik ist einfach. Wenn Ihre Sicherheit davon abhängt, dass Angreifer nicht wissen, wie Ihr System funktioniert, wetten Sie darauf, dass es nie jemand durchsickern lässt, zurückentwickelt oder eine Schwachstelle findet, die Sie übersehen haben. Diese Wette ist in der Öffentlichkeit jedes einzelne Mal verloren gegangen, wenn sie in großem Maßstab eingegangen wurde. Von DVD-Verschlüsselung über Steuergeräte in Autos bis hin zu proprietären Netzwerkprotokollen ist die Geschichte des Rechnens eine Geschichte davon, dass Geheimhaltung in dem Moment versagt, in dem ein kompetenter Angreifer beschließt, genauer hinzusehen.

Das ist für regulierte Branchen wichtig, weil die Alternative nicht lautet: „Open Source hat einzigartige Risiken.“ Die Alternative lautet nachweisbare Sicherheit. Und nachweisbare Sicherheit ist etwas, das nur Open Source liefern kann.

Was „Closed Source“ in der Praxis tatsächlich bedeutet

Wenn eine regulierte Organisation proprietäre Software kauft, dann kauft sie in Wahrheit Folgendes:

Sie kauft die Behauptung des Anbieters, dass die Software sicher ist. Sie kauft die Behauptung des Anbieters, dass es keine Hintertüren gibt. Sie kauft die Behauptung des Anbieters, dass Schwachstellen zeitnah offengelegt werden. Sie kauft die Behauptung des Anbieters, dass die Software tut, was sie verspricht, und nichts anderes.

Der Auditor des Käufers kann keine dieser Behauptungen unabhängig verifizieren. Der CISO des Käufers kann den Code nicht lesen, um zu bestätigen, dass das Sicherheitsmodell trägt. Der Regulator des Käufers kann einen SOC-2-Bericht anfordern, aber ein SOC-2-Bericht ist selbst eine Verifikation der Prozesse des Anbieters, nicht des Verhaltens der Software. Am Ende der Kette setzt die regulierte Einheit ihren Namen unter einen Stapel von Zusicherungen, die sie von Natur aus nicht verifizieren kann.

Das ist kein kleines Verfahrensproblem. Nach dem Digital Operational Resilience Act (DORA), der im Januar 2025 in der gesamten Europäischen Union zur Anwendung kam, bleiben Finanzunternehmen voll verantwortlich für die Einhaltung aller Verpflichtungen aus der Verordnung, selbst wenn IKT-Dienstleistungen von Dritten erbracht werden. Die Verordnung verlangt ausdrücklich, dass Unternehmen ein ganzheitliches Verständnis ihrer IKT-Anbieterabhängigkeiten aufrechterhalten, einschließlich dokumentierter Ausstiegsstrategien für kritische Dienste und der Fähigkeit, bei Bedarf den Anbieter zu wechseln.

Wenn Ihre kritische KI-Infrastruktur proprietär ist, liegt Ihre Ausstiegsstrategie nicht in Ihrer Kontrolle. Ihr Verständnis des Systems ist nicht architektonisch, sondern vertraglich. Und wenn ein Regulator Sie bittet, nachzuweisen, dass sich das System wie erwartet verhält, lautet Ihre Antwort: Der Anbieter hat es uns gesagt.

Das ist keine Gewährleistung. Das ist Delegation.

Was Open Source tatsächlich verändert

Open-Source-Software kehrt jeden dieser Punkte um.

Ihr Sicherheitsteam kann die Codebasis vor der Bereitstellung lesen, statt eine NDA zu unterschreiben und die Behauptungen des Anbieters zu akzeptieren. Ihr Auditor kann verifizieren, dass das in Produktion laufende Binärprogramm aus dem geprüften Quellcode gebaut wurde, mithilfe reproduzierbarer Builds. Ihr CISO kann einen konkreten Commit-Hash festlegen und auf Abruf genau nachweisen, was zu einem bestimmten Zeitpunkt in Ihrer Infrastruktur läuft.

Wenn eine Sicherheitslücke offengelegt wird, warten Sie nicht darauf, dass der Anbieter in seinem nächsten Release-Zyklus einen Patch einplant. Sie können die Behebung sehen, während sie entwickelt wird, sie für Ihren eigenen Kontext bewerten und nach Ihrem eigenen Zeitplan einspielen.

Wenn der Anbieter pleitegeht, übernommen wird, sein Preismodell ändert oder beschließt, das Produkt einzustellen, betrifft Sie das alles nicht. Die Lizenz, unter der Sie die Software erhalten haben, sei es Apache 2.0, MIT oder eine andere anerkannte Open-Source-Lizenz, kann nicht widerrufen werden. Der Code gehört Ihnen, um ihn so lange zu behalten, zu forken, zu verändern und zu betreiben, wie Sie ihn brauchen.

Das sind keine Wunschvorstellungen. Das sind Eigenschaften der Software selbst, bei Bedarf gerichtlich durchsetzbar und auf Abruf verifizierbar. Es sind genau jene Eigenschaften, nach denen Aufsichtsbehörden in den letzten fünf Jahren in immer eindeutigeren Worten gefragt haben.

Die Frage nach der Patch-Geschwindigkeit

Eines der häufigsten Gegenargumente gegen Open Source ist, dass „mehr Augen“ nicht automatisch bessere Sicherheit bedeuten. Das Argument lautet: Wenn der Code öffentlich ist, können Angreifer ihn ebenfalls lesen, und sie werden Schwachstellen zuerst finden.

Das klingt plausibel. Die Daten stützen es nicht.

Empirische Forschung zum Patch-Verhalten von Anbietern, darunter Studien an der Carnegie Mellon, hat konsistent zwei Dinge gezeigt. Erstens beheben Open-Source-Anbieter Schwachstellen im Durchschnitt schneller als proprietäre Anbieter. Zweitens werden Schwachstellen nach öffentlicher Offenlegung wesentlich häufiger behoben als davor, wobei eine viel zitierte Studie den Anstieg mit 137 Prozent beziffert.

Der Grund dafür ist strukturell und nicht philosophisch. Wenn eine Schwachstelle in einem Open-Source-Projekt öffentlich offengelegt wird, wird die Behebung öffentlich entwickelt, öffentlich geprüft und öffentlich ausgeliefert. Die Offenlegung selbst erzeugt Druck, schnell zu patchen. In proprietären Projekten kann dieselbe Offenlegung wochen- oder monatelang in einem privaten Bug-Tracker stehen, bevor ein Patch ausgeliefert wird, ohne externe Sicht auf den Zeitplan.

Das ist für regulierte Branchen keine hypothetische Sorge. DORA verlangt von Finanzunternehmen, einen IKT-bezogenen Vorfallmanagement-Prozess zu implementieren, der Vorfälle identifiziert, verfolgt, protokolliert und kategorisiert. Es verlangt, dass alle kritischen Werkzeuge und Anwendungen mindestens jährlich getestet werden. Es verlangt, dass Schwachstellen, Mängel und Lücken umgehend identifiziert, gemindert und beseitigt werden. Open-Source-Software macht es Ihnen durch die Sicht auf den tatsächlichen Stand von Patches und Schwachstellen erheblich leichter, diese Pflichten zu erfüllen.

Es lohnt sich auch, zu benennen, worauf regulierte Branchen bereits laufen. Die Infrastruktur des europäischen Bankwesens basiert auf Linux. Die Transaktionsdatenbanken europäischer Versicherer basieren auf PostgreSQL. Die Orchestrierungsschicht europäischer Krankenhausnetzwerke basiert auf Kubernetes. All das ist Open Source. All das wurde von allen relevanten Aufsichtsbehörden als sicher genug eingestuft, um Daten zu verarbeiten, die weit sensibler sind als die durchschnittliche KI-Workload. Das Argument, Open Source sei für regulierte Branchen nicht sicher, ist im Jahr 2026 ein Argument gegen die gelebte Realität dieser Branchen.

Was moderne Regulierung tatsächlich verlangt

Wenn man DORA, den EU-KI-Act, die FINMA-Rundschreiben zum Outsourcing und die verschiedenen bereichsspezifischen Leitlinien von BaFin, FCA und anderen europäischen Aufsichtsbehörden nacheinander liest, zeigt sich ein Muster. Moderne Regulierung fragt nicht mehr, ob Ihre Systeme sicher sind. Sie fragt, ob Sie nachweisen können, dass sie sicher sind, und ob Sie weiterbetrieben werden können, wenn etwas schiefgeht.

Die konkreten Anforderungen variieren je nach Regulierung, aber die architektonischen Prinzipien laufen zusammen:

Prüfbarkeit. Sie müssen einem Regulator genau zeigen können, was Ihre Systeme tun. Sie müssen Entscheidungen nachträglich rekonstruieren können. Der EU-KI-Act verlangt das insbesondere für KI-Systeme mit hohem Risiko, mit konkreten Vorgaben zu Protokollierung, Nachvollziehbarkeit und nachträglicher Erklärbarkeit.

Minderung von Vendor Lock-in. Sie müssen eine dokumentierte Ausstiegsstrategie für kritische IKT-Dienste haben. Sie müssen bei Bedarf den Anbieter wechseln können. DORA Artikel 28 macht das ausdrücklich. Die Auslagerungsanforderungen der FINMA tun dies seit 2018.

Kontinuität unter Belastung. Sie müssen unter den Bedingungen eines Lieferantenausfalls, geopolitischer Störungen oder regulatorischer Änderungen in einer Drittstaatenjurisdiktion weiterarbeiten können. Die letzten Jahre haben deutlich gemacht, dass extraterritoriale Sanktionen und Executive Orders den Zugriff auf cloudbasierte Dienste mit wenig oder gar keiner Vorwarnung abschneiden können, selbst bei hochkarätigen institutionellen Nutzern. Das ist keine theoretische Sorge mehr; das ist ein dokumentiertes Kontinuitätsrisiko.

Architektonische Transparenz. Sie müssen verstehen, nicht nur vertraglich, sondern technisch, wie Ihre Systeme mit Daten umgehen. Wohin sie fließen. Wo sie verarbeitet werden. Wer Zugriff hat. Die DSGVO verlangt das seit 2018. Der EU-KI-Act erweitert es.

Jede dieser Anforderungen ist mit proprietärer Software schwieriger zu erfüllen und mit Open Source leichter. Prüfbarkeit wird verbessert, wenn der Code selbst prüfbar ist. Vendor Lock-in wird gemindert, wenn die Software dank einer unwiderruflichen Lizenz auf unbestimmte Zeit selbst gehostet werden kann. Kontinuität bleibt erhalten, wenn keine einzelne Partei Ihren Zugriff abschalten kann. Architektonische Transparenz ist automatisch gegeben, wenn die Architektur per Definition transparent ist.

Die klare These für Open Source in regulierten Branchen

Open Source ist für regulierte Branchen sicher, weil es das einzige Softwaremodell ist, das regulierten Branchen erlaubt, das nachzuweisen, was ihre Aufsichtsbehörden von ihnen nachgewiesen haben wollen.

Proprietäre Software verlangt, dass Sie dem Anbieter glauben. Open Source lässt Sie den Code lesen. Proprietäre Software koppelt Ihre Kontinuität an die kommerziellen Entscheidungen eines Anbieters. Open Source macht Kontinuität zu einer Eigenschaft der Lizenz. Proprietäre Software macht die Reaktion auf Vorfälle zu einem Zeitplan des Anbieters. Open Source macht sie zu Ihrem Zeitplan. Proprietäre Software macht die Architekturprüfung zu einer vertraglichen Übung. Open Source macht sie zu einer Codeprüfung.

Das sind keine subjektiven Vorlieben. Es ist der Unterschied zwischen vertraglicher Zusicherung und architektonischer Zusicherung, und moderne Regulierung verlangt zunehmend die zweite.

Häufige Einwände, beantwortet

Drei Einwände tauchen oft genug auf, dass sie eine direkte Antwort verdienen.

„Open Source bedeutet keinen Support.“ Das vermischt Lizenzierung mit kommerziellen Beziehungen. Viele Open-Source-Projekte haben professionelle kommerzielle Anbieter, die Enterprise-Support, SLAs und dedizierte Sicherheitsreaktionen anbieten. Die Lizenz betrifft das Eigentum am Code; sie betrifft nicht das Vorhandensein von Supportverträgen. Wenn überhaupt, gibt Ihnen Open Source meist eine größere Auswahl an Support-Anbietern, weil kein einzelner Anbieter die zugrunde liegende Technologie kontrolliert.

„Bei Open Source kann jeder bösartigen Code beitragen.“ Reife Open-Source-Projekte verwenden signierte Commits, Freigaben von Pull Requests durch mehrere Reviewer, reproduzierbare Builds und Software Bills of Materials (SBOMs), genau um das zu adressieren. Die Sicherheit der Lieferkette großer Open-Source-Projekte ist im Jahr 2026 in vielen Fällen strenger als jene vergleichbarer proprietärer Produkte, weil die gesamte Pipeline öffentlich einsehbar ist.

„Unser Regulator wird das nicht genehmigen.“ Unserer Erfahrung nach ist das fast immer eine Fehlinterpretation der tatsächlichen Position des Regulators. Aufsichtsbehörden interessieren sich für Risikomanagement, nachweisbare Kontrollen und Kontinuität. Open-Source-Software erfüllt diese Anforderungen, wenn sie richtig gesteuert wird, ebenso gut oder besser als proprietäre Software. Was Aufsichtsbehörden beanstanden, ist nicht gewartete Software, nicht verifizierte Abhängigkeiten und undokumentierte Bereitstellung. Das sind Governance-Probleme, keine Probleme des Lizenzmodells.

Wie „richtig gesteuertes“ Open Source aussieht

Zur Vorwegnahme der naheliegenden Anschlussfrage: Ja, die Bereitstellung von Open Source in einer regulierten Umgebung ist nicht frei von Pflichten. Sie erfordert:

Ein dokumentiertes Inventar der verwendeten Open-Source-Komponenten, mit erfassten Versionen und Lizenzen

Einen Prozess zur Überwachung von Sicherheitsmeldungen aus dem Upstream und zur Anwendung von Patches

Eine gepflegte Build-Pipeline mit reproduzierbaren Builds und signierten Artefakten

Ein SBOM (Software Bill of Materials) für jedes bereitgestellte System

Eine dokumentierte Ausstiegs- und Kontinuitätsstrategie, einschließlich der kritischen Abhängigkeiten

Eine klare Trennung zwischen der Open-Source-Schicht und allen bestehenden kommerziellen Supportverträgen

Das sind keine außergewöhnlichen Anforderungen. Sie sind zunehmend die Basisanforderungen für jede Software in regulierten Branchen, ob Open Source oder nicht. Der Unterschied ist, dass Open Source sie umsetzbar macht.

Wo Xinity in diesem Bild steht

Das ist für uns kein abstraktes Argument. Wir haben Xinity Runtime, unsere KI-Inferenz-Engine, genau als jene Open-Source-Infrastruktur gebaut, die regulierte Branchen einsetzen können, ohne irgendjemandes Wort für bare Münze nehmen zu müssen.

Die Runtime steht unter Apache 2.0, was bedeutet, dass sie Ihnen gehört, dass Sie sie forken, verändern und auf Ihrer eigenen Infrastruktur unbegrenzt betreiben können. Der Code ist öffentlich verfügbar unter github.com/xinity-ai/xinity-ai. Builds sind reproduzierbar. Die Architektur ist dokumentiert. Der Datenfluss ist von Haus aus prüfbar, ohne versteckte Netzwerkaufrufe und ohne Telemetrie Dritter.

Wir haben uns aus diesen Gründen dafür entschieden, weil die Alternative gewesen wäre, regulierte Branchen zu bitten, uns zu vertrauen. Und wir fanden das nicht fair.

Wenn Sie als CISO, Compliance-Verantwortliche oder Architekt eine KI-Infrastruktur für eine regulierte Umgebung bewerten, können Sie jede einzelne Zeile des Codes lesen, die in Ihrem Rechenzentrum laufen würde, bevor Sie sich auf irgendetwas festlegen. Das ist der Standard, an den wir uns selbst gebunden haben. Wir meinen, das ist auch der Standard, an dem der Rest der Branche gemessen werden sollte.

Zusammenfassend

Die Frage „Ist Open Source sicher genug für regulierte Branchen?“ hat eine direkte Antwort.

Open Source ist nicht nur sicher genug. Es ist im Jahr 2026 die einzige Softwarearchitektur, die das erfüllen kann, was moderne Regulierung tatsächlich verlangt: Prüfbarkeit, Kontinuität, Transparenz und nachweisbare Kontrolle. Der Mythos der Closed-Source-Sicherheit durch Geheimhaltung ist in der Kryptografie seit über einem Jahrhundert ausgemustert, und er sollte nun auch im Unternehmenseinkauf ausgemustert werden.

Die Infrastruktur jeder regulierten Branche dieser Welt – Banken, Krankenhäuser, Regierungen – läuft bereits auf Open-Source-Betriebssystemen, Datenbanken und Orchestrierungstools. Die Frage ist nicht, ob Open Source in regulierte Branchen gehört. Sondern warum noch immer jemand es als Ausnahme statt als Grundlage behandelt.

Wenn Sie diese Frage für Ihre eigene Organisation durchdenken, sprechen wir gerne mit Ihnen darüber. Nicht, um Ihnen etwas zu verkaufen, sondern um zu teilen, was wir bei der Arbeit mit regulierten Kunden in der DACH-Region gelernt haben.

Sie erreichen uns unter contact@xinity.ai oder lesen Sie den Quellcode selbst unter github.com/xinity-ai/xinity-ai.

Xinity Runtime ist die Open-Source-KI-Infrastrukturschicht für europäische Unternehmen. Apache 2.0, selbst hostbar, von der Architektur her DSGVO-konform.