{"id":33403,"date":"2026-04-20T11:03:09","date_gmt":"2026-04-20T09:03:09","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=33403"},"modified":"2026-04-20T11:02:32","modified_gmt":"2026-04-20T09:02:32","slug":"managing-open-source-vulnerabilities","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/managing-open-source-vulnerabilities\/33403\/","title":{"rendered":"Architektur des Schwachstellen-Managements f\u00fcr Open Source"},"content":{"rendered":"<p>Wie bereits <a href=\"https:\/\/www.kaspersky.de\/blog\/open-source-vulnerabilities-in-ai-era\/33399\/\" target=\"_blank\" rel=\"noopener\">in einem anderen Artikel<\/a> erw\u00e4hnt: Ohne den Einsatz von Open-Source-Komponenten ist die moderne Software-Entwicklung praktisch undenkbar. In den letzten Jahren sind die damit verbundenen Risiken jedoch immer vielf\u00e4ltiger, komplexer und zahlreicher geworden. Erstens: Schwachstellen beeintr\u00e4chtigen die Infrastruktur und die Codebasis von Unternehmen und k\u00f6nnen oft nicht rechtzeitig behoben werden. Zweitens: unzuverl\u00e4ssige und unvollst\u00e4ndige Daten. Und drittens: Malware kann in beliebten Komponenten lauern. Es reicht nicht aus, einfach die Versionsnummern zu scannen und dem IT-Team Korrekturtickets zu schicken. Das Schwachstellen-Management muss viel breiter angelegt sein. Die Rede ist von Richtlinien f\u00fcr Software-Downloads, Begrenzungen f\u00fcr KI-Assistenten und Regeln f\u00fcr die gesamte Software-Entwicklungs-Pipeline.<\/p>\n<h1>Pool mit vertrauensw\u00fcrdigen Open-Source-Komponenten<\/h1>\n<p>Der Kern der L\u00f6sung besteht darin, der Nutzung von anf\u00e4lligem und b\u00f6sartigem Code einen Riegel vorzuschieben. Dazu sind die folgenden Ma\u00dfnahmen erforderlich:<\/p>\n<ul>\n<li>Internes Repository f\u00fcr Artefakte. Die einzige Quelle f\u00fcr Komponenten, die in der internen Entwicklung genutzt werden, muss ein einheitliches Repository sein. F\u00fcr diese Komponenten gilt eine \u00dcberpr\u00fcfungsprozedur.<\/li>\n<li>Strenges Komponenten-Screening. Dabei werden \u00fcberpr\u00fcft: bekannte Versionen der Komponente, bekannte anf\u00e4llige Versionen und b\u00f6sartige Versionen, Ver\u00f6ffentlichungsdatum, Aktivit\u00e4tsverlauf sowie Reputation des Pakets und seiner Autoren. Die Untersuchung des gesamten Paketinhalts, einschlie\u00dflich Build-Anweisungen, Testf\u00e4llen und anderer Zusatzdaten ist obligatorisch. Wenn neue Komponenten in die Registry aufgenommen werden, erfolgt eine Filterung mithilfe spezieller Open-Source-Scanner oder einer <a href=\"https:\/\/www.kaspersky.de\/enterprise-security\/cloud-workload-security?icid=de_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_wpplaceholder_sm-team_______0e3f5d0e5e802e8b\" target=\"_blank\" rel=\"noopener\">umfassenden Sicherheitsl\u00f6sung f\u00fcr Cloud-Workloads<\/a>.<\/li>\n<li>Anheften von Abh\u00e4ngigkeiten. Build-Prozesse, KI-Tools und Entwickler d\u00fcrfen bei Versionsangaben keine Vorlagen (z.\u00a0B. \u201ek\u00fcrzlich verwendet\u201c) verwenden. Projekt-Builds m\u00fcssen auf verifizierten Versionen beruhen. Gleichzeitig m\u00fcssen angeheftete Abh\u00e4ngigkeiten regelm\u00e4\u00dfig aktualisiert werden. Und zwar auf die neuesten verifizierten Versionen, die Kompatibilit\u00e4t gew\u00e4hrleisten und keine bekannten Schwachstellen aufweisen. Dadurch wird das Risiko von <a href=\"https:\/\/www.kaspersky.com\/blog\/npm-packages-trojanized\/54280\/\" target=\"_blank\" rel=\"noopener nofollow\">Lieferkettenangriffen durch die Kompromittierung eines bekannten Pakets<\/a> erheblich reduziert.<\/li>\n<\/ul>\n<h1>Verbesserung von Daten \u00fcber Schwachstellen<\/h1>\n<p>Um Schwachstellen effektiver zu identifizieren und richtig <a href=\"https:\/\/www.kaspersky.de\/blog\/cvss-rbvm-vulnerability-management\/32454\/\" target=\"_blank\" rel=\"noopener\">zu priorisieren<\/a>, muss ein Unternehmen mehrere IT- und Sicherheitsprozesse einrichten:<\/p>\n<ul>\n<li>Anreicherung von Daten \u00fcber Schwachstellen. Je nach den Anforderungen des Unternehmens k\u00f6nnen Informationen durch die Kombination mit Daten aus NVD, EUVD, BDU, GitHub Advisory Database und osv.dev angereichert werden oder es wird ein kommerzieller Threat-Intelligence-Feed erworben, der bereits aggregierte und angereicherte Daten bietet. Auf jeden Fall ist es empfehlenswert, zus\u00e4tzlich Threat-Intelligence-Feeds zu \u00fcberwachen, um reale Exploit-Trends zu verfolgen und das Profil von Angreifern zu verstehen, die auf bestimmte Schwachstellen spezialisiert sind. Kaspersky bietet einen <a href=\"https:\/\/www.kaspersky.com\/open-source-feed?icid=tr_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_wpplaceholder_sm-team___kti____dc583ac8416d9ba4\" target=\"_blank\" rel=\"noopener nofollow\">spezialisierten Daten-Feed, der sich auf Open-Source-Komponenten konzentriert<\/a>.<\/li>\n<li>Detaillierte Analyse der Software-Komposition. Spezialisierte Software-Kompositionsanalyse-Tools (SCA) erm\u00f6glichen eine fachgerechte Untersuchung der Abh\u00e4ngigkeitskette im Open-Source-Code. Dazu z\u00e4hlen eine vollst\u00e4ndige Inventarisierung der verwendeten Bibliotheken sowie die Erkennung veralteter oder nicht mehr unterst\u00fctzter Komponenten. Daten \u00fcber fehlerfreie Komponenten eignen sich auch, um die Artefakt-Registry anzureichern.<\/li>\n<li>Identifizierung von Abandonware. Selbst wenn eine Komponente formell nicht als anf\u00e4llig gilt und die Unterst\u00fctzung nicht offiziell beendet wurde, lohnt sich eine Suche nach Komponenten, die seit \u00fcber einem Jahr keine Updates mehr erhalten haben. Diese m\u00fcssen separat analysiert und m\u00f6glicherweise ersetzt werden (\u00e4hnlich wie EOL-Komponenten).<\/li>\n<\/ul>\n<h1>Schutz von KI-Code und KI-Agenten<\/h1>\n<p>Die Aktivit\u00e4ten von KI-Systemen, die beim Programmieren verwendet werden, erfordern komplexe Sicherheitsma\u00dfnahmen\u00a0\u2013 von der Filterung der Eingabedaten bis hin zur Benutzerschulung:<\/p>\n<ul>\n<li>Einschr\u00e4nkungen f\u00fcr Abh\u00e4ngigkeitsempfehlungen. Die Entwicklungsumgebung muss so konfiguriert werden, dass KI-Agenten und -Assistenten nur auf Komponenten und Bibliotheken aus der vertrauensw\u00fcrdigen Artefakt-Registry verweisen k\u00f6nnen. Falls die erforderlichen Tools dort nicht zu finden sind, muss das Modell eine Aufnahme der Abh\u00e4ngigkeit in die Registry beantragen. Es darf sich nicht einfach ein anderes Tool aus PyPI holen, das der Beschreibung entspricht.<\/li>\n<li>Filterung von Modellausgaben. Trotz dieser Einschr\u00e4nkungen muss alles, was vom Modell generiert wird, auch \u00fcberpr\u00fcft werden. Auf diese Weise wird sichergestellt, dass der KI-Code keine veralteten, ausgemusterten, anf\u00e4lligen oder erfundenen Abh\u00e4ngigkeiten enth\u00e4lt. Diese Pr\u00fcfung sollte direkt in den Code-Aufnahmeprozess oder in die Build-Vorbereitungsphase integriert werden. Sie ersetzt nicht den traditionellen statischen Analyseprozess: Die CI\/CD-Pipeline muss weiterhin mit SAST-Tools ausger\u00fcstet sein.<\/li>\n<li>Training f\u00fcr Entwickler. IT- und Sicherheitsteams m\u00fcssen sich mit den Eigenschaften, Funktionsprinzipien und h\u00e4ufigsten Fehlern von KI-Systemen bestens auskennen. Dazu sollten die Mitarbeiter ein <a href=\"https:\/\/xtraining.kaspersky.com\/courses\/large-language-models-security\/?icid=de_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_wpplaceholder_sm-team___xtraining____d02e25510b4a870d\" target=\"_blank\" rel=\"noopener\">spezielles Training<\/a> absolvieren, das auf die jeweiligen Rollen zugeschnitten ist.<\/li>\n<\/ul>\n<h1>Systematische Entfernung von EOL-Komponenten<\/h1>\n<p>Wenn in den Unternehmenssystemen veraltete Open-Source-Komponenten im Einsatz sind, m\u00fcssen die entsprechenden Schwachstellen systematisch und einheitlich behoben werden. Daf\u00fcr gibt es grunds\u00e4tzlich drei Methoden:<\/p>\n<ul>\n<li>Migration. Diese Methode verursacht den h\u00f6chsten Organisationsaufwand und ist am teuersten, da eine Komponente vollst\u00e4ndig ersetzt wird. Anschlie\u00dfend m\u00fcssen alle auf der Komponente basierenden Anwendungen angepasst, neu geschrieben oder ausgetauscht werden. Die Entscheidung f\u00fcr eine Migration ist besonders schwierig, wenn dadurch eine umfassende \u00dcberarbeitung des gesamten internen Codes erforderlich wird. H\u00e4ufig sind Kernkomponenten betroffen. Beispielsweise ist eine Migration von Node.js\u00a014 oder Python\u00a02 alles andere als einfach.<\/li>\n<li>Langfristiger Support (LTS). F\u00fcr umfangreiche veraltete Projekte werden spezielle Support-Dienste angeboten. Manchmal handelt es sich dabei um einen Zweig des veralteten Systems, der von anderen Entwicklern betreut wird. Andere M\u00f6glichkeit: Backport-Patch, bei dem spezialisierte Teams Patches f\u00fcr bestimmte Schwachstellen auf \u00e4ltere, nicht unterst\u00fctzte Versionen \u00fcbertragen. Der Umstieg auf LTS verursacht generell laufende Support-Kosten, was jedoch in vielen F\u00e4llen immer noch kosteng\u00fcnstiger sein kann als eine komplette Migration.<\/li>\n<li>Kompensationsma\u00dfnahmen. Nach einer detaillierten Analyse k\u00f6nnen <a href=\"https:\/\/www.kaspersky.com\/blog\/legacy-it-update-troubles-and-mitigations\/48692\/\" target=\"_blank\" rel=\"noopener nofollow\">umfassende Sicherheitsma\u00dfnahmen durchgef\u00fchrt werden, um das Exploit-Risiko f\u00fcr Schwachstellen in einem \u00e4lteren Produkt zu reduzieren<\/a>. Effektivit\u00e4t und Wirtschaftlichkeit dieses Ansatzes h\u00e4ngen von der Rolle der Software im Unternehmen ab.<\/li>\n<\/ul>\n<p>Sicherheit, IT und Business m\u00fcssen zusammenarbeiten, um eine dieser drei Optionen f\u00fcr jede dokumentierte EOL- oder aufgegebene Komponente auszuw\u00e4hlen und diese dann in den Asset-Registrys und SBOMs des Unternehmens zu realisieren.<\/p>\n<h1>Risikobasiertes Open-Source-Schwachstellen-Management<\/h1>\n<p>Alle oben genannten Ma\u00dfnahmen reduzieren die Menge an anf\u00e4lliger Software und Komponenten, die in das Unternehmen gelangen, und vereinfachen die Erkennung und Behebung von Schwachstellen. Trotzdem ist es schlicht unm\u00f6glich, alle Fehler zu beheben: Die Zahl der Anwendungen und Komponenten w\u00e4chst einfach zu schnell.<\/p>\n<p>Darum m\u00fcssen <a href=\"https:\/\/www.kaspersky.de\/blog\/cvss-rbvm-vulnerability-management\/32454\/\" target=\"_blank\" rel=\"noopener\">Schwachstellen nach wie vor priorisiert werden, um die realen Risiken zuerst zu adressieren<\/a>. Das Risikobewertungsmodell muss erweitert werden, um die Eigenheiten von Open Source zu ber\u00fccksichtigen. Dabei stellen sich folgende Fragen:<\/p>\n<ul>\n<li>Wird der anf\u00e4llige Codezweig tats\u00e4chlich in der Umgebung des Unternehmens ausgef\u00fchrt? Es sollte eine Erreichbarkeitsanalyse f\u00fcr gefundene Schwachstellen durchgef\u00fchrt werden. Viele fehlerhafte Code-Snippets werden innerhalb der spezifischen Implementierung des Unternehmens nie ausgef\u00fchrt, sodass die Schwachstelle gar nicht ausgenutzt werden kann. Die Analyse k\u00f6nnen bestimmte SCA-L\u00f6sungen \u00fcbernehmen. Dabei kann auch ein alternatives Szenario bewertet werden: Was passiert, wenn die anf\u00e4lligen Prozeduren oder Komponenten vollst\u00e4ndig aus dem Projekt entnommen werden? Manchmal erweist sich dieses Vorgehen als \u00fcberraschend praktisch.<\/li>\n<li>Wird der Fehler bei realen Angriffen ausgenutzt? Ist ein PoC verf\u00fcgbar? Die Antworten auf diese Fragen sind Teil von standardm\u00e4\u00dfigen Priorisierungs-Frameworks wie EPSS. Hier muss aber eine viel breitere Palette von Informationsquellen ber\u00fccksichtigt werden.<\/li>\n<li>Wurden in dieser Abh\u00e4ngigkeits-Registry oder in verwandten und \u00e4hnlichen Komponenten cyberkriminelle Aktivit\u00e4ten gemeldet? Hieraus ergeben sich zus\u00e4tzliche Priorisierungsfaktoren.<\/li>\n<\/ul>\n<p>Anhand dieser Faktoren k\u00f6nnen die Ressourcen effektiv zugewiesen und die gef\u00e4hrlichsten Fehler vorrangig behoben werden.<\/p>\n<h1>Transparenz ist Trumpf<\/h1>\n<p>Die Sicherheitsanforderungen f\u00fcr Open-Source-Software werden weiter steigen. Unternehmen, die Anwendungen entwickeln (auch f\u00fcr den internen Gebrauch) m\u00fcssen strenge Vorschriften erf\u00fcllen, ihr Vorgehen dokumentieren und die Cybersicherheit in ihren Systemen \u00fcberpr\u00fcfbar machen. Nach <a href=\"https:\/\/www.sonatype.com\/state-of-the-software-supply-chain\/introduction\" target=\"_blank\" rel=\"noopener nofollow\">Sch\u00e4tzungen von Sonatype<\/a> erf\u00fcllen weltweit bereits 90\u00a0% der Unternehmen eine oder mehrere Anforderungen, um die Zuverl\u00e4ssigkeit der eingesetzten Software nachzuweisen. Daher gilt Transparenz in Expertenkreisen als \u201edie W\u00e4hrung f\u00fcr Sicherheit in der Software-Lieferkette\u201c.<\/p>\n<p>Durch Kontrolle beim Einsatz von Open-Source-Komponenten und -Anwendungen, Threat-Intelligence-Anreicherung und strenge \u00dcberwachung KI-basierter Entwicklungssysteme k\u00f6nnen Unternehmen notwendige Innovationen einf\u00fchren und dabei den hohen Anforderungen gerecht werden, die von Aufsichtsbeh\u00f6rden und Kunden gestellt werden.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"mdr\"><input type=\"hidden\" class=\"placeholder_for_banner\" data-cat_id=\"mdr\" value=\"30562\">\n","protected":false},"excerpt":{"rendered":"<p>Verwaltung von Schwachstellen bei der Entwicklung und Nutzung von Open-Source-Software.<\/p>\n","protected":false},"author":2722,"featured_media":33404,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1848,3107,3108],"tags":[4213,1520,4263,3161,1111,1498,3881],"class_list":{"0":"post-33403","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-cvss","11":"tag-ki","12":"tag-ki-agenten","13":"tag-open-source","14":"tag-patches","15":"tag-schwachstellen","16":"tag-strategie"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/managing-open-source-vulnerabilities\/33403\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/managing-open-source-vulnerabilities\/30368\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/managing-open-source-vulnerabilities\/25418\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/managing-open-source-vulnerabilities\/30215\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/managing-open-source-vulnerabilities\/30614\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/managing-open-source-vulnerabilities\/41643\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/managing-open-source-vulnerabilities\/14472\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/managing-open-source-vulnerabilities\/55554\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/managing-open-source-vulnerabilities\/24913\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/managing-open-source-vulnerabilities\/30484\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/managing-open-source-vulnerabilities\/36103\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/managing-open-source-vulnerabilities\/35755\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.de\/blog\/tag\/schwachstellen\/","name":"Schwachstellen"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/33403","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/comments?post=33403"}],"version-history":[{"count":5,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/33403\/revisions"}],"predecessor-version":[{"id":33411,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/33403\/revisions\/33411"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/33404"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=33403"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=33403"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=33403"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}