Open Source: die Top-10-Risiken für Unternehmen

IT-Unternehmen setzten als erste auf Open Source, und viele große Unternehmen folgten diesem Beispiel. Schließlich führt die Möglichkeit, Code mehrfach zu verwenden und unabhängig zu ändern sowie Fehler zu beheben, zu schneller Innovation und Kostensenkung.

Doch Open Source hat auch einige negative Eigenschaften – aufgrund der unklaren Verantwortlichkeiten für die Erstellung und Pflege des Codes. Endor Labs hat mit Unterstützung von über 20 CISOs und CTOs großer IT-Unternehmen eine systematische Analyse durchgeführt, um diese Liste der Top 10 Risiken zu erstellen.

Bekannte Schwachstellen

Das signifikanteste ermittelte Risiko war das Vorhandensein von Schwachstellen sowohl im Open-Source-Projekt selbst als auch in seinen Abhängigkeiten, d. h. in externen Open-Source-Komponenten, die im Projekt verwendet werden. Sicherheitslücken in Abhängigkeiten können bei Dutzenden großer kommerzieller Software-Suiten zu kritischen Problemen führen, wie dies bei der bescheidenen Apache Log4j-Bibliothek der Fall war (CVE-2021-44228).

Sicherheitsvorkehrungen: Scannen Sie Ihre Anwendungen regelmäßig auf bekannte Schwachstellen – einschließlich Schwachstellen in direkten und indirekten Abhängigkeiten. Installieren Sie verfügbare Fixes umgehend. Um die Unternehmensressourcen zu optimieren, können Patches basierend auf dem Schweregrad einer bestimmten Schwachstelle und der Wahrscheinlichkeit ihres Exploits in der von Ihnen verwendeten Software priorisiert werden.

Legitime, kompromittierte Pakete

Da bis zu 80 % des Codes von Open-Source-Projekten von anderen Projekten in Form der besagten Abhängigkeiten übernommen 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öglicht, das Paket zu manipulieren. In diesem Fall taucht plötzlich Schadcode von Drittanbietern in Ihrer Anwendung auf, der in der Praxis häufig zum Diebstahl von Informationen oder für verschiedene illegale Methoden der Bereicherung (Spam, Adware-Betrug, Mining) verwendet wird.

Sicherheitsvorkehrungen: Es existiert derzeit keine ausgereifte Methode zum Schutz vor dieser Bedrohung, weshalb eine Kombination verschiedener Maßnahmen erforderlich ist: manuelle und automatische Systeme zur Analyse des Quellcodes und zur Überwachung der Repositories; lokale Speicherung vertrauenswürdiger Versionen von Komponenten; Einsatz von Threat Intelligence, um derartige Angriffe im Frühstadium zu erkennen (bevor sie Zeit haben, die in den Open-Source-Anwendungen des Unternehmens verwendeten Pakete zu beeinträchtigen).

Angriff der „Namensvetter“

Angreifer erstellen Pakete mit Namen, die denen legitimer Pakete ähneln, oder kopieren die Namen von legitimen Paketen, die in anderen Programmiersprachen geschrieben oder auf anderen Vertriebsplattformen veröffentlicht wurden. So besteht die Gefahr, dass Ihre Open-Source-Entwickler ein schädliches „Namensvetter“-Paket anstelle des Originals integrieren.

Sicherheitsvorkehrungen: Fordern Sie Ihre Entwickler zur Wachsamkeit auf. Als Teil einer Standardprozedur müssen Entwickler den Quellcode von Paketen vor der Verwendung auf Besonderheiten wie verschlüsselte Fragmente im Code, Hijacking von Funktionen und Ähnliches überprüfen. Darüber hinaus ist es ratsam, die digitalen Signaturen der Pakete (falls vorhanden) zu überprüfen.

Nicht unterstützter Code

Entwickler von Open-Source-Komponenten, -Paketen und -Anwendungen können den Support für diese jederzeit und aus beliebigen Gründen einstellen. Bei kleinen Paketen, die von 1-2 Personen entwickelt werden, passiert das häufig. In diesem Fall gibt es niemanden, der das Paket aktualisiert, um es an neue Technologien anzupassen oder Risiken für die Informationssicherheit zu beseitigen.

