{"id":30029,"date":"2023-04-19T10:57:47","date_gmt":"2023-04-19T08:57:47","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=30029"},"modified":"2023-04-19T10:57:47","modified_gmt":"2023-04-19T08:57:47","slug":"open-source-top-10-risks","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/open-source-top-10-risks\/30029\/","title":{"rendered":"Open Source: die Top-10-Risiken f\u00fcr Unternehmen"},"content":{"rendered":"

IT-Unternehmen setzten als erste auf Open Source, und viele gro\u00dfe Unternehmen folgten diesem Beispiel. Schlie\u00dflich f\u00fchrt die M\u00f6glichkeit, Code mehrfach zu verwenden und unabh\u00e4ngig zu \u00e4ndern sowie Fehler zu beheben, zu schneller Innovation und Kostensenkung<\/a>.<\/p>\n

Doch Open Source hat auch einige negative Eigenschaften \u2013 aufgrund der unklaren Verantwortlichkeiten f\u00fcr die Erstellung und Pflege des Codes. Endor Labs hat mit Unterst\u00fctzung von \u00fcber 20 CISOs und CTOs gro\u00dfer IT-Unternehmen eine systematische Analyse durchgef\u00fchrt, um diese Liste der Top 10 Risiken<\/a> zu erstellen.<\/p>\n

Bekannte Schwachstellen<\/h2>\n

Das signifikanteste ermittelte Risiko war das Vorhandensein von Schwachstellen sowohl im Open-Source-Projekt selbst als auch in seinen Abh\u00e4ngigkeiten, d. h. in externen Open-Source-Komponenten, die im Projekt verwendet werden. Sicherheitsl\u00fccken in Abh\u00e4ngigkeiten k\u00f6nnen bei Dutzenden gro\u00dfer kommerzieller Software-Suiten zu kritischen Problemen f\u00fchren, wie dies bei der bescheidenen Apache Log4j-Bibliothek der Fall war (CVE-2021-44228<\/a>).<\/p>\n

Sicherheitsvorkehrungen<\/strong>: Scannen Sie Ihre Anwendungen regelm\u00e4\u00dfig auf bekannte Schwachstellen \u2013 einschlie\u00dflich Schwachstellen in direkten und indirekten Abh\u00e4ngigkeiten. Installieren Sie verf\u00fcgbare Fixes umgehend. Um die Unternehmensressourcen zu optimieren, k\u00f6nnen Patches basierend auf dem Schweregrad einer bestimmten Schwachstelle und der Wahrscheinlichkeit ihres Exploits in der von Ihnen verwendeten Software priorisiert werden.<\/p>\n

Legitime, kompromittierte Pakete<\/h2>\n

Da bis zu 80 % des Codes von Open-Source-Projekten von anderen Projekten in Form der besagten Abh\u00e4ngigkeiten \u00fcbernommen werden, kann es immer vorkommen, dass Komponenten von Drittanbietern, die in Ihrer Anwendung verwendet werden, trojanisiert wurden. Das kann vorkommen, wenn der Entwickler dieser Komponenten gehackt wird oder das System zur Verteilung der Komponenten (d. h. der Paketmanager) eine Schwachstelle aufweist, die es erm\u00f6glicht, das Paket zu manipulieren. In diesem Fall taucht pl\u00f6tzlich Schadcode von Drittanbietern in Ihrer Anwendung auf, der in der Praxis h\u00e4ufig zum Diebstahl von Informationen<\/a> oder f\u00fcr verschiedene illegale Methoden der Bereicherung (Spam, Adware-Betrug, Mining<\/a>) verwendet wird.<\/p>\n

Sicherheitsvorkehrungen<\/strong>: Es existiert derzeit keine ausgereifte Methode zum Schutz vor dieser Bedrohung, weshalb eine Kombination verschiedener Ma\u00dfnahmen erforderlich ist: manuelle und automatische Systeme zur Analyse des Quellcodes und zur \u00dcberwachung der Repositories<\/a>; lokale Speicherung vertrauensw\u00fcrdiger Versionen von Komponenten; Einsatz von Threat Intelligence<\/a>, um derartige Angriffe im Fr\u00fchstadium zu erkennen (bevor sie Zeit haben, die in den Open-Source-Anwendungen des Unternehmens verwendeten Pakete zu beeintr\u00e4chtigen).<\/p>\n

Angriff der \u201eNamensvetter\u201c<\/h2>\n

Angreifer erstellen Pakete mit Namen, die denen legitimer Pakete \u00e4hneln, oder kopieren die Namen von legitimen Paketen, die in anderen Programmiersprachen geschrieben oder auf anderen Vertriebsplattformen ver\u00f6ffentlicht wurden. So besteht die Gefahr, dass Ihre Open-Source-Entwickler ein sch\u00e4dliches \u201eNamensvetter\u201c-Paket anstelle des Originals integrieren.<\/p>\n

Sicherheitsvorkehrungen<\/strong>: Fordern Sie Ihre Entwickler zur Wachsamkeit auf. Als Teil einer Standardprozedur m\u00fcssen Entwickler den Quellcode von Paketen vor der Verwendung auf Besonderheiten wie verschl\u00fcsselte Fragmente im Code, Hijacking von Funktionen und \u00c4hnliches \u00fcberpr\u00fcfen. Dar\u00fcber hinaus ist es ratsam, die digitalen Signaturen der Pakete (falls vorhanden) zu \u00fcberpr\u00fcfen.<\/p>\n

Nicht unterst\u00fctzter Code<\/h2>\n

Entwickler von Open-Source-Komponenten, -Paketen und -Anwendungen k\u00f6nnen den Support f\u00fcr diese jederzeit und aus beliebigen Gr\u00fcnden einstellen. Bei kleinen Paketen, die von 1-2 Personen entwickelt werden, passiert das h\u00e4ufig. In diesem Fall gibt es niemanden, der das Paket aktualisiert, um es an neue Technologien anzupassen oder Risiken f\u00fcr die Informationssicherheit zu beseitigen.<\/p>\n

Sicherheitsvorkehrungen<\/strong>: Bevor Sie das Projekt in Ihre Gesch\u00e4ftsprozesse und Ihren eigenen Code integrieren, sollten Sie seinen Reifegrad und seine Entwicklungs-\/Supportaussichten \u00fcberpr\u00fcfen. Ber\u00fccksichtigen Sie dabei die Anzahl der Entwickler, die das Projekt verwalten, und die H\u00e4ufigkeit der Aktualisierungen. Pr\u00fcfen Sie, ob und wann Long-Term-Support-Versionen (LTS) erschienen sind. F\u00fcr einige stabile Projekte ist es jedoch ganz normal, dass Releases nur selten erscheinen und nur zur Behebung von Bugs dienen.<\/p>\n

Veraltete Software<\/h2>\n

Die Nutzung alter Komponentenversionen in Projekten erschwert das Patching erheblich. Besonders akut ist dieses Problem im Falle von Risiko Nummer eins: Sicherheitsl\u00fccken in Komponenten. Normalerweise tritt ein Problem mit veralteten Abh\u00e4ngigkeiten auf, wenn sich eine neue Version einer Komponente in Bezug auf Syntax oder Semantik erheblich von fr\u00fcheren Versionen unterscheidet. In einem solchen Szenario kann eine veraltete Version viele Jahre lang ohne Sicherheitsupdates eingesetzt werden.<\/p>\n

Sicherheitsvorkehrungen<\/strong>: Geben Sie den Entwicklern Zeit, mit den Abh\u00e4ngigkeiten zu arbeiten \u2013 dazu geh\u00f6rt auch das \u00dcberarbeiten Ihres Codes, um auf die neuesten Versionen der verwendeten Komponenten zu aktualisieren.<\/p>\n

Ungepr\u00fcfte Abh\u00e4ngigkeiten<\/h2>\n

Da fast jede Anwendung die Komponenten von Drittanbietern verwendet, die ihrerseits wiederum andere Komponenten von Drittanbietern verwenden, wissen die Entwickler der Hauptanwendung oft nicht, dass eine bestimmte Komponente in ihrem Code enthalten ist. In einem solchen Fall wird sie nicht auf alle anderen in dieser Liste aufgef\u00fchrten Risiken gepr\u00fcft. Der Status von Updates, Schwachstellen und dem Rest ist schlichtweg nicht bekannt.<\/p>\n

Sicherheitsvorkehrungen<\/strong>: F\u00fchren Sie eine detaillierte Software Bill of Materials (SBOM) mit Hilfe von Scanning-Tools, die auch Abh\u00e4ngigkeiten erkennen k\u00f6nnen, die ohne Paketmanager verwendet werden.<\/p>\n

Regulatorische und lizenzrechtliche Risiken<\/h2>\n

Obwohl es sich um eine Open-Source-Anwendung handelt, ist jede Open-Source-Anwendung und jedes Open-Source-Paket mit einer eigenen Nutzungslizenz verkn\u00fcpft. Risiken treten auf, wenn sich herausstellt, dass die Lizenz mit der Nutzung der Anwendung f\u00fcr den beabsichtigten Zweck unvereinbar ist oder die Lizenzen einiger Anwendungskomponenten miteinander nicht kompatibel sind. Ebenso ist es m\u00f6glich, dass eine oder mehrere Abh\u00e4ngigkeitskomponenten gegen geltende Gesetze oder beh\u00f6rdliche Auflagen des Unternehmens versto\u00dfen.<\/p>\n

Sicherheitsvorkehrungen<\/strong>: Die bereits erw\u00e4hnten SBOM- und Code-Scanning-Tools sollten eingesetzt werden, um den \u00dcberblick \u00fcber die Lizenzen und Lizenzanforderungen f\u00fcr Open-Source-Anwendungen und -Komponenten zu behalten, die im Unternehmen verwendet werden. In Zusammenarbeit mit der Rechtsabteilung ist es zudem sinnvoll, eine Liste von Standardlizenzen zu erstellen, die f\u00fcr das Unternehmen akzeptabel sind und deren Kompatibilit\u00e4t mit dem Zweck der verwendeten Software beschreiben. Software mit inkompatiblen Lizenzen oder gar keiner Lizenz sollte entfernt werden.<\/p>\n

Unausgereifte Software<\/h2>\n

Die Verwendung von Komponenten, die von einem Team entwickelt wurden, dem es an Reife mangelt, bringt eine Reihe von Unannehmlichkeiten und Risiken mit sich. Zu den Problemen, die mit unausgereifter Software verbunden sind, reichen von einer unzureichenden oder ungenauen Code-Dokumentation \u00fcber Instabilit\u00e4t und Fehleranf\u00e4lligkeit bis hin zum fehlenden Testsatz f\u00fcr Regressionstests. Dar\u00fcber hinaus birgt unausgereifter Code mit gr\u00f6\u00dferer Wahrscheinlichkeit kritische Schwachstellen. Das alles macht den Einsatz unausgereifter Software unpraktisch und erh\u00f6ht sowohl die damit verbundenen Kosten als auch die Risiken von schwerwiegenden Vorf\u00e4llen und Ausfallzeiten.<\/p>\n

Sicherheitsvorkehrungen<\/strong>: Bevor Sie eine Anwendung oder Komponente implementieren, vergewissern Sie sich, dass die Entwickler die aktuellen Best Practices anwenden. Zu den Indikatoren hierf\u00fcr geh\u00f6ren eine vollst\u00e4ndige und aktuelle Dokumentation, CI\/CD-Pipelines f\u00fcr Regressionstests sowie detaillierte Informationen \u00fcber die Testabdeckung und sogar die Anzahl der Pakete, die die betreffende Komponente bereits verwenden.<\/p>\n

Ungepr\u00fcfte \u00c4nderungen<\/h2>\n

Die von einer Anwendung genutzten Komponenten k\u00f6nnen sich auf f\u00fcr die Entwickler v\u00f6llig unsichtbare Weise \u00e4ndern. Eine solche Situation kann entstehen, wenn Komponenten von einem Server ohne strenge Versionskontrollmechanismen und\/oder \u00fcber nicht verschl\u00fcsselte Kommunikationskan\u00e4le heruntergeladen und nicht mit Hashes und digitalen Signaturen \u00fcberpr\u00fcft werden. Theoretisch kann in diesem Fall der Aufbau der Anwendung jedes Mal ein anderes Endergebnis liefern.<\/p>\n

Sicherheitsvorkehrungen<\/strong>: Achten Sie bei der Entwicklung streng auf sichere Verfahren. Nutzen Sie w\u00e4hrend der Entwicklung Ressourcenkennungen, die eindeutig die Version der jeweiligen Komponente angeben. Pr\u00fcfen Sie au\u00dferdem heruntergeladene Komponenten mit digitalen Signaturen. Verwenden Sie stets sichere Kommunikationsprotokolle.<\/p>\n

Zu umfangreiche oder zu geringe Abh\u00e4ngigkeiten<\/h2>\n

Heutzutage k\u00f6nnen Entwickler eine Komponente mit nur drei Codezeilen integrieren. Gleichzeitig ist es ebenso nachteilig, wenn die gesamte Komponente aus vier Code-Zeilen besteht (sehr klein) und wenn der Code, den Sie verwenden wollen, nur eine von Tausenden von Komponenten-Funktionen ist \u2013 von denen die anderen in der Anwendung des Unternehmens nicht verwendet werden. In diesem Fall sind die Entwickler mit der Pflege einer weiteren Abh\u00e4ngigkeit im Interesse einer sehr geringen Funktionalit\u00e4t belastet.<\/p>\n

Sicherheitsvorkehrungen<\/strong>: Vermeiden Sie Abh\u00e4ngigkeiten mit geringer Funktionalit\u00e4t; entwickeln Sie solche Funktionen innerhalb der Hauptanwendung.<\/p>\n","protected":false},"excerpt":{"rendered":"

Open-Source-Anwendungen m\u00fcssen ordnungsgem\u00e4\u00df implementiert und gewartet werden; ansonsten k\u00f6nnte ein Unternehmen zahlreichen Gefahren ausgesetzt sein. Wir zeigen Ihnen die wichtigsten Risiken.<\/p>\n","protected":false},"author":2722,"featured_media":30030,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1848,3107,3108],"tags":[1129,844,963,3161,2183],"class_list":{"0":"post-30029","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-anwendungen","11":"tag-business","12":"tag-entwicklung","13":"tag-open-source","14":"tag-risiken"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/open-source-top-10-risks\/30029\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/open-source-top-10-risks\/25497\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/open-source-top-10-risks\/20930\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/open-source-top-10-risks\/28106\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/open-source-top-10-risks\/25804\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/open-source-top-10-risks\/26221\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/open-source-top-10-risks\/28706\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/open-source-top-10-risks\/35092\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/open-source-top-10-risks\/47875\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/open-source-top-10-risks\/20461\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/open-source-top-10-risks\/21153\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/open-source-top-10-risks\/26124\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/open-source-top-10-risks\/31809\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/open-source-top-10-risks\/31496\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.de\/blog\/tag\/open-source\/","name":"Open Source"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/30029","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=30029"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/30029\/revisions"}],"predecessor-version":[{"id":30031,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/30029\/revisions\/30031"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/30030"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=30029"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=30029"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=30029"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}