Die Qual der Wahl: Open-Source-Lösungen für Unternehmen

Überraschende Zahlen aus dem 2025 State of Open Source Report: 96 % der befragten Unternehmen nutzen Open-Source-Anwendungen. Open Source ist attraktiv – eine breit gefächerte Auswahl, vielfältige Anpassungsmöglichkeiten und niedrige Lizenzkosten sprechen für sich. Für über die Hälfte der Umfrageteilnehmer stellt die laufende Wartung von Open-Source-Apps jedoch eine große Herausforderung dar. 63 % der Befragten haben Mühe, die Lösungen auf dem neuesten Stand zu halten und Patches einzuspielen. Auch andere Probleme sorgen für schlaflose Nächte: Cybersicherheit, Einhaltung gesetzlicher Vorgaben und die Lebensdauer von Open-Source-Anwendungen, da abgelaufene Projekte nicht mehr unterstützt werden. Wie lassen sich diese Probleme minimieren? Und worauf musst du achten, wenn du Open-Source-Software (OSS) implementieren möchtest?

Updates und Patches

Das häufigste Problem ist die zeitgerechte Aktualisierung, darum solltest du potenzielle OSS-Anwärter sehr sorgfältig auf diesen Aspekt hin durchleuchten. Die Häufigkeit und der Umfang von Updates sowie deren Inhalt lassen sich direkt im öffentlichen Repository der Anwendung begutachten. Die folgenden Fragen dienen als Orientierungshilfe: Wie gut sind die Updates dokumentiert? Welche Problemarten werden durch die Updates gelöst? Welche neuen Funktionen werden durch Updates hinzugefügt? Wie häufig erscheinen kleinere Korrekturen einige Tage oder Wochen nach einer Hauptversion? Wie schnell wird auf gemeldete Fehler reagiert?

Bei der Beantwortung helfen Standardtools (z. B. Git Insights) und zusätzliche Dienste (Is it maintained?, Repology und Libraries.io). Libraries.io zeigt sofort an, welche veralteten Abhängigkeiten die aktuelle Version verwendet.

Sicherheitsrelevante Updates verdienen besondere Aufmerksamkeit. Werden solche Updates separat veröffentlicht oder mit Funktions-Updates gebündelt? In der Regel bedienen sich Entwickler der zweiten Methode. In diesem Fall ist ausschlaggebend, wie lange die Veröffentlichung von Sicherheits-Updates gewöhnlich dauert.

Zudem muss geklärt werden, wie komplex die Installation von Updates ist. Dabei helfen die offizielle Dokumentation und das Hilfesystem. Oft sind noch weitere Informationsquellen erforderlich. Empfehlenswert ist auch eine gründliche Lektüre von Feedbacks der Benutzer-Community.

Anhand dieser umfassenden Informationen kannst du einschätzen, wie aufwendig die Wartung des Produkts ist. Du musst interne Ressourcen für den Support zuweisen. Es reicht nicht aus, Verantwortliche zu ernennen. Für solche und ähnliche Aufgaben müssen spezielle Arbeitszeiten vorgesehen werden.

Schwachstellen

Für eine Prognose zur möglichen Häufigkeit von Cybersicherheitsproblemen empfiehlt es sich, die Entwicklungskultur und die Cybersicherheitshygiene des Produkts vorab zu bewerten. Dies kann ziemlich aufwendig sein. Eine erste allgemeine Analyse kannst du jedoch mit automatisierten Tools durchführen.

Für gängige Produkte und Pakete kannst du dich auf vorhandene heuristische Bewertungsergebnisse von Tools wie OpenSSF Scorecard stützen. Das Tool stellt eine Vielzahl von Daten zur Cybersicherheitshygiene bereit. Beispielsweise die Anzahl der nicht behobenen Schwachstellen, das Vorhandensein von Sicherheitsrichtlinien sowie die Verwendung von Fuzzing und Abhängigkeits-Pinning.

Wichtige Infos bieten auch öffentlich verfügbare Schwachstellendatenbanken (z. B. NVD und GitHub-Advisory). Dort erfährst du, wie viele Schwachstellen im Projekt entdeckt wurden, wie kritisch sie sind und wie schnell sie gefixt wurden. Übrigens deutet eine hohe Anzahl von Schwachstellen eher auf die Popularität des Projekts hin als auf eine dürftige Entwicklungspraxis. Wichtiger ist vielmehr, um welche Art von Fehlern es geht und wie die Entwickler auf Fehler reagieren.

Abhängigkeiten und Lieferkette

Fast jedes OSS-Projekt basiert auf Open-Source-Komponenten von Drittanbietern, die oft nicht dokumentiert sind. Solche Komponenten werden nach eigenen Zeitplänen aktualisiert und können Fehler, Schwachstellen und sogar bösartigen Code enthalten. Dabei ist entscheidend, wie schnell gepatchte Komponenten-Updates in das Projekt einfließen, das du gerade checkst.

Um diesen Aspekt zu beurteilen, benötigst du die Tools SBOM (Software Bill of Material) oder SCA (Software Composition Analysis). Spezielle Open-Source-Lösungen (z. B. OWASP Dependency-Check oder Syft) können die Abhängigkeitsstruktur eines Projekts darstellen. Sie sind jedoch normalerweise für Projekte gedacht, die bereits im Einsatz sind und in deinen eigenen Repositorys oder Container-Images bereitstehen. Darum ist eine gründliche Abhängigkeitenanalyse eher für ein Produkt geeignet, das die vorläufige Bewertung bereits bestanden hat und als ernsthafter Kandidat für deine Infrastruktur infrage kommt.