Sicherheitsvorkehrungen: Bevor Sie das Projekt in Ihre Geschäftsprozesse und Ihren eigenen Code integrieren, sollten Sie seinen Reifegrad und seine Entwicklungs-/Supportaussichten überprüfen. Berücksichtigen Sie dabei die Anzahl der Entwickler, die das Projekt verwalten, und die Häufigkeit der Aktualisierungen. Prüfen Sie, ob und wann Long-Term-Support-Versionen (LTS) erschienen sind. Für einige stabile Projekte ist es jedoch ganz normal, dass Releases nur selten erscheinen und nur zur Behebung von Bugs dienen.

Veraltete Software

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

Sicherheitsvorkehrungen: Geben Sie den Entwicklern Zeit, mit den Abhängigkeiten zu arbeiten – dazu gehört auch das Überarbeiten Ihres Codes, um auf die neuesten Versionen der verwendeten Komponenten zu aktualisieren.

Ungeprüfte Abhängigkeiten

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ührten Risiken geprüft. Der Status von Updates, Schwachstellen und dem Rest ist schlichtweg nicht bekannt.

Sicherheitsvorkehrungen: Führen Sie eine detaillierte Software Bill of Materials (SBOM) mit Hilfe von Scanning-Tools, die auch Abhängigkeiten erkennen können, die ohne Paketmanager verwendet werden.

Regulatorische und lizenzrechtliche Risiken

Obwohl es sich um eine Open-Source-Anwendung handelt, ist jede Open-Source-Anwendung und jedes Open-Source-Paket mit einer eigenen Nutzungslizenz verknüpft. Risiken treten auf, wenn sich herausstellt, dass die Lizenz mit der Nutzung der Anwendung für den beabsichtigten Zweck unvereinbar ist oder die Lizenzen einiger Anwendungskomponenten miteinander nicht kompatibel sind. Ebenso ist es möglich, dass eine oder mehrere Abhängigkeitskomponenten gegen geltende Gesetze oder behördliche Auflagen des Unternehmens verstoßen.

Sicherheitsvorkehrungen: Die bereits erwähnten SBOM- und Code-Scanning-Tools sollten eingesetzt werden, um den Überblick über die Lizenzen und Lizenzanforderungen für 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ür das Unternehmen akzeptabel sind und deren Kompatibilität mit dem Zweck der verwendeten Software beschreiben. Software mit inkompatiblen Lizenzen oder gar keiner Lizenz sollte entfernt werden.

Unausgereifte Software

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 über Instabilität und Fehleranfälligkeit bis hin zum fehlenden Testsatz für Regressionstests. Darüber hinaus birgt unausgereifter Code mit größerer Wahrscheinlichkeit kritische Schwachstellen. Das alles macht den Einsatz unausgereifter Software unpraktisch und erhöht sowohl die damit verbundenen Kosten als auch die Risiken von schwerwiegenden Vorfällen und Ausfallzeiten.

Sicherheitsvorkehrungen: Bevor Sie eine Anwendung oder Komponente implementieren, vergewissern Sie sich, dass die Entwickler die aktuellen Best Practices anwenden. Zu den Indikatoren hierfür gehören eine vollständige und aktuelle Dokumentation, CI/CD-Pipelines für Regressionstests sowie detaillierte Informationen über die Testabdeckung und sogar die Anzahl der Pakete, die die betreffende Komponente bereits verwenden.

Ungeprüfte Änderungen

Die von einer Anwendung genutzten Komponenten können sich auf für die Entwickler völlig unsichtbare Weise ändern. Eine solche Situation kann entstehen, wenn Komponenten von einem Server ohne strenge Versionskontrollmechanismen und/oder über nicht verschlüsselte Kommunikationskanäle heruntergeladen und nicht mit Hashes und digitalen Signaturen überprüft werden. Theoretisch kann in diesem Fall der Aufbau der Anwendung jedes Mal ein anderes Endergebnis liefern.

Sicherheitsvorkehrungen: Achten Sie bei der Entwicklung streng auf sichere Verfahren. Nutzen Sie während der Entwicklung Ressourcenkennungen, die eindeutig die Version der jeweiligen Komponente angeben. Prüfen Sie außerdem heruntergeladene Komponenten mit digitalen Signaturen. Verwenden Sie stets sichere Kommunikationsprotokolle.

Zu umfangreiche oder zu geringe Abhängigkeiten

Heutzutage können 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 – von denen die anderen in der Anwendung des Unternehmens nicht verwendet werden. In diesem Fall sind die Entwickler mit der Pflege einer weiteren Abhängigkeit im Interesse einer sehr geringen Funktionalität belastet.

Sicherheitsvorkehrungen: Vermeiden Sie Abhängigkeiten mit geringer Funktionalität; entwickeln Sie solche Funktionen innerhalb der Hauptanwendung.