Open Source Sicherheit: Keine Blackbox

Illustration zum Vergleich von Open Source und Closed Source: Links eine transparente, grüne Box, in der HONICON-Figuren den offen einsehbaren Quellcode auf Bildschirmen prüfen und sich austauschen. Rechts eine geschlossene, dunkle Box mit der Aufschrift „Closed Source" – ihr Inneres bleibt verborgen. Davor steht eine HONICON-Figur vor der Wahl zwischen „Open Option" und „Closed Option". Überschrift: „Open Source ist keine Blackbox". — Transparenz statt Blackbox: Bei Open Source ist einsehbar, was im Inneren passiert – bei Closed Source bleibt nur Vertrauen.

ℹ️ tl;dr

73 Prozent der deutschen Unternehmen setzen auf Open Source. Das zeigt der Bitkom-Monitor 2025 – Tendenz steigend.
Open-Source-Sicherheit lebt von offenem Code. Du siehst, was drin ist. Geschlossene Software bleibt eine Blackbox.
Das BSI setzt bewusst auf Software-Vielfalt. So werden Monokulturen und große Angriffsflächen vermieden.
Der Cyber Resilience Act verlangt eine vollständige Komponentenliste. Als Hersteller musst du sie liefern – egal ob Open Source oder nicht.
Selbst AWS, Microsoft Azure und Atlassian setzen auf offene Technologie. Sie steckt längst im Kern ihrer Systeme.

Du stehst vor der Entscheidung, ob dein nächstes Projekt auf einer Open-Source-Lösung laufen soll. Die Geschäftsführung fragt dich: Ist das nicht ein zusätzliches Sicherheitsrisiko? Genau diese Frage bekommen wir häufig gestellt. Schon 2008 titelte eine große Marktstudie von Gartner, dass in Kürze nahezu alle Unternehmen Open-Source-Software einsetzen würden. Heute bestätigt der Open Source Monitor 2025 von Bitkom: 73 Prozent der deutschen Unternehmen nutzen Open Source, vor zwei Jahren waren es 69 Prozent. Die Zahlen sprechen für sich. Doch der eigentliche Unterschied liegt darin, dass Open Source keine Blackbox ist. Und genau das ist der Punkt, den noch viele Entscheider bei der Open Source Sicherheit bisher übersehen.

Warum Open Source keine Blackbox ist

Bei Open Source liegt der Code offen. Du kannst reinschauen, verstehen, im Zweifel korrigieren lassen. Bei proprietärer Software bleibt dir nur, dem Hersteller zu vertrauen, eine Blackbox eben. Linux, Kubernetes, Ansible: alles längst Standard, alles offen einsehbar.

Der Unterschied klingt zunächst technisch. Ist er aber nicht. Es ist eine Vertrauensfrage: Verlässt du dich auf das Versprechen eines Herstellers, oder kannst du selbst nachvollziehen, was in deinen Systemen passiert?

Was Open Source Sicherheit für dein Unternehmen bedeutet

Tausende Entwickler können denselben Code einsehen. Schwachstellen fallen so oft schneller auf als in geschlossener Software, weil nicht nur der Hersteller selbst prüft, sondern eine ganze Community mitschaut. Das BSI setzt deshalb bewusst auf Software-Vielfalt statt auf eine einzige Standardlösung für alle: Wenn fast jeder dieselbe Software einsetzt, muss ein Angreifer nur eine Schwachstelle finden, um sehr viele Systeme gleichzeitig zu treffen. Mehr unterschiedliche Lösungen im Einsatz bedeuten also weniger Angriffsfläche auf einen Schlag, und mehr Unabhängigkeit vom einzelnen Hersteller.

Illustration zum Peer-Review-Prinzip bei Open Source: Links die transparente Open-Source-Box, in der HONICON-Figuren gemeinsam am Quellcode arbeiten und sich austauschen. Rechts ein Code-Editor, dessen Inhalt von unabhängigen Prüf-Agenten mit grünen Scannern durchleuchtet wird – symbolisiert die zusätzliche Kontrolle durch die weltweite Community. — Nicht nur die Entwickler im Projekt prüfen den Code – tausende unabhängige Augen aus der Community schauen mit und entdecken Schwachstellen oft schneller.

Das bleibt keine Theorie. Im Projekt CAOS: Gemeinsam mit einem externen Sicherheitsdienstleister hat das BSI den Code von BigBlueButton und Jitsi geprüft und gefundene Lücken den Entwicklern vertraulich gemeldet, statt sie sofort zu veröffentlichen, damit erst ein Patch bereitsteht, bevor Angreifer davon erfahren. Viele Augen helfen aber nur, wenn auch wirklich geprüft wird. Offener Code ersetzt keine gepflegte Update-Routine, dazu hatten wir kürzlich mehr in Never change a running system geschrieben.