Überprüfe die Liste der Abhängigkeiten anhand der folgenden Fragen: Stammen die Komponenten aus vertrauenswürdigen und bewährten Datenquellen? Sind sie beliebt? Verfügen sie über digitale Signaturen? Anhand dieser Kriterien bewertest du die Kompromittierungsrisiken.

Eigentlich könntest du von Hand nach Schwachstellen in Abhängigkeiten suchen. Wenn ein OSS-Projekt jedoch bereits in einer Testumgebung bereitgestellt wurde, sind Tools wie Grype viel effektiver.

Die Überwachung von Updates kann sich ganz unerwartet als große Herausforderung entpuppen. Theoretisch muss jedes Abhängigkeits-Update für ein Projekt erneut überprüft werden. In der Praxis ist dies nur mit automatisierten Scannern möglich. Alle anderen Ansätze sind unbezahlbar.

Wenn ein Projekt veraltete Abhängigkeiten verwendet und im Hinblick auf die Cybersicherheit nicht ideal ist, solltest du gleich nach einer Alternative suchen. Es kann allerdings sein, dass dein Unternehmen aufgrund seines Profils eine ganz bestimmte Lösung benötigt? Dann gibt es nur einen Weg: Analysiere die Risiken sehr gründlich, entwickle kompensierende Maßnahmen und stelle genügend Ressourcen für die laufende Wartung bereit. Erfahrungsgemäß sind die internen Ressourcen oft nicht ausreichend. Darum solltest du von Anfang an Optionen für den professionellen technischen Support der relevanten Produkte abwägen.

Einhaltung interner und gesetzlicher Vorschriften

Möglicherweise gelten für die gewählte Software und die entsprechenden Daten gesetzliche Bestimmungen. In diesem Fall solltest du umgehend einen Plan für Compliance-Audits ausarbeiten. Etablierte Open-Source-Anwendungen der Enterprise-Klasse bieten teilweise eine begleitende Dokumentation, die bestimmte Audits vereinfacht. Andernfalls musst du selbst dafür sorgen, was wiederum erheblichen Zeitaufwand bedeutet und Ressourcen bindet.

Unabhängig von der Branche erfordert nahezu jede Software ein Lizenz-Compliance-Audit. Einige Open-Source-Komponenten und -Anwendungen werden unter restriktiven Lizenzen (z. B. AGPL) vertrieben, die die Verbreitung und Nutzung der Software einschränken. Dank der SBOM/SCA-Analyse kannst du alle Lizenzen für deine Software und deren Abhängigkeiten inventarisieren und anschließend überprüfen, ob dein Anwendungsfall mit allen Lizenzen in Einklang steht. Diese Prozesse lassen sich mit speziellen Tools wie OSS Review Toolkit weitgehend automatisieren, aber die Automatisierung erfordert eindeutige Richtlinien und Ressourcen deines Entwicklungsteams.

Wartungskosten

Nachdem du alle oben genannten Aspekte analysiert hast, musst du dir noch überlegen, welche Varianten es für die Wartung der Anwendung gibt. Wenn ein internes Team die Wartung übernimmt, musst du den Spezialisten entsprechende Zeitressourcen zuweisen. Falls dein Team nicht über das erforderliche Fachwissen verfügt, musst du Experten einstellen. Die Personen, die für die Wartung und Sicherheit von Open-Source-Software verantwortlich sind, benötigen außerdem Zeit und Mittel für eine ständige Weiterbildung.

Wenn die Ressourcen deines internen Teams für die Wartung zu knapp sind (zu wenig Personal oder fehlendes Know-how), gibt es mindestens zwei Optionen für professionellen technischen Support durch Drittanbieter: Firmen, die auf den Betrieb von Anwendungen spezialisiert sind (z. B. Red Hat) und Managed-Hosting-Provider für spezielle Anwendungen (z. B. Kube Clusters und MongoDB Atlas).

Kosten und Komplexität des technischen Supports sind nicht nur vom Zeitaufwand und der Expertise abhängig. Es spielt auch eine Rolle, ob dein Unternehmen auf eine umfassende Open-Source-Einführung vorbereitet ist:

• Verfügt dein Cybersicherheitsteam über Schwachstellen-Scanner und Risikomanagement-Tools, die für OSS geeignet sind?
• Unterstützen deine Tracking- und Überwachungstools für IT-Assets auch Open-Source-Projekte und -Komponenten?
• Wichtig für interne Entwicklungsteams: Sind die Prozesse zur Untersuchung von Bildern, Repositorys und anderen Codequellen in der CI/CD-Pipeline enthalten? Dieser Aspekt lässt sich durch spezialisierte Sicherheitslösungen automatisieren (z. B. mit Kaspersky Hybrid Cloud Security ).
• Besitzt dein Unternehmen eine Richtlinie für die OSS-Nutzung? Wer trifft Entscheidungen und wer ist für dringende Maßnahmen zuständig?

Ein weiterer wichtiger Aspekt ist das umfangreiche Spektrum von Open-Source-Risiken. Dazu zählen das möglicherweise abrupte Ende eines Projekts, eine Vielzahl geringfügiger Abhängigkeiten und andere Risiken in der Lieferkette.