{"id":32344,"date":"2025-06-24T10:38:44","date_gmt":"2025-06-24T08:38:44","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=32344"},"modified":"2025-06-25T12:47:25","modified_gmt":"2025-06-25T10:47:25","slug":"can-you-support-open-source-preliminary-assessment","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/can-you-support-open-source-preliminary-assessment\/32344\/","title":{"rendered":"Die Qual der Wahl: Open-Source-L\u00f6sungen f\u00fcr Unternehmen"},"content":{"rendered":"

\u00dcberraschende Zahlen aus dem 2025 State of Open Source Report<\/a>: 96\u00a0% der befragten Unternehmen nutzen Open-Source-Anwendungen. Open Source ist attraktiv\u00a0\u2013 eine breit gef\u00e4cherte Auswahl, vielf\u00e4ltige Anpassungsm\u00f6glichkeiten und niedrige Lizenzkosten sprechen f\u00fcr sich. F\u00fcr \u00fcber die H\u00e4lfte der Umfrageteilnehmer stellt die laufende Wartung von Open-Source-Apps jedoch eine gro\u00dfe Herausforderung dar. 63\u00a0% der Befragten haben M\u00fche, die L\u00f6sungen auf dem neuesten Stand zu halten und Patches einzuspielen. Auch andere Probleme sorgen f\u00fcr schlaflose N\u00e4chte: Cybersicherheit, Einhaltung gesetzlicher Vorgaben und die Lebensdauer von Open-Source-Anwendungen, da abgelaufene Projekte nicht mehr unterst\u00fctzt werden. Wie lassen sich diese Probleme minimieren? Und worauf musst du achten, wenn du Open-Source-Software (OSS) implementieren m\u00f6chtest?<\/p>\n

Updates und Patches<\/h2>\n

Das h\u00e4ufigste Problem ist die zeitgerechte Aktualisierung, darum solltest du potenzielle OSS-Anw\u00e4rter sehr sorgf\u00e4ltig auf diesen Aspekt hin durchleuchten. Die H\u00e4ufigkeit und der Umfang von Updates sowie deren Inhalt lassen sich direkt im \u00f6ffentlichen Repository der Anwendung begutachten. Die folgenden Fragen dienen als Orientierungshilfe: Wie gut sind die Updates dokumentiert? Welche Problemarten werden durch die Updates gel\u00f6st? Welche neuen Funktionen werden durch Updates hinzugef\u00fcgt? Wie h\u00e4ufig erscheinen kleinere Korrekturen einige Tage oder Wochen nach einer Hauptversion? Wie schnell wird auf gemeldete Fehler reagiert?<\/p>\n

Bei der Beantwortung helfen Standardtools (z.\u00a0B. Git Insights<\/a>) und zus\u00e4tzliche Dienste (Is it maintained?<\/a>, Repology<\/a> und Libraries.io<\/a>). Libraries.io zeigt sofort an, welche veralteten Abh\u00e4ngigkeiten die aktuelle Version verwendet.<\/p>\n

Sicherheitsrelevante Updates verdienen besondere Aufmerksamkeit. Werden solche Updates separat ver\u00f6ffentlicht oder mit Funktions-Updates geb\u00fcndelt? In der Regel bedienen sich Entwickler der zweiten Methode. In diesem Fall ist ausschlaggebend, wie lange die Ver\u00f6ffentlichung von Sicherheits-Updates gew\u00f6hnlich dauert.<\/p>\n

Zudem muss gekl\u00e4rt 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\u00fcndliche Lekt\u00fcre von Feedbacks der Benutzer-Community.<\/p>\n

Anhand dieser umfassenden Informationen kannst du einsch\u00e4tzen, wie aufwendig die Wartung des Produkts ist. Du musst interne Ressourcen f\u00fcr den Support zuweisen. Es reicht nicht aus, Verantwortliche zu ernennen. F\u00fcr solche und \u00e4hnliche Aufgaben m\u00fcssen spezielle Arbeitszeiten vorgesehen werden.<\/p>\n

Schwachstellen<\/h2>\n

F\u00fcr eine Prognose zur m\u00f6glichen H\u00e4ufigkeit 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\u00fchren.<\/p>\n

F\u00fcr g\u00e4ngige Produkte und Pakete kannst du dich auf vorhandene heuristische Bewertungsergebnisse von Tools wie OpenSSF Scorecard<\/a> st\u00fctzen. 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\u00e4ngigkeits-Pinning.<\/p>\n

Wichtige Infos bieten auch \u00f6ffentlich verf\u00fcgbare Schwachstellendatenbanken (z.\u00a0B. NVD<\/a> und GitHub-Advisory<\/a>). Dort erf\u00e4hrst du, wie viele Schwachstellen im Projekt entdeckt wurden, wie kritisch sie sind und wie schnell sie gefixt wurden. \u00dcbrigens deutet eine hohe Anzahl von Schwachstellen eher auf die Popularit\u00e4t des Projekts hin als auf eine d\u00fcrftige Entwicklungspraxis. Wichtiger ist vielmehr, um welche Art von Fehlern es geht und wie die Entwickler auf Fehler reagieren.<\/p>\n

Abh\u00e4ngigkeiten und Lieferkette<\/h2>\n

Fast jedes OSS-Projekt basiert auf Open-Source-Komponenten von Drittanbietern, die oft nicht dokumentiert sind. Solche Komponenten werden nach eigenen Zeitpl\u00e4nen aktualisiert und k\u00f6nnen Fehler, Schwachstellen und sogar b\u00f6sartigen Code enthalten. Dabei ist entscheidend, wie schnell gepatchte Komponenten-Updates in das Projekt einflie\u00dfen, das du gerade checkst.<\/p>\n

Um diesen Aspekt zu beurteilen, ben\u00f6tigst du die Tools SBOM (Software Bill of Material) oder SCA (Software Composition Analysis). Spezielle Open-Source-L\u00f6sungen (z.\u00a0B. OWASP Dependency-Check<\/a> oder Syft<\/a>) k\u00f6nnen die Abh\u00e4ngigkeitsstruktur eines Projekts darstellen. Sie sind jedoch normalerweise f\u00fcr Projekte gedacht, die bereits im Einsatz sind und in deinen eigenen Repositorys oder Container-Images bereitstehen. Darum ist eine gr\u00fcndliche Abh\u00e4ngigkeitenanalyse eher f\u00fcr ein Produkt geeignet, das die vorl\u00e4ufige Bewertung bereits bestanden hat und als ernsthafter Kandidat f\u00fcr deine Infrastruktur infrage kommt.<\/p>\n

\u00dcberpr\u00fcfe die Liste der Abh\u00e4ngigkeiten anhand der folgenden Fragen: Stammen die Komponenten aus vertrauensw\u00fcrdigen und bew\u00e4hrten Datenquellen? Sind sie beliebt? Verf\u00fcgen sie \u00fcber digitale Signaturen? Anhand dieser Kriterien bewertest du die Kompromittierungsrisiken.<\/p>\n

Eigentlich k\u00f6nntest du von Hand nach Schwachstellen in Abh\u00e4ngigkeiten suchen. Wenn ein OSS-Projekt jedoch bereits in einer Testumgebung bereitgestellt wurde, sind Tools wie Grype<\/a> viel effektiver.<\/p>\n

Die \u00dcberwachung von Updates kann sich ganz unerwartet als gro\u00dfe Herausforderung entpuppen. Theoretisch muss jedes Abh\u00e4ngigkeits-Update f\u00fcr ein Projekt erneut \u00fcberpr\u00fcft werden. In der Praxis ist dies nur mit automatisierten Scannern m\u00f6glich. Alle anderen Ans\u00e4tze sind unbezahlbar.<\/p>\n

Wenn ein Projekt veraltete Abh\u00e4ngigkeiten 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\u00f6sung ben\u00f6tigt? Dann gibt es nur einen Weg: Analysiere die Risiken sehr gr\u00fcndlich, entwickle kompensierende Ma\u00dfnahmen und stelle gen\u00fcgend Ressourcen f\u00fcr die laufende Wartung bereit. Erfahrungsgem\u00e4\u00df sind die internen Ressourcen oft nicht ausreichend. Darum solltest du von Anfang an Optionen f\u00fcr den professionellen technischen Support der relevanten Produkte abw\u00e4gen.<\/p>\n

Einhaltung interner und gesetzlicher Vorschriften<\/h2>\n

M\u00f6glicherweise gelten f\u00fcr die gew\u00e4hlte Software und die entsprechenden Daten gesetzliche Bestimmungen. In diesem Fall solltest du umgehend einen Plan f\u00fcr Compliance-Audits ausarbeiten. Etablierte Open-Source-Anwendungen der Enterprise-Klasse bieten teilweise eine begleitende Dokumentation, die bestimmte Audits vereinfacht. Andernfalls musst du selbst daf\u00fcr sorgen, was wiederum erheblichen Zeitaufwand bedeutet und Ressourcen bindet.<\/p>\n

Unabh\u00e4ngig von der Branche erfordert nahezu jede Software ein Lizenz-Compliance-Audit. Einige Open-Source-Komponenten und -Anwendungen werden unter restriktiven Lizenzen (z.\u00a0B. AGPL)<\/a> vertrieben, die die Verbreitung und Nutzung der Software einschr\u00e4nken. Dank der SBOM\/SCA-Analyse kannst du alle Lizenzen f\u00fcr deine Software und deren Abh\u00e4ngigkeiten inventarisieren und anschlie\u00dfend \u00fcberpr\u00fcfen, ob dein Anwendungsfall mit allen Lizenzen in Einklang steht. Diese Prozesse lassen sich mit speziellen Tools wie OSS Review Toolkit<\/a> weitgehend automatisieren, aber die Automatisierung erfordert eindeutige Richtlinien und Ressourcen deines Entwicklungsteams.<\/p>\n

Wartungskosten<\/h2>\n

Nachdem du alle oben genannten Aspekte analysiert hast, musst du dir noch \u00fcberlegen, welche Varianten es f\u00fcr die Wartung der Anwendung gibt. Wenn ein internes Team die Wartung \u00fcbernimmt, musst du den Spezialisten entsprechende Zeitressourcen zuweisen. Falls dein Team nicht \u00fcber das erforderliche Fachwissen verf\u00fcgt, musst du Experten einstellen. Die Personen, die f\u00fcr die Wartung und Sicherheit von Open-Source-Software verantwortlich sind, ben\u00f6tigen au\u00dferdem Zeit und Mittel f\u00fcr eine st\u00e4ndige Weiterbildung.<\/p>\n

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

Kosten und Komplexit\u00e4t des technischen Supports sind nicht nur vom Zeitaufwand und der Expertise abh\u00e4ngig. Es spielt auch eine Rolle, ob dein Unternehmen auf eine umfassende Open-Source-Einf\u00fchrung vorbereitet ist:<\/p>\n