Ein Punkt kommt für dich als Unternehmen trotzdem hinzu: Der Cyber Resilience Act, die neue EU-Verordnung für die Cybersicherheit von Produkten mit digitalen Elementen, nimmt in erster Linie nicht-kommerzielle Open-Source-Projekte selbst aus der strengen Haftung. Sobald du aber Open-Source-Komponenten in ein eigenes Produkt einbaust, giltst du als Hersteller, und die Verantwortung liegt bei dir, nicht bei der Community dahinter.

Konkret verlangt der CRA ab Dezember 2027 eine Software Bill of Materials, eine vollständige Liste aller Softwarekomponenten eines Produkts. Diese Liste unterscheidet nicht zwischen Open Source und zugekaufter Software, beides wird gleich behandelt. Relevant wird sie für dich trotzdem besonders im Open-Source-Kontext, weil in typischen Anwendungen ein Großteil des Codes aus Open-Source-Bibliotheken besteht. Bei Bekanntwerden einer Schwachstelle wie damals bei Log4Shell entscheidet diese Liste, ob du in Minuten weißt, ob du betroffen bist, oder tagelang suchen musst. Bußgelder bei Verstößen: bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

Wer treibt Open Source in der Verwaltung voran?

Die öffentliche Hand. Das Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS), eine bundeseigene Gesellschaft, baut mit openDesk (einer Office-Suite für Behörden) und openCode (einer Plattform zum Teilen von Verwaltungssoftware) zwei Bausteine auf, um Behörden unabhängiger von einzelnen internationalen Anbietern zu machen. Im März 2026 haben Bund und Bitkom einheitliche Vertragsbedingungen für die Beschaffung von Open-Source-Lösungen vereinbart. Über 80.000 Arbeitsplätze in der Verwaltung laufen inzwischen auf openDesk. Was heute dort Standard wird, landet morgen in den Anforderungen deiner eigenen Kunden, etwa in Ausschreibungen oder Lieferketten-Nachweisen.

Und im Enterprise-Umfeld?

Dort zieht das nach, allerdings aus einem anderen Grund: Leistung statt Souveränität. Selbst Atlassian hat bei Jira Data Center offiziell auf OpenSearch als Suchmaschine umgestellt und gibt dafür 38 Prozent schnellere Performance an, in Confluence sogar das 4,5-Fache. Wir setzen diese Kombination selbst erfolgreich ein. Sogar die großen Cloud-Konzerne setzen im Kern auf offene Technologie: Sowohl AWS als auch Microsoft Azure bieten Red Hat Enterprise Linux inzwischen offiziell als eigenes Angebot an.

Was Open Source strategisch bringt, und wo die Grenze liegt

Eine Harvard-Studie hat es durchgerechnet: Ohne Open-Source-Software müssten Unternehmen im Schnitt 3,5-mal mehr für Software ausgeben. Das ist ein Durchschnittswert über viele Unternehmen hinweg, keine Garantie für jeden Einzelfall, aber er zeigt: Kostenkontrolle ist real, kein Marketing-Argument. Dazu kommt Unabhängigkeit vom einzelnen Hersteller, wenn sich Preise oder Konditionen ändern, und die Möglichkeit, Software an eigene Prozesse anzupassen statt umgekehrt.

Isometrische Illustration eines modularen Gebäudes aus gestapelten Bausteinen: Grüne Module mit der Aufschrift „Open Source" und graue Module mit „Closed Source" fügen sich zu einer stabilen Gesamtarchitektur zusammen. Zwei HONICON-Figuren bewegen sich im und auf dem Gebäude, umgeben von Bäumen. Die Struktur symbolisiert eine IT-Landschaft, in der offene und geschlossene Software gezielt kombiniert werden. — Eine erfolgreiche IT-Architektur kombiniert Open- und Closed-Source-Lösungen dort, wo sie am meisten Sinn ergeben.

Wir setzen selbst bewusst auf Open Source, aber nicht überall gleich. Unsere Server laufen auf Linux. Für die digitale Identität nutzen wir Authentik statt eines cloudbasierten Login-Dienstes, aus demselben Grund: Wer Zugriff auf Login-Metadaten und Policies hat, entscheidet am Ende, wer Kontrolle über die eigene IT hat. Bei der Server-Automatisierung läuft bei uns Ansible Core mit Semaphore UI, vollständig selbst gehostet.

Der Haken dabei: 60 Prozent der Unternehmen haben laut derselben Auswertung keine Open-Source-Strategie, nur 14 Prozent eine eigene interne Stelle, die genau das koordiniert (ein sogenanntes Open Source Program Office), bei 62 Prozent fehlt eine dokumentierte Policy. Genutzt wird es überall, gesteuert selten, und genau da entscheidet sich, ob Open Source zum Vorteil wird oder zur Dauerbaustelle.

Fazit: Deine Enterprise-Umgebung,deine Regeln

Open Source ist keine Blackbox, sondern genau das Gegenteil. Es kann deine Enterprise-Umgebung sein, die du fast vollständig an dein Unternehmen anpassen kannst. Es gibt dir die Freiheit und Sicherheit, die dir eine proprietäre SaaS-Lösung nicht geben kann.

Wir helfen dir gerne bei der richtigen Open-Source-Strategie, mit langer Erfahrung im Open-Source-Segment.